unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
Subject: Re: The load path
Date: Wed, 10 Nov 2004 20:43:52 +0200	[thread overview]
Message-ID: <1100112232.3368.19.camel@localhost> (raw)
In-Reply-To: <418D0EAE.40703@ossau.uklinux.net>

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


  parent reply	other threads:[~2004-11-10 18:43 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-16 17:52 The load path Andy Wingo
2004-10-17 19:40 ` Rob Browning
2004-10-17 23:13 ` Greg Troxel
2004-11-05 15:05 ` Marius Vollmer
2004-11-05 15:25   ` Paul Jarc
2004-11-05 16:43     ` Rob Browning
2004-11-05 17:43       ` Paul Jarc
2004-11-05 18:59         ` Rob Browning
2004-11-05 19:22           ` Paul Jarc
2004-11-05 22:05             ` Rob Browning
2004-11-06  7:25               ` Paul Jarc
2004-11-06 16:19                 ` Rob Browning
2004-11-06 22:58                   ` Rob Browning
2004-11-05 16:15   ` Rob Browning
2004-11-05 17:31   ` Andreas Rottmann
2004-11-05 18:57     ` Greg Troxel
2004-11-05 19:07     ` Rob Browning
2004-11-05 19:19   ` Greg Troxel
2004-11-05 23:53     ` Neil Jerram
2004-11-06  4:54       ` Rob Browning
2004-11-06 14:38         ` Andreas Vögele
2004-11-06 17:49         ` Neil Jerram
2004-11-06 21:21           ` Rob Browning
2004-11-07 18:46             ` Neil Jerram
2004-11-07 21:16               ` Rob Browning
2004-11-09 15:22               ` Paul Jarc
2004-11-10 18:43           ` Andy Wingo [this message]
2004-11-11 13:23             ` Greg Troxel
2004-11-12 21:31             ` Neil Jerram
2004-11-13  0:22               ` Greg Troxel
2004-11-13  1:08                 ` Rob Browning
2004-11-13 16:12                   ` Greg Troxel
2004-11-14 11:02                     ` Neil Jerram
2004-11-14 14:05                       ` Greg Troxel
2004-11-18 19:44                         ` Neil Jerram
2004-11-19 14:46                           ` Greg Troxel
2004-11-14 10:48                   ` Neil Jerram
2004-11-15 16:43                     ` Andy Wingo
2004-11-18 19:54                       ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1100112232.3368.19.camel@localhost \
    --to=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).