Looking at the package repo, it looks like you just store metadata and a link to the file along with a hash. As long as the repo is reasonably controlled, that should address Mark’s concern. We just need to have a clear process on the rules of inclusion. I would suggest that every addition has a couple of trusted people review it prior to merge.
Right now it requires one review, but that can be changed at any time.
Dis someone say Package Manager? :
YES PLEASE!!! 
I put this in as experiment/placeholder for something better a long time ago now.
It’s slow though, using datagrid with Emscripten was a mistake, needs replaced with a non-web based UI.
Relevant posts here: OXT Community Sample Stacks, Extension & Resource Management - Page 2 - OpenXTalk Forums
NOTE the post above that: OXT Community Sample Stacks, Extension & Resource Management - Page 2 - OpenXTalk Forums
Which is all about the ‘Loadable Code Extension’ (de-branded 
) ‘Package’ file format.
.LCE files are just ZIP compressed directories of a specified folder structure, which can include stacks/scripts OR xBuilder lcb source / lcm compiled bytecode module, AND can include icons, dictionary files, sample stacks, default scripts, resources (images, sounds, etc.), code (compiled libraries for FFI wrappers), etc.
This could be extended to support whatever HXT is doing with that script-compiler library, also ‘guide files’ and sample stacks like those found on the old revOnline.
xBuilder language even has ‘my resource folder’ syntax to make it easier to locate resources from LCB code.
I imagined it like Package Management repos could be handled in a way that there would be a main, curated repo, AND the repo list would be user-extensible, so that a dev could add in their own remote or locally stored on disk repository (which the user would be trusted source obviously), a concept much like the one used by the popular FOSS Media Center app KODI.
For my ‘repo’ system I tried to keep it simple, using Tab-Seperated (TSV) to store the info about repos (a URL or a folder path), and for the list of the contents of the current repo:
A nice thing about using Tabbed Sep Values is that GitHub understands them and displays them as tables in its web-UI.
Each file in the repo then can have a text file that includes more detailed information about the package, and a .svg icon for widget (which can be extracted with revExtensionManager API), and a preview image, using a same base-name format like:
whatever.whatever.lce.txt, whatever.whatever.lce.svgicon, whatever.whatever.lce.jpg
for HXT stacks is would be whatever.hyperxtalk, whatever.hyperxtalk.jpg
Package formats and their managing software are often recognized as complex beasts, saddled as they are with such a wide range of considerations.
In the LC community, the pursuit of a PM was a long evolutionary journey of discovery and learning, at times advanced through a few working groups which identified needs and developed tooling.
In the Drupal community, a significant shift of package management made years ago has more recently been discovered to be problematic for addressing the project’s current needs.
If you’re confident with this HexTalk implementation there’s no need to go rifling through archives to put together a map of an ancient land never fully settled.
But if the PM released now is more of a thought experiment to prompt discussion and planning, I can find relevant details among the ancient scrolls which may be useful, if that’s the case.
Well, the package manager has been written and is usable the way it is. We added Paul’s suggestion of multiple repos, while it was still a low-risk feature to add. Now is the time to suggest features before it’s released and put into use, as it will be trickier then to do updates
1 Like
HexTalk?
BTW, since I keep mentioning it (on purpose) I’m not now calling ‘lcm’ as ‘Loadable Code Modules’ purely out of the need to De-Brand everything in the IDE, that’s actually what they are. .lcm is a compiled bytecode in a file. I started to reverse engine the .lcm file format a bit (only enough to extract the extension id from the header of a module.lcm file), when I made a stack demonstrating lcm ‘on-the-fly’ module loading:
That stack has like 5 or 6 Extension modules included in it stored as custom properties, which can be selected from a list and loaded into ram ready for scripts to use.
I particularly like the Vector Drawing Board demo in that stack
There was a long playful discussion of names once, you can say hexTalk if you vocalize hxTalk or HXT:
There was and it was enjoyable I still either call it HyperXTalk or say the letters H-X-T, but I like the play on letters and calling it hexTalk.
1 Like
Okay, we can now install extensions too without having to use the Extension Manager, just do it straight from the package manager.
1 Like
This is what I came up with for the Package Manager, but the logic is separate from the UI so you can make your own up. Lets see what you can come up with and we’ll vote on the one we like to make it the default package manager.
1 Like
This looks very good 
Thanks for the kind words. I’m waiting to see what you guys can come up with though
Ah I see, OK thanks.
Probably still need some sort of Extension Manager as part of the IDE, like to un-install, go-to Dictionary docs/guides, and to launch demo stacks included with an Extension.
Also, need an editor for making Meta data for packages.
The Extension Manager isn’t going away, but the Package Manager handles the uninstallation as well. Never thought about auto-launching demo stacks, but it would be kind of tricky because they’d all be named something different.
There’s already a mechanism in place in Extension Manager that you can launch a demo stack, if one was included in .lce package in ‘Samples’ subfolder). The problem was mechanism was broken (but fixed it in my version). It would list the sample stacks but not open them. That’s when/why I parsed out the API.lcdoc for the Extension Manager library so I could see what handlers are there already. There’s already handlers in there that can return a bunch of information on Extensions like directory path info, and the SVG path of its icon for examples.
Project/Sample/ stacks for installed Extensions appear in a Context menu for EM rows:
Phonetic habit. It’s how I pronounce it when talking about the project with colleagues. And I have a thing for hexagons, so it’s a little too easy to make that misspelling.