Michel Schinz <Michel.Schinz@epfl.ch> writes:
> Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de> writes:
>
>> Michel Schinz <Michel.Schinz@epfl.ch> writes:
>
>
>> I think we should limit the possible kinds of archive and
>> compression methods.
>
> Ok. I guess that "tar" for archives and "gzip" and "bzip" for
> compression methods are enough for now.
So do I.
> [...]
>
>>> To help package authors write their installation script, a small
>>> library could be provided with scsh. This library should contain
>>> functions to install packages according to the scheme proposed
>>> here. (That includes functions to get the name of the directory in
>>> which scsh packages should reside---what is called the package
>>> root below).
>>
>> Yes, I think such a library is really needed. However, we should
>> start with something simple so it doesn't hamper the release of this
>> proposal.
>
> Ok, I'll make an attempt at defining this.
Great!
> I have to say that my current specification about the installation
>
> Which reminds me of the fact that tilde-expansion is not performed on
> the paths contained in SCSH_LIB_DIRS:
>
> ----------------------------------------------------------------------
> % SCSH_LIB_DIRS='"~/projects/scsh-packages/root/"' scsh -ll sunet/pkg.scm
>
> Error: Couldn't find library module file
> "sunet/pkg.scm"
> ("~/projects/scsh-packages/root/")
> % SCSH_LIB_DIRS='"/home/schinz/projects/scsh-packages/root/"' scsh -ll
> sunet/pkg.scm
> Welcome to scsh 0.6.4 (Olin Shivers)
> Type ,? for help.
>>
> ----------------------------------------------------------------------
>
> Maybe it would be nice (and helpful for users who need their own
> package root) to perform tilde-expansion on all components of
> SCSH_LIB_DIRS at scsh startup.
Hmm, yes that sounds reasonable. However, I wonder if Olin left out
this feature intentionally, given the fact that the +lp and +lpe
options differ at this point.
> [...]
>
>>> - Every package version directory contains one file called "pkg.scm"
>>> (maybe "packages.scm" if we want to keep the current practice)
>>> which contains the definition of *all* the interfaces and
>>> structures which make up the package.
>>
>> An alternative would be to require a "load-pkg.scm" file that is to be
>> loaded in the exec package and could load the interface and structure
>> definitions and in addition execute arbitrary code. I'm not sure if
>> the additional power is needed but it's probably more flexible and
>> could save the package author from defining one big package file.
>
> Right, that's a good idea. But then it's not compatible with scsh's
> -ll option, it seems. (or we need to provide equivalents to -ll and
> SCSH_LIB_DIRS that works for the exec package).
Yes, we would need a new command line option (-lel ?) but we could use
the library path for searching.
Hmm, maybe it would be nice to have the set of options
-m <package> Switch to package.
-config Switch to config package.
-exec Switch to exec package.
-l <file-name> Load file into current package.
-ll <file-name> As in -l, but search the library path list.
-ds Do script. (in current package)
instead of the current
-m <package> Switch to package.
-lm <module-file-name> Load module into config package.
-le <exec-file-name> Load file into exec package.
-l <file-name> Load file into current package.
-ll <module-file-name> As in -lm, but search the library path list.
-ds Do script.
-dm Do script module.
-de Do script exec.
That is, to add the config and exec packages to the set of packages
that can be "current" during command line evaluation and simply use -l
to load a file into the current package. And -ll to load a file into
the current package but search the library path for the file. Just a
thought...
> [...]
>
>>> Some "meta-data" about packages would need to be defined somewhere,
>>> like the dependencies among packages.
>>
>> Yes, but I don't think we should talk about this for now. We could
>> however standardize the set of possible version numbers to make it
>> easier to speak about depending on a specific version (range) later.
>
> Yes, I guess if we say that versions are sequences of integers, and
> that they are ordered lexicographically, it's enough.
Plus, that the sequence delimiter in the version number is a simple
dot...
> Thanks for your comments. In the following days I'll update my
> document and take a few existing packages (sunet, sunterlib, pgscsh)
> and try to write a scsh install script for them. That should help me
> find out if the above makes sense, and give me an idea of the
> functions we should provide in the library I talk about in the
> "Package configuration, building, testing and installation" part. I'll
> keep you updated about my progress.
Thanks a lot for your effort!
--
Martin
|