Re: PCAN packages
- Posted by ghaberek (admin) Feb 13, 2023
- 378 views
I've had some thoughts about that.
Rather than something like python's pip, or go get or julia's use Pkg; Pkg.add("xxx"); a better
mechanism is to plonk that sort of code directly into the interpreter. First off, let's have an
option which triggers the new behaviour, say "include [auto] bass\bass.e", so if bass.e is found
Personally I'm not fan of this or automatic includes in general. I don't like black-box "magic" unless I can somehow peek behind the curtain to specifically deduce what's going on. Something like Make's --recon like maybe "--print-includes" or "--show-dependency-resolution" would go a long way here. But even then, automatic features like this have a funny smell to me so I'm not a big fan.
it just carries on as normal, otherwise it starts prompting to look/download/install/restart.
I could even and probably would add a new tab onto the "p pgui" window to do that last bit, so
what a final end user would see is a big(ish) popup window that starts with something like:
snip (too long)
Users would be given the choice of installing to Phix\builtins, the app directory, or maybe even
C:\Users|~ (and of course the interpreter updated to look for include files there too).
The onus of building and packaging an application should be solely on the developer. We should provide ample tools that are (hopefully) easy to use but in the end, if I download and install "FoobarApp" from somebody's website, I don't ever expect it to do anything but run as its own self-contained app. I don't ever want "FoobarApp" to be reaching out to "Someguy's Website" for part of its runtime. Unless that's not what you meant by this.
Somewhere on the PCAN wiki there could be a packages.txt anyone can edit/vandalise, containing
snip (too long)
Anyone [re-]uploading a package *must* update the sha256 checksum, sha512 are also valid too.
It would technically be much safer to post any new checskums on the Eu forum instead, or maybe
require pull requests on the github repository, but that might just scare away too many people.
One point worth noting is that all packages *must* incorporate a unique directory name, so they
don't start clobbering bits 'n pieces of any other packages, assuming that at least some will be
multi-file, which must be in a zip (auto-extracted into said target directory), any install.exw
would just be stuff that needs doing after that has happened.
The packages.txt file must be maintained in strict alphabetic order of [full] package names.
Maybe other site links could be permitted, but we want/need PCAN to be a "start your search here".
Allowing private (non-PCAN) download urls would certainly make the sha256 checksums far more secure.
Of course PCAN can/should still have a "backup" copy, and you can initiate a "secure" install from within
PCAN itself simply by copying the PCAN url into the clipboard and then running "p pgui".
It would be my responsibility to vet any changes to that file and include a copy in the distro
as Phix\builtins\packages.txt, and possibly vet/upload on demand to somewhere a bit safer than
the wiki, on a slightly more regular basis. Obviously, any contributor can edit their own copy
for testing purposes, and/or get to see an "sha256 error: "???" != "e3b0c...2b855", in full.
I was thinking of taking a page out of Go's book with their go get command. Along your lines, it's a built-in feature of the go compiler and it doesn't really care where it gets packages from as long as it can get to them. Although I'd still prefer each tool be its own thing instead of cramming everything into one monolithic executable. A requirements.txt (or packages.txt) could accompany each project something like euget install -r requirements.txt would then fetch and install them.
[github.com] OpenEuphoria/foobar@v3.1.4 ghaberek/package-name@v1.5.9;sha256=a1b2c3d4e5f6... petelomax/phix-package@2.6.5;sha512=a1b2c3d4e5f6e5d4c3b2a1...
This negates the need for an API or wiki (not a fan of apps reading data from a human-editable webpage) for actual package retrieval. And it puts the ownership solely in the hands of each package maintainer. You could just maintain an "Index" page with categorized links to known package repositories.
Of course there is no point whatsoever in me starting any of that unless other people are ready
and able and willing to start contributing useful stuff in that fashion.
Likewise, no objection to someone initiating a massive overhaul and restructuring of PCAN either.
PS: Any bottlenecks here pale into insignificance compared to me/Greg being the only ones who
apparently stand any chance at all of ever shipping a new release. I would certainly have no
problem with a "vetted" packages.txt kept in a repository several trusted parties could update.
Agreed. Only thing I ask is that I be involved in the design as I've already given this a lot of thought and I've collected a lot of knowledge IT, Cybersecurity, and the "modern" development world.
-Greg
