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.