Uploading a package is an irreversible operation. It's not even about
accidentally leaking your secret sauce to the internet. You could upload
a package to snow-fort.org by accident and pullute the package name
space [1].
So let's ask the user first before going ahead uploading stuff. We only
ask once even if we're going to upload a dozen packages, so it's not
that annoying. The target repo is also shown in case you want to upload
to a custom repo and want to make sure it does so.
[1] I did (while attempting to uploading to a local snow-fort instance
during testing). I guess `(chibi snow commands)` is forever mine
now.
Currently a package's cond-expand contains the symbol of the target
implementation and optionally more from config file. Execute a
command (once) on target implementation to add their full feature list,
making it available for each package to use.
All of these Schemes are tested. Larceny is just too annoying to get the
feature list (no one-liner, and it could take a while) so Larceny stays
the current behavior.
There is a small unrelated change here: the gosh command to get
version. We don't need to call (exit), if stdin is closed properly (it
should) then gosh should exit regardless.
$ tools/snow-chibi implementations
WARNING: Implementation gauche is an unsupported version,
0.9.10_pre1, but at least 0.9.4 is required.
cyclone
sagittarius
The easy solution is also accept "_" as version separator and consider
"pre1" the forth component. This makes the warning go away, and I don't
think it'll affect version comparison on other schemes.
Currently "remove" command does not know how to use sudo to remove
files installed into directories owned by root. By default Snow
installs stuff into /usr/local hierarchy and uses sudo for that.
Let's teach it to remove packages without explicit sudo too.
Snow-Chibi is a local package manager, not a system one. It can install
Scheme packages into system but they are not managed by system package
manager like dpkg, RPM, pacman, ports, etc.
Traditionally (and in accordance with Filesystem Hierarchy Standard),
/usr/local hierarchy should be used for local administrator installs --
and that's what Snow-Chibi provides.
Let's make sure that Snow-Chibi installs snowballs into /usr/local
hierarchy even if Chibi is compiled for installation into the system,
with PREFIX=/usr. Introduce a distinct bunch of variables holding paths
to library installation directories, with "SNOW" prefix:
- SNOWPREFIX - default prefix for Snow-installed stuff
- SNOWLIBDIR - custom libraries required for Snow itself
- SNOWSOLIBDIR - shared libraries required for Snow itself
- SNOWMODDIR - Snow installs Scheme modules here
- SNOWBINMODDIR - Snow installs native libraries here
All of these are set to /use/local by default, just as they are now.
However, they are not affected by regular PREFIX, LIBDIR, MODDIR, etc.
which affect only libraries bundled with Chibi.
And in order for these to work, they need to be added into the current
module path so that they can be used in parallel with system libraries.
Furthermore, we need to tweak "get-install-library-dir" function to use
those paths instead of hardcoded "/usr/local/lib" by default. Introduce
a new helper "get-install-library-dirs", similar to "get-install-dirs".
It will look up the correct installation directories in current module
path, giving preference to the ones with "/lib" in them.
With these defaults, Snow will install Scheme modules into
/usr/local/share/snow and native libraries go into /usr/local/lib/snow,
similar to how built-it libraries are installed into
/usr/local/share/chibi and /usr/local/lib/chibi is used for native code.
Of course, this can be overriden at build time by setting SNOWPREFIX or
individual SNOWMODDIR, SNOWBINMODDIR variables.
To get the repository path in Chicken 5, we not only have to require the
chicken.platform module, we also need to take the car of the result
since it now returns a list.
The method snow-chibi used to get the version of Chicken installed
doesn't work with Chicken 5. Adding "-R chicken.platform" would make it
work with Chicken 5, but then it wouldn't work with Chicken 4.
In both Chicken 4 & 5, however, csi has a -release option that will just
give the version number. So, I've changed the Chicken version detection
in snow-chibi to use this option.
Testing with...
./chibi-scheme tools/snow-chibi.scm implementations
...then seemed to work with both Chicken 4 & 5.
