1. PCAN packages
- Posted by petelomax Feb 13, 2023
- 528 views
Forked from Re: Definitive list of Euphoria libraries?
but most importantly we need package authors and maintainers, and that includes people to build and operate the package system itself.
That cannot happen.
Why not? I think it can. PCAN for Phix is proof that it can be done. Heck, I wonder if we should work with petelomax to extend PCAN to cover OpenEuphoria specific packages as well.
No objections here
That said, if we find someone who has the drive to create an OE packaging system from scratch and start adding packages to it, I don't have any real objections to letting that person start working.
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
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:
This application cannot run because of a missing file. With your permission, I think I can get that for you. All options here have suitable and sensible defaults, so you can just click OK or Cancel when you're ready.
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).
Somewhere on the PCAN wiki there could be a packages.txt anyone can edit/vandalise, containing
package: bass\bass.e description: `An audio library` PCAN url: http://phix.x10.mx/pmwiki/pmwiki.php?n=Main.Bass download url: http://phix.x10.mx/pmwiki/uploads/bass.zip sha256 checksum: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 installation: install.exw /*optional*/ compatibility: Phix|Euphoria|Eu4.1+ /*or whatever, also optional*/
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.
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.
2. Re: PCAN packages
- Posted by axtens_bruce Feb 13, 2023
- 499 views
Reads a bit like how Deno does it.
-Bruce
3. Re: PCAN packages
- Posted by ghaberek (admin) Feb 13, 2023
- 498 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
4. Re: PCAN packages
- Posted by petelomax Feb 13, 2023
- 465 views
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.
There is nothing to stop you downloading and installing things manually, and if you don't put "[auto]" in your include statements none of this affects you anyway.
The onus of building and packaging an application should be solely on the developer.
There is clearly still a need for proper applications to be properly packaged, and if you're shipping a binary you kinda have to anyway.
That said, there is also a case for an amateur programmer to put out an amateur (open source) package, and Phix/Euphoria to pick up the pieces.
I was also perhaps thinking more along the lines of here's some source code, now how do I run it when the original author did a runner years ago?
I was thinking of taking a page out of Go's book with their go get command.
Not really a fan of go get: pip, Pkg.add() and even npm install simply work better. (OK, to be precise, it is good, but others are even better)
One thing they don't tell you in the go docs is that anything more than a year or so old is guaranteed fubar. And more than a few are Linux-only.
A requirements.txt (or packages.txt) could accompany each project
That could be done, and maybe, even probably, quite a bit simpler than your current thinking.
(not a fan of apps reading data from a human-editable webpage)
Absolutely, only post-manually-vetted stuff would ever actually be used, and all downloads properly sha-2 verified. (and to be really picky, I know you meant publically-editable)
[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 for actual package retrieval. And it puts the ownership solely in the hands of each package maintainer.
Not getting that. Where are the urls, installation hints, compatibility? Are you really saying github-only? If ownership is soley in their hands, how does that ever get on anyone else's machine?
Ah... is it that you are thinking more of a single application, whereas I've got my sights more on re-usable components?
You could just maintain an "Index" page with categorized links to known package repositories.
How is that in any way different to my suggested packages.txt file, exactly? Didn't like the layout? Too much useful information?
Only thing I ask is that I be involved in the design
Of course.
PS: I hadn't actually thought about the possibility of sticking anything on a cdn until just now, either.