Re: [clisp-list] common init invocation

[Pascal B. <pj...@in...>]

Samium Gromoff writes:
> On Mon, 2006-03-27 at 18:36 +0200, Pascal Bourguignon wrote:
> > Samium Gromoff writes:
> 
> [snip]
> 
> > The problem is that scripts may be put in /usr/local/bin and may be
> > used by any user.  All the users should have a ~/.clisprc file
> > compatible with the scripts!  This is difficult to ensure.
> 
> I think, scripts put in /usr/local/bin can have -norc in their
> #! header line. Does it solve the problem, or i`m misunderstanding
> something?

This is a question of what is the best default.

IMO, the best default is what is currently implemented.

 
> > So the best way is to put all initialization inside the script,
> 
> Sometimes putting all initialization inside the script doesn`t make
> sense or is even outright impossible.
> 
> Imagine a software package depending on some ASDF modules.
> 
> (Here depending means doing (asdf:oo 'asdf:load-op 'somemodule-1) etc.)
> 
> Imagine then that some user downloads this software package, but doesn`t
> have all of the ASDF modules installed system-wide.
> 
> So what he does is, he downloads these modules, and puts them somewhere
> like /home/me/cl/systems/.
> 
> Now all he has to do is to tell ASDF where it can find these modules.
> 
> And suddenly without some form of an init file this becomes a problem
> you need to solve for _every_ lisp software package, individually.
> Most likely, by changing its source.


Indeed this is a big deployment problem.

That's one thing that's sure, after my experience, is that you don't
want a script that works well the day you install it, to suddently
break  because some user installed some new version of an ASDF
package.  We're speaking here of production scripts, used to maintain
important servers running.  The scripts must be stand alone.  If they
need some ASDF library, then it should be deployed along the script.

Even my proposed solution to have a shared init file is good only if
you're prepared to run regression test on all the scripts you've
installed ever everytime you update it or its dependences.

For scripts with more dependencies, the only valid way to deploy them
in production is to save an image.


> I am not making it up -- you can see that usage of the init file is
> what is recommended in the ASDF manual:
> 
> > The variable asdf:*central-registry* is a list of "system directory
> > designators"1. A system directory designator is a form which will be
> > evaluated whenever a system is to be found, and must evaluate to a
> > directory to look in. You might want to set *central-registry* in your
> > Lisp init file, for example: 
> > 
> > 
> > (setf asdf:*central-registry*
> >   '(*default-pathname-defaults*
> >     #p"/home/me/cl/systems/"
> >     #p"/usr/share/common-lisp/systems/"))

"You *might* want",  and "*your* lisp init file".


> >     ( Once upon a time, I had a Makefile with:
> >       
> >       SCRIPT_NAME=exemple
> >       SCRIPT_SOURCES=init.lisp lib1.lisp lib2.lisp main.lisp
> >       all:$(SCRIPT_NAME)
> >       $(SCRIPT_NAME):$(SCRIPT_SOURCES)
> >            @echo '#!/usr/local/bin/clisp -q -ansi' > $@
> >            @cat $(SCRIPT_SOURCES) >> $@
> >            @chmod 755 $@
> >     )
> > 
> > or, if you have a lot of scripts that need the same initialization,
> > put this common initialization file in a common place, and explicitely
> > load it from each script:
> > 
> >     #!/usr/local/bin/clisp -q -ansi
> >     (load "/usr/local/share/clisp/script-init.lisp")
> >     ...
> 
> Probably this might be ok for software i write. But it also means that
> i`ll need to modify /all/ software using ASDF, with my
> site-and-user-specific script initialisation.

Perhaps you should cite specifics, because if you need to deploy some
software that's distributed as an ASDF system, you'd better check that
it doesn't depend on anything else, or that it builds an installable
image or set that doesn't depend on anything else.

It's really too easy to use ASDF-INSTALL:INSTALL to update to an
incompatible version of an ASDF system that will break your production
environment.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.