Re: [Chicken-users] Installing data files for eggs

[Jim Pryor]

On Sat, Oct 02, 2010 at 08:55:59PM +0200, Peter Bex wrote:
> 
> Is there a proper way to install data files from egg .setup-files?
> I couldn't find anything at http://wiki.call-cc.org/manual/Extensions
> so I rolled my own for the "slatex" egg:
> 
> ---
> (define style-path
>   (list (installation-prefix) "share" "chicken" "slatex"))
> 
> ;; <snipped: code to build style-path into to the program>
> 
> (copy-file "slatex.sty" (make-pathname style-path "slatex.sty"))
> (copy-file "slatex-chicken.sty" (make-pathname style-path 
> "slatex-chicken.sty"))
> (copy-file "cltl.sty" (make-pathname style-path "cltl.sty"))
> ---
> 
> The disadvantages are obvious: these files don't get uninstalled by
> chicken-uninstall and Chicken's data files aren't necessarily installed
> under $PREFIX/share/chicken  (the user can override $DATADIR on the Make
> invocation when building Chicken).

Hi Peter,

I'm really not *that* knowledgeable about egg installation. But I have
been writing packaging scripts for most of the eggs, for the Arch Linux
user repository. From that experience, I got the following impressions:

1. You're right, you shouldn't hard-code share/chicken/slatex in the way
you do. But this would work instead:

-(define style-path
-  (list (installation-prefix) "share" "chicken" "slatex"))
+; also declare additional dependency on setup-helper
+(include "setup-helper")
+(define style-path
+  (list (installation-chicken-home) "slatex"))


2. And that's where you should be copying your slatex.sty etc. files. Is
it really true that files copied in that way don't get uninstalled by
chicken-uninstall?

3. However, please don't hard-code installation-prefix into the program.
This is the code you snipped:

> ;; Is there a simpler way to bake this path into the program at compile time?
> (with-output-to-file "style-path.scm"
>   (lambda ()
>     (write `(define style-path ',style-path))))

I guess installation-prefix could be used in two different ways. One way
might be: I have my main chicken-home underneath, say /usr. Some
system-wide directory chosen when compiling chicken. But I want to
install your egg underneath, say ~/chicken. Then I'd use
`chicken-install -p ~/chicken slatex`. And in this case, when I go on
later to use your egg, your egg should look for its datafiles underneath
~/chicken. This usage pattern fits ok with what you've done above.

However, here's another way that installation-prefix can be used, which
is what I do when writing packaging scripts for installing eggs using
the Arch Linux package manager.

When building a package, we run:

    chicken-install -p /some/fakeroot/usr

This installs all the egg's files underneath an (otherwise empty) fakeroot. If 
the build step completes successfully, then the packaging system compresses all 
the files in the fakeroot and wraps it as a binary package. Later, the user can 
install that binary package and the files will then be installed not underneath 
/some/fakeroot, but instead underneath the real root /.

With this usage pattern, I'd want your egg installation sequence to
install files underneath installation-prefix (setup-helper defines:
    (installation-chicken-home) ; /some/fakeroot/usr/share/chicken
    (installation-repository-path) ; /some/fakeroot/usr/lib/chicken/5

But then when I'd *use* your egg, I'd want it to look for its files
underneath chicken-prefix, (chicken-home), and (repository-path).

If both of these are legitimate uses of installation-prefix (and I certainly
hope the second is; otherwise I see no good way to integrate the
chicken-install system with our packaging system), then perhaps you
should define two style-paths, one under installation-chicken-home, and
the other underneath chicken-home.


> So, I think it would be a good idea to add something like this to
> setup-api:
> 
> (define style-path (data-path-for-extension 'slatex))
> 
> (install-data 'slatex
>               '("slatex.sty" "slatex-chicken.sty" "cltl.sty")
>               `((version ,slatex-version))) ;; If this makes sense?
> 
> The data-path-for-extension would return a unique directory for
> this extension in which it is free to dump its files.  I think this would
> make it easier to keep track of where everything is, especially if some
> extensions install a lot of files.
> 
> Alternatively, we could have a "data-path" procedure which works just
> like the "program-path" procedure, ie it could accept no args and return
> the $DATADIR path.  Then it would be up to eggs whether they want to
> create a subdirectory for their files or not.

Yes, I can imagine these would be useful. I'd hope that there would be
versions that respected installation-path, as well as versions that just
were based on the $DATADIR path. Some of the same issues I described
above would probably still arise.


-- 
Jim Pryor
address@hidden