Thanks for your detailed comments, Jüergen.
Point 1: use a file archive rather than git or svn.
Agreed. I'll change my recommendation concurrent with the initial release of the package manager.
It's certainly easier to rely on source control for updates while still in testing.
Point 2: metadata as APL; single-file packages
You make some good points. I won't rule out making this change.
I would like to address your concern regarding a single-file package, though. The package manager requires a directory to enclose the package. This is not because of the separate metadata file, but rather because I want the package manager to support (a) APL code which is modularized by file, (c) packages which combine APL code with code written in other languages, and (c) packages in which one or more data files may be an integral part of the package. IOW, I believe that restricting a package to a single file unnecessarily restricts what one *should* be able to do with a package.
I think that a single-file package (combining both metadata and APL code) may be an interesting optimization to the package manager. I'll think about the implications.
The ease of use of a single file is a compelling argument. However, creating a package around a single APL file is already an almost-trivial operation.
There's also the question of whether metadata should be part of a package's namespace. Obviously, I've opted to keep the metadata separated; the package manager, not the package, "owns" the metadata. To me, this seems like a "cleaner" approach. I'd be curious hear about use-cases that would require the metadata to be present in the package's namespace.
I have a roadmap (see ROADMAP.md) listing the order in which new features might be added to the package manager. I personally don't see the single-file use-case as being particularly urgent; I'd probably slot this in just prior to multi-platform support. I'm open to persuasion.
Point 3: directory hierarchy
I've already entered into an off-list conversation with Elias regarding this same issue. I hope he'll chime in here with comments and use-cases.
I clearly need to rethink how I'm installing the package manager. I may also need to move search-path implementation much earlier in the roadmap.
One point where my vision differs significantly from yours is in the notion of platform-specific code. You propose isolating such code in a platform-specific directory (i.e. wslib5). I anticipate bundling code for multiple platforms in a package and having the package manager load the proper code for the platform.
My main concern in changing behaviors in this area will be to not preclude future[*] multiplatform support (other APL interpreters and other host operating systems).
Thanks again for your comments!
Best wishes,
David
NOTE: [*] The initial implementation of the package manager is specific to GNU APL on Linux. I do intend that a future release will support other APLs and other operating systems. The package manager's architecture is already leaning in this direction even though the implementation does not fully support the intention of the architecture. Full multiplatform support comes late on the roadmap, just before remote repository support.