Hi David,
thanks for the explanation. I was actually not arguing for putting
everything in one file.
The point was not to separate the meta information from the main apl
file (the one
)COPYd by the user) so that the meta information is available at the apl
level.
I fully agree that a lib that contains several file should be in its own
directory
(for example under /usr/lib/wslib3/foo-package) with a link in
/usr/lib/wslib3 so
that it is found by )COPY 3.
/// Jürgen
On 06/02/2014 07:48 PM, David Lamkins wrote:
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.
On Mon, Jun 2, 2014 at 3:53 AM, Juergen Sauermann
<juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
wrote:
Hi David,
I have a few small comments after reading the documents of your
package manager.
1. Distribution format.
I believe it is OK to download the package manager with git or svn
as long
as it is under development. But the normal distribution format
should be something
more common such as a *package.tar.gz *file. System administrators
will appreciate that.
2. Metadata file
Do you think it would be possible to have the meta data in the (or
the main) APL file instead
of a separate file? Having a separate metadata file does not hurt
if you use git, svn, or tar files.
However, I could very well envision other use cases (emails,
cut-and-past from documents or
web pages) in particular for small (single file) libraries. In
these cases a single file is much
easier to use.
Both file formats used by GNU APL (.xml and .apl) could easily
support this (APL ⍝ comments in .apl files or
xml comments or an extra xml tag). Another option would be one or
more APL functions returning the metadata.
This would also make it easier to access the metadata from APL.
3. Installation directory
I believe that installing libraries in $HOME/workspaces is not a
good idea. If you have a
system administrator then she will most likely no appreciate the
idea of installing files in some
user's home directory (and certainly not in her own one). So if
the package manager becomes
famous then it rather wants to be installed in some /usr/lib/xxx
directory than in $HOME/xxx.
There are a number of existing conventions for installation
directories (File System Hierarchy
Standard and autoconf packages) that should be considered in this
context).
In particular we should separate user-related directories ($HOME
and $GROUP) from machine
directories (usr/lib etc.) so that a package installation only
uodates the latter and not the former
(which may contain changes made by the user).
My current thinking is this:
We have 10 library reference numbers 0-9 that could be divided
like this by default:
*0 $HOME/workspaces
1: $GROUP/wslib1
2. $ALL/wslib2 #$ALL does not exist really - just to
explain the concept
3: /usr/lib/apl/wslib3 # fully portable libraries
4: /usr/lib/apl/wslib4 # basically portable libraries
5: /usr/lib/apl/wslib5 # GNU APL specific libraries
6...9: TBD (eg. examples, tutorials, testcases, etc)
*In this scheme, packages and GNU APL itself would install
libraries in locations 3, 4, and 5.
I am planning to generate the GNU APL preferences file by
./configure so that libraries
that are shipped with GNU APL will be installed in /usr/lib/apl or
/usr/local/lib/apl (or $PREFIX/lib/apl)
as determined by ./configure and make the default preferences file
use these directories.
/// Jürgen
--
"Far out in the uncharted backwaters of the unfashionable end of the
Western Spiral arm of the Galaxy lies a small unregarded yellow sun.
Orbiting this at a distance of roughly ninety-eight million miles is
an utterly insignificant little blue-green planet whose ape-descended
life forms are so amazingly primitive that they still think
programming in Java is a pretty neat idea."
-- With apologies to Douglas Adams, who I like to think would have
appreciated this.
http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/
