PCAN packages

new topic     » topic index » view thread      » older message » newer message

Forked from Re: Definitive list of Euphoria libraries?

jimcbrown said...
katsmeow said...
ghaberek said...

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

jimcbrown said...

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.

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu