The load path

The load path

[Andy Wingo]

Hey all,

We all know know that guile is a great extension language. However,
these days I'm writing apps that are Just Guile -- no C frontend at all.
When doing so, I run into some issues with the load path.

First off, the load path for a guile in /usr/bin/guile doesn't
include /usr/local. I was discussing this with Rob today on IRC, and we
agreed that /usr/local should be added onto the load path for a guile
in /usr, so that local packages can be used without hacking LOAD_PATH.
Otherwise you have to run wrapper scripts/environment variable hacks
before running your code. This is analogous to the behavior of the C
compiler, and so shouldn't be too controversial. /usr/local should
precede /usr in the ordering, so that local changes override the
distribution's defaults. This is also in line with the behavior of the C
compiler. (Dunno if $prefix/local should only be added if $prefix==/usr,
or always.)

Secondly, guile's load path includes ".". This is unexpected. The set of
includes should not depend on the working directory of the user. Also,
as in the case of $PATH and $LD_LIBRARY_PATH, this exposes a security
risk. The only time I can imagine this as being useful is within a
source tree, when you control the environment anyway.

Obviously fixing these cannot be done in the stable branch, because it
will likely break people's code and hacks around the problem. But I'd
like to see it go in to guile 1.7. Sound OK?

Regards,
-- 
Andy Wingo <wingo@pobox.com>
http://ambient.2y.net/wingo/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Andy Wingo <wingo@pobox.com> writes:

> First off, the load path for a guile in /usr/bin/guile doesn't
> include /usr/local. I was discussing this with Rob today on IRC, and
> we agreed that /usr/local should be added onto the load path for a
> guile in /usr, so that local packages can be used without hacking
> LOAD_PATH.

I agree that it's probably a good idea, though I was a little
concerned about putting things in /usr/local in root's default path.

However, my concern may have been based on an incorrect assumption.  I
had thought that on many systems root's PATH did not include
directories in /usr/local/bin by default because on those systems
/usr/local was group staff, and membership in staff was not supposed
to be equivalent to root (security-wise).  If this is not a common
presumption, then my concern is irrelevant.

> Secondly, guile's load path includes ".". This is unexpected. The set of
> includes should not depend on the working directory of the user. Also,
> as in the case of $PATH and $LD_LIBRARY_PATH, this exposes a security
> risk. The only time I can imagine this as being useful is within a
> source tree, when you control the environment anyway.

Yes.  It's risky for all the same reasons that having . in your PATH
is.  The risk is a little less than it otherwise might be, since . is
at the end, but it's still a risk.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

I wonder about taking $PATH, and changing bin to share/guile, and
using that as the load path.  This seem possibly useful, but a little
hackish.  If there were a PREFIXES environment variable, and programs
constructed paths of all sorts from PREFIXES, that would seem less
kludgy.

Having /usr/local begs the question of whether on NetBSD /usr/pkg
should be included, but really this isn't important becaus 
compiling guile from pkgsrc results in /usr/pkg/share/guile being in
the load path from its own prefix anyway.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Marius Vollmer]

[ Andy, I discussed this with rlb on #guile, but I guess you weren't
  there at the time.  The below is a (subjectively filtered)
  summary. 
]

Andy Wingo <wingo@pobox.com> writes:

> First off, the load path for a guile in /usr/bin/guile doesn't
> include /usr/local.

Yes.  I am not sure whether it is good to single out /usr/local, tho.
There might be any number of directories that people could reasonable
expect to be in the load path, such as /opt/<package>/guile for a
Guile using <package>.

We do currently support "init.scm": This file gets executed at startup
immediately after boot-9.scm.  It is looked for in the load path.
That file is intended for site-specific initialization such as adding
/usr/local, /opt/<package> etc to the load path.

This does not address what should be in that file _by_default_.  In
fact, the Debian approach is to have a directory of init files that
all get executed in order, so that different packages can cleanly
deposit their own actions.

We think we should support this directly in Guile.  What about
executing this code at the end of boot-9.scm:

  (define (list-directory dir pattern)
    (let ((port (opendir dir))
          (regexp (make-regexp pattern)))
      (do ((entry (readdir port) (readdir port))
           (res '() (if (regexp-exec regexp entry) (cons entry res) res)))
          ((eof-object? entry) res))))

  (define (run-directory dir)
    (if (file-exists? dir)
        (for-each (lambda (f)
                    (load (string-append dir "/" f)))
                  (sort (list-directory dir ".*\\.scm$") string<?))))

  (run-directory (string-append (assq-ref %guile-build-info 'sysconfdir)
                                "/guile-" (effective-version)"
                                "/init.d"))

This will run every *.scm file in ${sysconfdir}/guile-1.x/init.d/ in
lexicographic order.

There can be additional rules about the contents of init.d/: Files
with names matching *site-local.scm are reserved for the site admin.
All filenames must start with at least two-digits, etc.

You could then add /usr/local to the load path from within init.d.

Packagers could do what is appropriate for their system by installing
a suitable file into init.d.  Etc.

Opinions, everyone?

> Secondly, guile's load path includes ".". This is unexpected. The set of
> includes should not depend on the working directory of the user.

Yes agreed, I have removed "." in HEAD.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Paul Jarc]

Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
> In fact, the Debian approach is to have a directory of init files
> that all get executed in order, so that different packages can
> cleanly deposit their own actions.

I like this idea.  But there should probably be a command-line switch
to disable loading these files.  For a parallel example with Emacs,
sometimes there is a site installation of Gnus, and the site init
files load part of Gnus, but the user may have their own newer copy of
Gnus that they want to use.  So they should be able to (and with
Emacs, they can) disable the normal loading of the site init files,
and then explicitly load them from their personal init file after
they've made the necessary load-path changes.

In the more common case, the site init file won't cause any trouble,
and the personal init file ought to be able to depend on the site init
file - which is why the site init stuff should be loaded first, which
is why disabling it has to be done with a command line switch instead
of something in the personal init file.

>   (define (list-directory dir pattern)

(use-modules ((ice-9 ftw) :select (directory-files)))

> There can be additional rules about the contents of init.d/: Files
> with names matching *site-local.scm are reserved for the site admin.
> All filenames must start with at least two-digits, etc.

I'm not sure the two-digit requirement will be useful.  Independent
packages won't know about each other, so they have no way to guess the
right order for their init files to be loaded in.  They should aim for
order-independence.  Then if it turns out there are ordering problems,
the admin can create earlier-named symlinks that fall in the right
order, and Guile can say "I've seen this device+inode before, I won't
load it again".  That check would also let packages' init files load
other init files they depend on, which solves the ordering problem
automatically, without having to guess numbers.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> There can be additional rules about the contents of init.d/: Files
> with names matching *site-local.scm are reserved for the site admin.
> All filenames must start with at least two-digits, etc.

I'd suggest that we might want to consider also reserving any name
starting with a 0 for the local admin.  This would allow the local
admin to create a file they know will be executed first.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> I like this idea.  But there should probably be a command-line
> switch to disable loading these files.  For a parallel example with
> Emacs, sometimes there is a site installation of Gnus, and the site
> init files load part of Gnus, but the user may have their own newer
> copy of Gnus that they want to use.  So they should be able to (and
> with Emacs, they can) disable the normal loading of the site init
> files, and then explicitly load them from their personal init file
> after they've made the necessary load-path changes.

Hmm.  We were thinking of having guile load from
${sysconfdir}/guile-X.Y/init.d/.  If the local version isn't installed
in the same place as the site installation, then it wouldn't try to
load the site's files by default.  However, if you did want it to load
them, you could just create a symlink to init.d, or make the init call
yourself.

Even so, perhaps a "--site-files DIR" option might be worth
considering.

> I'm not sure the two-digit requirement will be useful.  Independent
> packages won't know about each other, so they have no way to guess
> the right order for their init files to be loaded in.  They should
> aim for order-independence.  Then if it turns out there are ordering
> problems, the admin can create earlier-named symlinks that fall in
> the right order, and Guile can say "I've seen this device+inode
> before, I won't load it again".

(minor note: I had been thinking of one or more digits.)

We were modeling this after the normal sysvinit and Debian emacsen
approach.  i.e. /etc/rcS.d/ and /etc/emacs/site-start.d/.  Using
NUMBERname makes it very easy to predict what's going to happen.  With
the device+inode+visited-table approach, you can't easily tell what's
going to happen just by looking at the directory.

On the other hand, I can see the concern that the NUMBERname approach
is perhaps best suited for a situation where you have centralized
organization (i.e. a distribution).

We probably need a bit of further consideration here.

As background, one of the original reasons for our proposed changes is
to provide a standard place for distributions to put add-on package
files (a la emacs/site-start.d/).  The fact that this also lets us
move the site initialization file (init.scm) to /etc/ (by reserving
N*site-local.scm) is an added benefit that fixes a violation of the
FHS.

> That check would also let packages' init files load other init files
> they depend on, which solves the ordering problem automatically,
> without having to guess numbers.

That might argue for a use-modules or require/provide style solution,
though if appropriate, we'd want a modified one that only looks in the
init.d dir so that startup files can't be confused with files in other
packages (i.e. don't use load-path).

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Andreas Rottmann]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> [ Andy, I discussed this with rlb on #guile, but I guess you weren't
>   there at the time.  The below is a (subjectively filtered)
>   summary. 
> ]
>
> Andy Wingo <wingo@pobox.com> writes:
>
>> First off, the load path for a guile in /usr/bin/guile doesn't
>> include /usr/local.
>
> Yes.  I am not sure whether it is good to single out /usr/local, tho.
> There might be any number of directories that people could reasonable
> expect to be in the load path, such as /opt/<package>/guile for a
> Guile using <package>.
>
> We do currently support "init.scm": This file gets executed at startup
> immediately after boot-9.scm.  It is looked for in the load path.
> That file is intended for site-specific initialization such as adding
> /usr/local, /opt/<package> etc to the load path.
>
> This does not address what should be in that file _by_default_.  In
> fact, the Debian approach is to have a directory of init files that
> all get executed in order, so that different packages can cleanly
> deposit their own actions.
>
> We think we should support this directly in Guile.  What about
> executing this code at the end of boot-9.scm:
>
[snip]
>
> This will run every *.scm file in ${sysconfdir}/guile-1.x/init.d/ in
> lexicographic order.
>
After skimming the Debian Emacs Policy, I think there might be one
useful feature to copy: All emacsen have a /etc/emacs/site-start.d
directory in common, which is used in case there is no
/etc/<flavor>/site-start.d directory:

,----
|   This result is that .elc files will take precedence over .el files
|   in a given directory, and files in the <flavor> site-start.d
|   directory will take precedence over those in the emacs common
|   directory.
`----

This might be useful to support multiple versions of Guile on a
system, but nevertheless allowing packages that do not depend on a
specific Guile version to place their scripts into /etc/guile/init.d.


Just my 2 eurocent, 
     Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Software Patents: Where do you want to stifle inovation today?



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> If the local version isn't installed in the same place as the site
> installation, then it wouldn't try to load the site's files by
> default.  However, if you did want it to load them, you could just
> create a symlink to init.d, or make the init call yourself.

I'm thinking of the case where a user wants to avoid something the
admin put in the init code, or insert some other code ahead of it.
The user can't touch the sitewide init directory, so it can only be
controlled on the command line.

Disabling the init code is also a useful first step when tracking down
a problem - Emacs and Guile both have -q, and Emacs also has
--no-site-file.

> Using NUMBERname makes it very easy to predict what's going to
> happen.
...
> On the other hand, I can see the concern that the NUMBERname
> approach is perhaps best suited for a situation where you have
> centralized organization (i.e. a distribution).

Agreed on both counts.  My preference is to push work as far upstream
as possible (including when I'm upstream :) ), so I prefer systems
that let the individual packages easily cooperate so there's nothing a
distributor needs to do.

> As background, one of the original reasons for our proposed changes is
> to provide a standard place for distributions to put add-on package
> files (a la emacs/site-start.d/).

Packages' installation scripts could also find the site init directory
and insert their init files there.

> That might argue for a use-modules or require/provide style solution,
> though if appropriate, we'd want a modified one that only looks in the
> init.d dir so that startup files can't be confused with files in other
> packages (i.e. don't use load-path).

Maybe best practice would be to put the initialization code in a
normal module called (foo init), and then the init file merely loads
that module.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

/etc/guile/* is pleasing, since in my experience the fundamental
problem has been installing guile with one prefix, and a guile module
with another.  The user is expected to do

(use-modules (foo bar))

but not to have to mess with %load-path.

My own preference would lean toward having a clean, pkg-friendly way,
to drop a file in /etc/guile/ that would make e.g. the guile in
/usr/pkg be able to load modules installed in /usr/y0, by extending
%load-path.
This should be a file that perhaps gets called by convention
load-usr-y0.scm, or some such, so that a package that installs to a
different prefix can run some guile code (as root) to install the file
if it isn't there, something that feels like

guile-admin --persistent-load-prefix-path-add /usr/y0


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> I'm thinking of the case where a user wants to avoid something the
> admin put in the init code, or insert some other code ahead of it.
> The user can't touch the sitewide init directory, so it can only be
> controlled on the command line.

Ahh, so you don't mean the case where the user installed their own
copy of guile.  Ok, then for that, --disable-init-d might be good,
though "--init-dir /dev/null" might work too ;>

Having both options might make sense, i.e. --disable-init-dir and
"--init-dir DIR".

>> That might argue for a use-modules or require/provide style solution,
>> though if appropriate, we'd want a modified one that only looks in the
>> init.d dir so that startup files can't be confused with files in other
>> packages (i.e. don't use load-path).
>
> Maybe best practice would be to put the initialization code in a
> normal module called (foo init), and then the init file merely loads
> that module.

Hmm, but that won't allow the init file to set up the %load-path if
needed, i.e.

  init.d/package-a.scm: (use-modules (b init))

  init.d/package-b.scm: (set! %load-path (cons ... %load-path)) ...

So package-a's init will fail if it is run first.

I also think we may need at least enough documented convention that
the local admin can easily have a place to put their customizations,
and can have sufficient control over when they are run.

An alternate specification would be to require the init files to be
modules named (init.d foo), and just arrange for
${siteconfdir}/guile-X.Y/ to be first in the %load-path before guile
starts processing.  So package foo would install
guile-X.Y/init.d/foo.scm.

However I'm still a little unsure about crowding the init process
directly into the module namespace.  Perhaps that's the right thing,
but I'm not convinced yet.  It would mean that we'd have to reserve a
namespace like (init.d ...)  and it would mean that all of the (init.d
foo) modules would be visible to normal, non-init code, and there's no
reason for that.

It also still doesn't leave any way for the local admin to specify
configurations that are guaranteed to run at a particular time without
modifying all the other init files.

Here's a possible alternative:

  - specify ${siteconfdir}/guile-X.Y/init.d/ for "add-ons".

  - add a new bit of infrastructure.  A trivial guile module called
    something like (guile init) which provides:

      (guile-run-initialization . dir) ;; load INITDIR/* in order.
      (guile-init-require name) ;; load INITDIR/name.scm iff not loaded
      (guile-init-provide name) ;; called by INITDIR/name.scm on success

  - have guile look for ${siteconfdir}/guile-X.Y/init.scm at startup.
    If that isn't found, then have it run (guile-run-initialization
    "${siteconfdir}/guile-X.Y/init.d").

    However, if ${siteconfdir}/guile-X.Y/init.scm is found, guile just
    runs that.  So if the local admin creates an init.scm, then they
    need to add this to the file

      (use-modules (guile init))
      (guile-run-initialization "${siteconfdir}/guile-X.Y/init.d")

    if they want the normal startup behavior.  We'll also provide a
    skeleton init.scm to demonstrate this in our documentation.

  - add "--confdir DIR" and --disable-init command line options.

This approach would allow dependencies without conflating
initialization and the normal module namespace, and it seems like it
would allow the local admin a reasonable level of control.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> ,----
> |   This result is that .elc files will take precedence over .el files
> |   in a given directory, and files in the <flavor> site-start.d
> |   directory will take precedence over those in the emacs common
> |   directory.
> `----
>
> This might be useful to support multiple versions of Guile on a
> system, but nevertheless allowing packages that do not depend on a
> specific Guile version to place their scripts into /etc/guile/init.d.

Yes.  I'd planned to talk about that after we figured out the initial
structure.  In fact, I do think the Debian Emacs Policy's probably not
a bad example to consider[1], though I don't think we should worry
about trying to match it directly.

If we were to add something like the above, perhaps /etc/guile/X.Y/
and /etc/guile/common/ might be appropriate, but I'm tempted to put
this on the back burner for the moment.

([1] Bias disclaimer: I wrote it, in consultation with others.)

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

  Andy Wingo <wingo@pobox.com> writes:

  > First off, the load path for a guile in /usr/bin/guile doesn't
  > include /usr/local.

  Yes.  I am not sure whether it is good to single out /usr/local, tho.
  There might be any number of directories that people could reasonable
  expect to be in the load path, such as /opt/<package>/guile for a
  Guile using <package>.

>From reading this, I don't follow the direction of the current thread.
Perhaps it would be good to articulate what ought to work that doesn't
now.  The only thing I see is a way to install guile in one prefix, a
module in another, and then to somehow configure that second prefix's
share/guile to be searched by default by use-modules, load etc.

One could also want some code in the new module to be run for any
invocation of guile, but it's not clear that's a good idea as it more
or less violates the basic language definition and the provided
definition of that's in the (guile user) module.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> Ahh, so you don't mean the case where the user installed their own
> copy of guile.

Right - the user just installs a newer version of a module.  (Like
installing a new Gnus, but still using the system Emacs.)

> Having both options might make sense, i.e. --disable-init-dir and
> "--init-dir DIR".

Sure.

>> Maybe best practice would be to put the initialization code in a
>> normal module called (foo init), and then the init file merely loads
>> that module.
>
> Hmm, but that won't allow the init file to set up the %load-path if
> needed, i.e.

Ah, right.

Hmm.  ISTM modules are already good enough for everything except
tweaking %load-path, since that has to be done before the modules can
be found.  But if that's the only problem that needs to be solved,
then there's a very simple solution: have a directory full of
subdirectories that all get added to %load-path.  For a module
installed somewhere else, you can just drop a symlink in the central
directory, pointing to the module's directory.

So first augment %load-path unconditionally; then load the site init
code (optional, default yes); then load the user init code (optional,
default yes).

> It also still doesn't leave any way for the local admin to specify
> configurations that are guaranteed to run at a particular time without
> modifying all the other init files.

Let Guile load a site init file by default.  Distros will create that
file, and they can have it load a local-admin init file at the
appropriate spot (maybe even one at the beginning and one at the end).
People installing from source will create the site init file
themselves, since there's no distro sitting between them and Guile.

> This approach would allow dependencies without conflating
> initialization and the normal module namespace,

What sort of init code needs to be handled, other than %load-path
tweaking?

> and it seems like it would allow the local admin a reasonable level
> of control.

Yes, I'd say your approach is flexibile enough.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> Hmm.  ISTM modules are already good enough for everything except
> tweaking %load-path, since that has to be done before the modules
> can be found.  But if that's the only problem that needs to be
> solved, then there's a very simple solution: have a directory full
> of subdirectories that all get added to %load-path.  For a module
> installed somewhere else, you can just drop a symlink in the central
> directory, pointing to the module's directory.

I'm still a little concerned that use-modules might be practically
correct here, but semantically wrong, but I'm not sure yet.  I'm also
not sure that the init-require/provide approach is better.  The
question that troubles me is whether or not the "init-file" namespace
should be separate from the normal module namespace.

Overall, what I wanted was a way to specify a set of actions that will
be taken at init time, where the ordering can be easily specified,
where actions can be added and removed easily (i.e. by adding/removing
files), and where the local admin has a well defined way to make at
least some adjustments if necessary.

All of these actions (the files) should be editable by the local
admin, so they need to be placed in /etc according to the FHS
(i.e. automake's sysconfdir).  Further, at least for Debian, if
they're in /etc, they must be conffiles, and so they may need to stick
around and still function correctly (i.e. not break things) even if
the underlying package has been removed.  That's why in the
emacs/site-start.d/* files, you will see conditional code like this:

  (if (not (file-exists-p "/usr/share/emacs/site-lisp/autoconf"))
      (message "Package autoconf removed but not purged.  Skipping setup.")
    ... do the normal setup here which the admin might edit...
    )

Strictly speaking, the init files won't necessarily be modules,
although we could perhaps use that mechanism, but the questions are,
is it appropriate to use the module system for this, and should these
files still be visible to other use-modules calls, even after startup
is finished?  If not, then we shouldn't use the module system
directly, though we could probably share code.

In any case, having some dependency mechanism, as you've suggested,
wether it is use-modules or init-require/provide seems like a pretty
good solution, allowing ordering without relying on the sorting of
file names, and the local admin can still take some control by
creating an /etc/guile-X.Y/init.scm file, or perhaps adding their own
*-site-local.scm init.d files.

I do think that init.scm should be explictly reserved for the local
sysadmin (*not* for distributions).  The sysadmin should be able to
easily ignore (or filter) the distribution's init.d files if they so
choose, and init.scm would be the place to do that.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Greg Troxel wrote:

>  Andy Wingo <wingo@pobox.com> writes:
>
>  > First off, the load path for a guile in /usr/bin/guile doesn't
>  > include /usr/local.
>
>  Yes.  I am not sure whether it is good to single out /usr/local, tho.
>  There might be any number of directories that people could reasonable
>  expect to be in the load path, such as /opt/<package>/guile for a
>  Guile using <package>.
>
>>From reading this, I don't follow the direction of the current thread.
>Perhaps it would be good to articulate what ought to work that doesn't
>now.  The only thing I see is a way to install guile in one prefix, a
>module in another, and then to somehow configure that second prefix's
>share/guile to be searched by default by use-modules, load etc.
>
>One could also want some code in the new module to be run for any
>invocation of guile, but it's not clear that's a good idea as it more
>or less violates the basic language definition and the provided
>definition of that's in the (guile user) module.
>  
>
I agree. It seems to me that the only thing we need to support here is 
%load-path extension, and that we might find a neater solution by 
focussing only on that problem (as opposed to a means for executing 
arbitrary 3rd party code at startup time). Guile has important 
differences here from Emacs, so it doesn't follow that a good design for 
Emacs is also good for Guile.

Regards,
Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I agree. It seems to me that the only thing we need to support here
> is %load-path extension, and that we might find a neater solution by
> focussing only on that problem (as opposed to a means for executing
> arbitrary 3rd party code at startup time). Guile has important
> differences here from Emacs, so it doesn't follow that a good design
> for Emacs is also good for Guile.

One of the simlplest solutions is to load all the files in a
well-specified /etc dir in some order.  That's what Marius proposed,
and that's what Debian tends to do, both with Emacs, and with various
other things (ppp, ifup, cron, rc.?, etc.).

Paul then suggested that you might want to consider using dependencies
of some sort rather than just relying on a globally coordinated
ordering of file names.  I can see the argument in favor of that too,
though it would be less relevant if you're going to specify that these
files are only allowed to modify the %load-path.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> Overall, what I wanted was a way to specify a set of actions that will
> be taken at init time, where the ordering can be easily specified,
> where actions can be added and removed easily (i.e. by adding/removing
> files), and where the local admin has a well defined way to make at
> least some adjustments if necessary.

If the init actions are limited to %load-path tweaking, then I think a
directory-of-(directories|symlinks) is sufficient.  If the init
actions can go beyond that (which will be possible if they are
represented in Scheme files), then I'm not sure I want that to affect
every one of my Guile invocations.  I'm glad my shell scripts, Perl
scripts, Python scripts, etc., aren't all forced to load some
site-wide initialization code.  Scripts know what they need, and take
care of it themselves.  Arbitrary init code is convenient for
interactive interpreters, but I'm wary of establishing it for all
invocations.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Andreas Vögele]

Rob Browning writes:

> One of the simlplest solutions is to load all the files in a
> well-specified /etc dir in some order.  That's what Marius proposed,
> and that's what Debian tends to do, both with Emacs, and with
> various other things (ppp, ifup, cron, rc.?, etc.).

All this could be done from init.scm without changing Guile.  The only
thing that would be required is a new command-line option that
inhibits loading of init.scm so that users may skip the site-wide
initialization.

IMHO it would be okay to distribute an init.scm that loads init files
from a directory with Guile.  But please make it optional.  Packagers
could then decide whether to use that init.scm or not.  I don't see
why things that can be done outside of the Guile core should go into
the core.  The way Emacs loads init files on Debian is also not part
of Emacs and the same is true of ifup, cron etc.

What makes me especially wary is the fact that people have mentioned
Debian's init.d system in this thread.  I use Debian at work and at
home but I've never liked System V init scripts.  And Debian's
incarnation is by far the worst implementation of that scheme that
I've ever seen.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> If the init actions are limited to %load-path tweaking, then I think
> a directory-of-(directories|symlinks) is sufficient.  If the init
> actions can go beyond that (which will be possible if they are
> represented in Scheme files), then I'm not sure I want that to
> affect every one of my Guile invocations.  I'm glad my shell
> scripts, Perl scripts, Python scripts, etc., aren't all forced to
> load some site-wide initialization code.  Scripts know what they
> need, and take care of it themselves.  Arbitrary init code is
> convenient for interactive interpreters, but I'm wary of
> establishing it for all invocations.

After thinking about it further, I'm leaning toward agreement.  For
now, it might be best to stick with what we know we need:

  - move init.scm from its current location to
    ${sysconfdir}/guile-X.Y/.

  - add a configure argument that allows you to modify the default
    load-path.  One method I mentioned to Marius yesterday might be to
    add something like:

      --with-built-in-load-path='("foo" default "bar")'

    where this value is read, 'default expands to the default path,
    and we flatten any sub-lists.

Overall, I think it's a fair point that it may not be clear we need
generalized "startup actions" yet.  After a bit more consideration, I
realized I couldn't think of any Guile add-on packages that really
need them at the moment.  So unless we add features to Guile that do
require such actions (for Emacs, autoload settings are such a
feature), we should perhaps avoid any additional infrastructure.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Rob Browning wrote:

>Neil Jerram <neil@ossau.uklinux.net> writes:
>
>  
>
>>I agree. It seems to me that the only thing we need to support here
>>is %load-path extension, and that we might find a neater solution by
>>focussing only on that problem (as opposed to a means for executing
>>arbitrary 3rd party code at startup time). Guile has important
>>differences here from Emacs, so it doesn't follow that a good design
>>for Emacs is also good for Guile.
>>    
>>
>
>One of the simlplest solutions
>
For which problem, though?

> is to load all the files in a
>well-specified /etc dir in some order.  That's what Marius proposed,
>and that's what Debian tends to do, both with Emacs, and with various
>other things (ppp, ifup, cron, rc.?, etc.).
>  
>
Yes, I understood that; I'm currently inclined against the proposal.

In my view, the Emacs analogy doesn't apply, because

- Emacs is a user-focussed application where it is desirable for `M-x 
whatnot' to Just Work

- Guile is a developer-focussed application where explicit-ness is more 
important than automatic-ness, so it is preferable to require a script 
or an interactive user to say

  (use-modules (whatnot))
  (whatnot)

The ppp/ifup/cron analogy doesn't apply because these are all invoked 
automatically by the system without user intervention.  Guile on the 
other hand is always driven by a script, a specific program within which 
it is embedded, or by an interactive user; all of which have excellent 
existing mechanisms for executing any startup code that is needed for 
that particular use.

>Paul then suggested that you might want to consider using dependencies
>of some sort rather than just relying on a globally coordinated
>ordering of file names.
>
This is a good consideration if you accept the premise that it is 
desirable to execute arbitrary code here.  If you don't (which is my 
position), then it instead points to the dangers of adding unnecessary 
complexity.

>  I can see the argument in favor of that too,
>though it would be less relevant if you're going to specify that these
>files are only allowed to modify the %load-path.
>
>  
>
Absolutely.  %load-path ordering _could_ be important, but in my view we 
would have messed up if we allowed it to become so - see notes below on 
conflicts.

Here's how I think this area should work.

- On a non-distribution-managed machine, it is the machine admin's 
responsibility to set the needed %load-path in init.scm.

- On a distribution-managed machine...

  - The set of %load-path directories is a distribution decision, not a 
per-package decision.  In general, I think applications should be 
strongly encouraged to install their Scheme code in one of the 
distribution-wide %load-path locations, not in some application-specific 
directory (which would then need to be added to %load-path).  This is 
good for free software - because people can find the code more easily, 
and see it in context - and good for forcing us to deal with any naming 
conflicts properly instead of hiding them under the carpet.

  - There is a handful of meta-packages (e.g. KDE, Gnome) that are so 
big that it might make sense for them to have their own %load-path 
location.  But these are few enough that the distribution can include 
these in the distribution-wide %load-path from the start, even if those 
meta-packages are not actually installed.

  - Note that there is no need for a distribution mechanism to include 
/usr/local in the %load-path, system-wide, because the distribution does 
not use /usr/local.  If the sysadmin knows that the machine also 
contains non-distribution-managed software in /usr/local, he/she can of 
course add /usr/local to the load path in init.scm.  If a particular 
user wants /usr/local, he/she can extend the load path in their .guile.

  - Therefore a distribution can simply provide an init.scm that 
includes the distribution-wide load path.  init.scm can be treated as a 
conf file in the usual Debian way (i.e. not automatically overwriting it 
if the local admin has changed it, and so on).

I see no utility in doing something like adding all subdirs of a given 
directory to the load path.  use-modules already uses a hierarchical 
namespace, so instead the subdir name should be the first component of 
the module name.  I wonder if the real concerns here are of conflicts in 
module naming, and of handling different versions of the same module; 
both of which concerns would motivate being able to manipulate the load 
path so that the ordering of directories in it was important.  In my 
view, relying on the ordering of load path components is the way of 
madness (except in the particular-user-experimenting mode, where a user 
prepends their own directory to the load path in order to experiment), 
and it would be far better to agree guidelines for unique module names, 
and to work out a solution for module versioning.

Regards,
    Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Yes, I understood that; I'm currently inclined against the proposal.

See my recent reply to Paul.  After some thinking, I'm similarly
inclined.

>   - The set of %load-path directories is a distribution decision, not
> a per-package decision.  In general, I think applications should be
> strongly encouraged to install their Scheme code in one of the
> distribution-wide %load-path locations, not in some
> application-specific directory (which would then need to be added to
> %load-path).

Agreed, with the one caveat that until/unless we end up with some
better module versioning support, we may need a bit of policy, at
least within distributions that support multiple installed versions of
Guile.

Imagine there's a guile add-on module package foo.  Also imagine that
it works fine with guile-1.6 and guile-1.8, but not guile-2.0.  It
needs to be able to arrange for itself to be available via
(use-modules (foo)) in the first two cases, but not in the last.

One easy way to do that with the current system would be to just tell
the add-on packages to put their files elsewhere (say /usr/share/foo)
and then set up the right symlinks during installation:

   /usr/share/guile/1.6/foo -> ../../foo
   /usr/share/guile/1.8/foo -> ../../foo

Of course Guile still needs better support for multiple installed
versions, presuming we're interested in such support upstream (bin/*
in particular).  Otherwise, I can continue to just work on that in
Debian.

> In my view, relying on the ordering of load path components is the
> way of madness (except in the particular-user-experimenting mode,
> where a user prepends their own directory to the load path in order
> to experiment), and it would be far better to agree guidelines for
> unique module names, and to work out a solution for module
> versioning.

I agree completely.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> After thinking about it further, I'm leaning toward agreement.  For
> now, it might be best to stick with what we know we need:
>
>   - move init.scm from its current location to
>     ${sysconfdir}/guile-X.Y/.
>
>   - add a configure argument that allows you to modify the default
>     load-path.  One method I mentioned to Marius yesterday might be to
>     add something like:
>
>       --with-built-in-load-path='("foo" default "bar")'
>
>     where this value is read, 'default expands to the default path,
>     and we flatten any sub-lists.

oh, and and perhaps also

  - add a --no-site-init (or similar) command line argument.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Rob Browning wrote:

>Agreed, with the one caveat that until/unless we end up with some
>better module versioning support, we may need a bit of policy, at
>least within distributions that support multiple installed versions of
>Guile.
>
>Imagine there's a guile add-on module package foo.  Also imagine that
>it works fine with guile-1.6 and guile-1.8, but not guile-2.0.  It
>needs to be able to arrange for itself to be available via
>(use-modules (foo)) in the first two cases, but not in the last.
>
>One easy way to do that [...]
>  
>
Agreed. I'd just note that versioning also has to cope with the case 
where an add-on package A also provides an interface that further 
packages {B, C, ...} may use, so there is also a requirement for 
handling multiple installed versions of A, and for {B, C, ...} to be 
able to get the version that they need.

Unfortunately, I have no idea at this point how to solve such a problem!

Regards,
Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Agreed. I'd just note that versioning also has to cope with the case
> where an add-on package A also provides an interface that further
> packages {B, C, ...} may use, so there is also a requirement for
> handling multiple installed versions of A, and for {B, C, ...} to be
> able to get the version that they need.
>
> Unfortunately, I have no idea at this point how to solve such a
> problem!

One of the simplest ways I can think of to handle this (athough it's
not all that pretty) is for packages to just put something like a
"soname" in the module name.  i.e. (use-modules (foo-1)).  Then when
the API changes incompatibly, the author just changes the module name
to foo-2.  This is already the best way to solve the dynamic linking
problem, given the currently available dynamic linking facilities like
libltdl.  i.e. (dynamic-link "libfoo-2").

As far as use-modules is concerned, I can also imagine adding
something fancier like (use-modules (foo #:version 4)), which might
have more sophisticated semantics (like ld.so or something else).

There's a further complication if you want to try to handle problems
created when only some of the packages on a system have been upgraded
and there are multiple levels of dependencies,

   A -> B -> D                (-> means "depends on") 
   A -> C -> D

but the currently installed version of B depends on a different
version of D than the currently installed version of C.  This is also
a problem in the shared library arena, and as far as I know the
primary solution right now is to just say "don't do that".  A
distribution like Debian tries to make sure that the transition period
where such situations exists is a short as possible and only happens
in unstable (and maybe testing).

In any case, I suspect all of this will be the subject of some future
discussion.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Paul Jarc]

Neil Jerram <neil@ossau.uklinux.net> wrote:
> there is also a requirement for handling multiple installed versions
> of A, and for {B, C, ...} to be able to get the version that they
> need.

Slashpackage <URL:http://cr.yp.to/slashpackage.html> offers a
solution.  Let each version of each package be installed in its own
directory, and let each package find its dependencies via symlinks
kept in its own directory.
/path/to/A-1.0
/path/to/A-2.0
/path/to/B-*/deps/A -> /path/to/A-1.0
/path/to/C-*/deps/A -> /path/to/A-2.0

In the common case, the symlinks wouldn't need to single out a
specific version, so they could just point to /path/to/A, which is a
symlink to the "current version" of A.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Andy Wingo]

Hey folks,

Nice discussion. Sorry I was off the net for most of this. I'm replying
to Neil's mail because his POV represents the consensus, it seems. There
is one issue that still needs to be addressed.

On Sat, 2004-11-06 at 17:49 +0000, Neil Jerram wrote:
>   - Note that there is no need for a distribution mechanism to include 
> /usr/local in the %load-path, system-wide, because the distribution does 
> not use /usr/local.  If the sysadmin knows that the machine also 
> contains non-distribution-managed software in /usr/local, he/she can of 
> course add /usr/local to the load path in init.scm.  If a particular 
> user wants /usr/local, he/she can extend the load path in their .guile.

I disagree. When a user downloads an app, builds it and installs it,
they should be able to run it. On all configure scripts that I know
of, /usr/local is the default prefix. This is fine for C code: the
compiler will pick up headers, libs, and binaries from /usr/local, even
if the compiler comes from the distribution. Why should guile be any
different? Or to take your argument to its conclusion, why
include /usr/share/guile/site in the load path? After all, the distro
won't put anything there.

This is a bigger problem with libraries than apps, because apps can
munge the load path as appropriate.

Anyway, I hope I have convinced you of the bug report-hell lib and app
authors will get if the default install path isn't in the default guile
load path :)

[reordered]
>   - The set of %load-path directories is a distribution decision, not a 
> per-package decision.  In general, I think applications should be 
> strongly encouraged to install their Scheme code in one of the 
> distribution-wide %load-path locations, not in some application-specific 
> directory (which would then need to be added to %load-path).

Even for modules implementing functionality of an app, that aren't part
of its public interface? My instinct is to hide them, because then I
know they won't cause me problems in the future if someone uses them
somehow.

>   - There is a handful of meta-packages (e.g. KDE, Gnome) that are so 
> big that it might make sense for them to have their own %load-path 
> location.

I'll write another email about this, it's a bigger topic.

Cheers,
-- 
Andy Wingo <wingo@pobox.com>
http://ambient.2y.net/wingo/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

I agree that there is a problem, but I'm not comfortable with
hardcoding /usr/local.

On NetBSD 2.0, /usr/local/include is _not_ in the default search path
for the compiler.  One includes -I/-L if one wants that.

And, adding /usr/local to guile's search path (as opposed to the
prefix with which guile is built, which is already there) doesn't
really solve the problem - it just means that guile built with some
prefix and some module built with /usr/local will work, not any other
combinations.

Often people use prefixes to keep things separate.

With C libraries, techniques like pkgconfig find linking information,
but that's not available.  Even still, one has to muck with
PKGCONFIGPATH.

I think what's needed is first agreement about whether modules
installed in prefixes different from guile's prefix should be visible
to guile programs that don't set %load-path, and then how to do that
in the general case of two different prefixes.

One way that seems pretty simple is to have a directory in guile's
prefix that has files containing extra directories for %load-path, and
a guile utility that takes a prefix and ensures that a file for it is
in this directory.  Then, modules can simply call

guile-prefix-ensure $(prefix)

as part of the install process.  Alternatively, a similar per-user
directory could be used, so that one could do 'guile-prefix-ensure
--system' for the global one.

I've also symlinked module dirs from another prefix into guile's.
This isn't super clean, but it was easy.

Binary libraries for modules are another story; IMHO modules should
construct absolute paths for their own libraries from the configured
prefix, and not rely on search paths.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Andy Wingo wrote:

>I disagree. When a user downloads an app, builds it and installs it,
>they should be able to run it. On all configure scripts that I know
>of, /usr/local is the default prefix. This is fine for C code: the
>compiler will pick up headers, libs, and binaries from /usr/local, even
>if the compiler comes from the distribution. Why should guile be any
>different? Or to take your argument to its conclusion, why
>include /usr/share/guile/site in the load path? After all, the distro
>won't put anything there.
>  
>
I agree: when Guile is built and installed using "configure; make; make 
install", the default load path should certainly include /usr/local.  
That's not quite what I was addressing though; I was talking about the 
case where everything on a machine is there through package management - 
in this case /usr/local isn't needed because there isn't anything in 
/usr/local.

My thinking was, that as soon as you have a user who is prepared to do 
"configure; ...", you have a user who can edit init.scm to add any load 
path that isn't already there.  (E.g. the case where Guile is installed 
as a package, so is in /usr, but the user builds and installs an add-on 
.tar.gz themselves in /usr/local.)

>Even for modules implementing functionality of an app, that aren't part
>of its public interface?
>
Yes, absolutely!

> My instinct is to hide them, because then I
>know they won't cause me problems in the future if someone uses them
>somehow.
>  
>
But surely "using them somehow" is what Free Software is all about?

Regards,
    Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

  That's not quite what I was addressing though; I was
  talking about the case where everything on a machine is there through
  package management -
  in this case /usr/local isn't needed because there isn't anything in
  /usr/local.

And, at least on NetBSD, cc doesn't search /usr/local.  If guile does,
that's a bug :-)  So if things not in prefix get added to %load-path,
it would be nice to make it a configure-time option, perhaps a 

--load-path-prefixes=/usr/local,/usr/y0


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

>   That's not quite what I was addressing though; I was
>   talking about the case where everything on a machine is there through
>   package management -
>   in this case /usr/local isn't needed because there isn't anything in
>   /usr/local.
>
> And, at least on NetBSD, cc doesn't search /usr/local.  If guile does,
> that's a bug :-)  So if things not in prefix get added to %load-path,
> it would be nice to make it a configure-time option, perhaps a 
>
> --load-path-prefixes=/usr/local,/usr/y0

Did you see the suggestion in one of my last messages in this thread,
and if so, what did you think?

i.e. the one suggesting an option like this:

      --with-built-in-load-path='("foo" default "bar")'

among a couple of other things.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

        --with-built-in-load-path='("foo" default "bar")'

That looks good.  The question is whether that's about prefixes, or
actual directories.  It might be nice to have some way to specify
either, where prefix means the default list of places in a prefix.

It would also be nice to be able to include $prefix/lib/guile/site, so
that packages intended for guile ttn-1.4 work without needing a
symlink into share.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Rob Browning wrote:

>Greg Troxel <gdt@ir.bbn.com> writes:
>  
>
>>And, at least on NetBSD, cc doesn't search /usr/local.  If guile does,
>>that's a bug :-)  So if things not in prefix get added to %load-path,
>>it would be nice to make it a configure-time option, perhaps a 
>>
>>--load-path-prefixes=/usr/local,/usr/y0
>>    
>>
>Did you see the suggestion in one of my last messages in this thread,
>and if so, what did you think?
>
>i.e. the one suggesting an option like this:
>
>      --with-built-in-load-path='("foo" default "bar")'
>
>among a couple of other things.
>  
>
This looks good to me. If this option is not specified, I presume the 
default load path is ("$prefix/share/guile/site" 
"$prefix/share/guile/$effective_version" "$prefix/share/guile") - is 
that right?

Regards,
Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Greg Troxel wrote:

>        --with-built-in-load-path='("foo" default "bar")'
>
>That looks good.  The question is whether that's about prefixes, or
>actual directories.  It might be nice to have some way to specify
>either, where prefix means the default list of places in a prefix.
>  
>
I think the extras can be actual directories, as:

- it seems to me there isn't a strong need for extra prefixes: the point 
about .../1.6 versus .../site is to provide a distinction between code 
installed by the Guile install itself, and code installed by third 
parties; so $additional_prefix/share/guile/1.6 would usually be 
pointless and unused

- in the case where one explicitly wants to include the non-site 
directory of another Guile installation (dangerous though this sounds!), 
one can do so by listing it as an "actual directory"; also note that if 
one is doing such strange things, the $effective_version of the other 
Guile install might be different from the one being configured, so the 
prefix approach wouldn't help anyway.

>It would also be nice to be able to include $prefix/lib/guile/site, so
>that packages intended for guile ttn-1.4 work without needing a
>symlink into share.
>  
>
Out of interest, can you expand on this? What kind of file is installed 
there, and is that the only thing needed to make ttn-guile packages work?

Regards,
Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

Neil Jerram <neil@ossau.uklinux.net> writes:

> - it seems to me there isn't a strong need for extra prefixes: the
> point about .../1.6 versus .../site is to provide a distinction
> between code installed by the Guile install itself, and code installed
> by third parties; so $additional_prefix/share/guile/1.6 would usually
> be pointless and unused

The situation tha motivates this comment is e.g. when one installs
guile with --prefix=/usr/pkg (perhaps as part of pkgsrc, so it's semi
part of the OS), and then installs some guile module "foo bar" as
--prefix=/usr/y0 (not choosing /usr/pkg because every file in /usr/pkg
is supposed to be registered as part of the pkg db).  Then, one wants
to be able to (use-modules (foo bar)) in guile without fuss.  the foo
bar module source is nominally expecting to install in the same prefix
as guile, so it might have installed things in either
$prefix/share/guile or $prefix/share/guile/site.  (If it's not ok to
install in the former, a) please point me to the docs that say this
and b) explain why it's in the load path :-)

So, in the general case, to suppport packages in /usr/y0, one needs to
add /usr/y0/share/guile and /usr/y0/share/guile/site to %load-path -
the "standard" locations within the load path.
/usr/y0/share/guile/1.6 would be for _parts of guile_, and I agree
that this makes no sense for alternate prefixes.

I view 'site' as being a directory that can be shared among a group of
admin'd machines, but really it's like site-lisp in emacs and thus
local.  I put things in /usr/pkg/share/guile (no site) when they are
packaged rather than local.

> - in the case where one explicitly wants to include the non-site
> directory of another Guile installation (dangerous though this
> sounds!), one can do so by listing it as an "actual directory"; also
> note that if one is doing such strange things, the $effective_version
> of the other Guile install might be different from the one being
> configured, so the prefix approach wouldn't help anyway.

Sure, and I agree that this is odd.

> >It would also be nice to be able to include $prefix/lib/guile/site, so
> >that packages intended for guile ttn-1.4 work without needing a
> >symlink into share.

> Out of interest, can you expand on this? What kind of file is
> installed there, and is that the only thing needed to make ttn-guile
> packages work?

Sorry, I was too brief and used the wrong word.

ttn's guile supports binary modules (which I think are a cool thing,
despite also seeing the merits of the arguments that one should use a
scheme shim to load them and export symbols).  These are deprecated in
guile 1.6, but I really hope they don't go away, because it would make
guile-pg (PostgreSQL interface with automatic type conversion - very
spiffy) harder to use under the upcoming 1.8, and I don't see the harm
in leaving them as a deprecated feature.  Because these modules are
shlibs, rather than scheme, they are arch-dependent and can't go in
$prefix/share, and in ttn-guile they belong in LIBSITE_DIR, which is
normally $prefix/lib/guile/site:

> l -R /usr/pkg/lib/guile/site/
total 1
drwxr-xr-x  2 root  wheel  512 Nov 13 10:44 database

/usr/pkg/lib/guile/site//database:
total 144
lrwxr-xr-x  1 root  wheel     11 Nov 13 10:43 libpostgres.la -> postgres.la
-r--r--r--  1 root  wheel   2806 Nov 13 10:43 postgres-col-defs.scm
-r--r--r--  1 root  wheel   9882 Nov 13 10:43 postgres-meta.scm
-r--r--r--  1 root  wheel   3644 Nov 13 10:43 postgres-resx.scm
-r--r--r--  1 root  wheel  24073 Nov 13 10:43 postgres-table.scm
-r--r--r--  1 root  wheel  11345 Nov 13 10:43 postgres-types.scm
-rw-r--r--  1 root  wheel  43368 Nov 13 10:43 postgres.a
-rwxr-xr-x  1 root  wheel    898 Nov 13 10:43 postgres.la
lrwxr-xr-x  1 root  wheel     17 Nov 13 10:43 postgres.so -> postgres.so.0.0.0
lrwxr-xr-x  1 root  wheel     17 Nov 13 10:43 postgres.so.0 -> postgres.so.0.0.0
-rwxr-xr-x  1 root  wheel  47248 Nov 13 10:43 postgres.so.0.0.0

This is in ttn-guile's %load-path, but not in 1.6.  So, I symlinked
/usr/pkg/lib/guile/site/database into /usr/pkg/share/guile/site in the
pkgsrc entry for guile-pg:

> l /usr/pkg/share/guile/site/database
lrwxr-xr-x  1 root  wheel  32 Nov 13 10:43 /usr/pkg/share/guile/site/database -> ../../../lib/guile/site/database

This is a bit hackish, but was simpler and more self-contained than
adding a patch to guile's pkgsrc entry or trying to make guile-pg
install things someplace else.  (In general, pkgsrc entries try to
munge upstream software as little as possible, or at least that's my
philosophy for it.)

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Andy Wingo]

On Sun, 2004-11-14 at 10:48 +0000, Neil Jerram wrote:
> Rob Browning wrote:
> >      --with-built-in-load-path='("foo" default "bar")'
>
> This looks good to me. If this option is not specified, I presume the 
> default load path is ("$prefix/share/guile/site" 
> "$prefix/share/guile/$effective_version" "$prefix/share/guile")

This sounds good to me as well for 1.7, but with one reservation: there
are hordes of linux users that just do ./configure; make; make install
for all autoconf'd software they download. I don't want to have to tell
each one of them to set --prefix if they want the program to actually
work. This means, distributors must be made aware that guile should
follow the system C compiler's conventions, so that users are not
surprised.

Furthermore, if they put a /usr/local dir in the path, it should be
before the default paths.

It would be strange to require a configure argument --disable-broken in
order for your program to work.

Cheers,
-- 
Andy Wingo <wingo@pobox.com>
http://ambient.2y.net/wingo/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Greg Troxel wrote:

>The situation tha motivates this comment is e.g. when one installs
>guile with --prefix=/usr/pkg (perhaps as part of pkgsrc, so it's semi
>part of the OS), and then installs some guile module "foo bar" as
>--prefix=/usr/y0 (not choosing /usr/pkg because every file in /usr/pkg
>is supposed to be registered as part of the pkg db).  Then, one wants
>to be able to (use-modules (foo bar)) in guile without fuss.  the foo
>bar module source is nominally expecting to install in the same prefix
>as guile, so it might have installed things in either
>$prefix/share/guile or $prefix/share/guile/site.  (If it's not ok to
>install in the former, a) please point me to the docs that say this
>and b) explain why it's in the load path :-)
>
>So, in the general case, to suppport packages in /usr/y0, one needs to
>add /usr/y0/share/guile and /usr/y0/share/guile/site to %load-path -
>the "standard" locations within the load path.
>/usr/y0/share/guile/1.6 would be for _parts of guile_, and I agree
>that this makes no sense for alternate prefixes.
>
>I view 'site' as being a directory that can be shared among a group of
>admin'd machines, but really it's like site-lisp in emacs and thus
>local.  I put things in /usr/pkg/share/guile (no site) when they are
>packaged rather than local.
>  
>
I see your argument, and I think this is a useful clarification of 
.../guile vs. .../guile/site (I was previously wondering what the point 
of having both of these), but I'm afraid I'm still not convinced.

(1) If site is like site-lisp, then why does there need to be a site 
other than the one belonging to the Guile install itself?

(2) Even if there is a need, it's still nicer - because more explicit - 
to add both .../guile and .../guile/site independently to the configure 
option.

>ttn's guile supports binary modules (which I think are a cool thing,
>despite also seeing the merits of the arguments that one should use a
>scheme shim to load them and export symbols).  These are deprecated in
>guile 1.6, but I really hope they don't go away, because it would make
>guile-pg (PostgreSQL interface with automatic type conversion - very
>spiffy) harder to use under the upcoming 1.8, and I don't see the harm
>in leaving them as a deprecated feature.  Because these modules are
>shlibs, rather than scheme, they are arch-dependent and can't go in
>$prefix/share, and in ttn-guile they belong in LIBSITE_DIR, which is
>normally $prefix/lib/guile/site:
>  
>
Thanks for explaining.  I don't think I fully understand what's behind 
the lib vs. shared split.  (If shared is really shared, for example, how 
does it work that both <installation in $prefix/lib> and <installation 
in $prefix/shared> are 1:1 with <make install>?)  However, given also 
that the lib idea is currently controversial, I'm inclined to argue that 
this is a further motivation for saying that the arguments to the 
configure option should be complete additional directories, not 
prefixes. :-)

Regards,
    Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Neil Jerram]

Andy Wingo wrote:

>On Sun, 2004-11-14 at 10:48 +0000, Neil Jerram wrote:
>  
>
>>Rob Browning wrote:
>>    
>>
>>>     --with-built-in-load-path='("foo" default "bar")'
>>>      
>>>
>>This looks good to me. If this option is not specified, I presume the 
>>default load path is ("$prefix/share/guile/site" 
>>"$prefix/share/guile/$effective_version" "$prefix/share/guile")
>>    
>>
>
>This sounds good to me as well for 1.7, but with one reservation: there
>are hordes of linux users that just do ./configure; make; make install
>for all autoconf'd software they download. I don't want to have to tell
>each one of them to set --prefix if they want the program to actually
>work.
>
I'm not sure what you mean by setting --prefix each time.  All that the 
user needs to do is - once-off - add

(set! %load-path (cons "/usr/local/share/guile" %load-path))

to their .guile or the system init.scm.  And if the user can do 
./configure etc., I reckon they can do this.

(And who's to say that they haven't decided to install autoconf'd 
software in /opt/local, for example?)

> This means, distributors must be made aware that guile should
>follow the system C compiler's conventions, so that users are not
>surprised.
>  
>
Personally, I've been surprised in the past _by_ the C compiler's 
conventions.  I seem to recall having serious trouble with one version 
of Gtk in /usr and another version in /usr/local, because /usr/local 
comes _before_ /usr in the include path, but _after_ it in the linker 
path!  So - unless I was being really stupid at the time - not a good 
example to follow.

>Furthermore, if they put a /usr/local dir in the path, it should be
>before the default paths.
>  
>
I think it's probably unwise to set up a system so that ordering is 
important.  However, with the .guile/init.scm approach, the user has 
complete control here.

Regards,
    Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: The load path

[Greg Troxel]

  I don't think I fully understand what's behind
  the lib vs. shared split.  (If shared is really shared, for example,
  how does it work that both <installation in $prefix/lib> and
  <installation in $prefix/shared> are 1:1 with <make install>?)

Per the 4.4BSD conventions, from which the notion of /usr/share arose,
things in /usr/share must be architecture independent.  So no
executables, no shlibs, just text files and binary files that have the
same representation on all architectures.

On any machine, with make install, it's fine to put the appropriate
bits in both.  A symlink in /usr/share pointing to /usr/lib is ok too,
becaues the symlink is architecture-independent.  With this, one can
mount /usr from an arch-dependent place, and /usr/share from an
architecture-independent place.  This doesn't get used much, except
perhaps that for os installation sets the 'share' set can be the same
for all archs.

  I'm
  inclined to argue that this is a further motivation for saying that
  the arguments to the configure option should be complete additional
  directories, not prefixes. :-)

Sure, and I concur.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel