Re: A flaw in current emacsen package setup?
- To: Rob Browning <email@example.com>
- Cc: firstname.lastname@example.org, Sam Hartman <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: A flaw in current emacsen package setup?
- From: Manoj Srivastava <firstname.lastname@example.org>
- Date: Mon, 03 Dec 2001 12:54:45 -0600
- Message-id: <[🔎] email@example.com>
- In-reply-to: <[🔎] firstname.lastname@example.org> (Rob Browning's message of "Mon, 03 Dec 2001 10:45:57 -0600")
- References: <[🔎] email@example.com> <[🔎] firstname.lastname@example.org>
[Please follow up to email@example.com]
>>"Rob" == Rob Browning <firstname.lastname@example.org> writes:
Rob> One thing I'm wondering about is how many packages modify the
Rob> load-path internally, rather than just in a small top-level
Rob> initialization file. If there are (m)any, then we may need to
Rob> do something sneakier like grabbing the load-path before running
Rob> all the site-lisp.d scripts, then comparing the load-path to the
Rob> saved copy and then rearranging load-path based on that to put
Rob> any additions "in the right place". Though we might want to do
Rob> this on a per-script basis, rather than just once for all of
Rob> site-start.d to avoid inter-dependency issues for packages that
Rob> have local overrides.
Umm. I am not sure we can capture instances of packages
modifying load-path internally -- since the files where modification
occurs may not be loaded after the site-lisp.d scripts are
Rob> Another option would be to have a slightly smarter
Rob> add-after-local, perhaps called emacsen-pkg-add-path that would
Rob> just handle the issue, using perhaps similar tricks to the
Rob> above, and then require all the add-on packages to use that.
Rob> The advantage here is that we can easily change the policy if
Rob> needed without any of the packages having to change their code.
That would be ideal. I was hoping you would suggest that ;-)
In which case, maintainers can edit any internal load-path
modification to go through emacsen-pkg-add-path as well.
Cynic, n.: One who looks through rose-colored glasses with a
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C