Okay, so we have the workings of a package manager in HyperXTalk. Currently it supports script libraries. Should we expand it to include plugins and extensions too?
oh yeah, and if anyone feels inclined to create a GUI for it it is a script library itself so you can create your own UI for it
Package Manager ? ![]()
Sounds interesting — but at the moment I have absolutely no clue what it actually is or what we could do with it.
Could you please give us a bit more information about what it’s used for and which problems it helps solve ?
(Don’t worry, you cannot have known)
Basically it’s a repository for developers to post their libraries to and then you can download them and use them in your IDE/software without having to hunt the internet for them.
Obviously there’s not much there as it’s not available yet
but the test library does work (gets installed, runs and gets uninstalled)
Hey that link looks familiar
If you’ve ever used Linux or brew (on macOS) then you’ll know about package managers.
From Wikipedia
A package manager, or package management system, is software that supports installing, upgrading, configuring, and removing software for the host system in a consistent manner.
Thanks for the explanations — that actually sounds like a very good idea ![]()
But one thing just popped into my mind: how am I supposed to know what something like com.hyperxtalk.library.test actually does? Right now it feels a bit like opening a mystery box and hoping for the best ![]()
Maybe we could agree on having a title or short description at the top of the xxx.hyperxtalkscript file, which could also be displayed in an info field in the stack you showed. That way people can immediately see what the library is for and what magic it contains ![]()
Or maybe I’m missing the intended workflow here — how are users supposed to discover and use these libraries ?
That’s a good idea. I’ll add it in
Yeah, that’s definitely one way ![]()
I was imagining it more like this (see screenshot):
You click on the library, and then the stack reads a defined part of the library and displays it in the top field.
Kind of like a “click and preview”
But your version is also great it hides the Libray name completely - I like that also.
The thing with click and preview is you have to click to read the description so you can’t just scan as you scroll. I had originally thought of a click and preview as well.
That’s kinda big. Where do I find it?
I’m just working out a few kinks and then it’ll be in the pull request
There is already code to parse documentation out of script files. If we define a minimum set of fields for a script to be included, that could be leveraged. For the list view, it could be just the name and summary or description fields. The full documentation file could be viewable without installation as well (like a preview).
The only thing is the documentation resides on a foreign host so I don’t know how easy it will be to get it and load it.
Docs will be small, so fetching them as needed shouldn’t be too bad. Having said that, I would need to understand how the data will be structured/stored/fetched to really be able to offer useful suggestions. For now, it is just a high level idea to keep in mind. Once I see how the data flow is envisioned, I can offer my thoughts.
I rather hate to say this because the Package Manager is a Big Thing. But we need some way to vet the posted libraries/stacks/plugins/whatever before they can be public. I have complete trust in my linux lineage… when I get notices that updates are available I grab them. That’s not the case for files that have been posted online by anybody who has access to the internet. I’d start by saying that just a string saying “Authour” isn’t enough. I’d want verifiable contact info. There’s enough problem with npm management in the supply chain.
Right now every entry in the package manager has to be a pull request in GitHub and then it needs to be verified before actually showing up in the list of packages available.
As for the verifiable contact information what do you have in mind?
You can find it at this pull request


