Re: Keeping an ELPA checkout

[Ted Zlatanov]

On Fri, 25 Mar 2011 17:12:57 -0400 Stefan Monnier <address@hidden> wrote: 

>> But ELPA packages are... packages!  Everything in emacs/lisp is source
>> code, meant to work as you describe.  Some ELPA packages happen to be
>> single-file libraries but you are trying to skip the installation and
>> activation steps which track dependencies, byte-compile, and adjust the
>> load path.  At least I don't think that's how it is supposed to work in
>> Tom Tromey's design.

SM> I know, but I don't think there's any fundamental good reason why we
SM> can't tweak emacs/lisp/Makefile.in so that it gets things to work.

They are packages, that's a great reason :)  Yeah, you can do it, but
it's going to break sooner or later.  I like Chong's approach better
than tweaking things.

Also, isn't it better to put the rules inside the GNU ELPA (thus the
"elpa" branch) than inside Emacs' lisp/Makefile.in, as Chong suggested?

>> Which I think are so people can install ELPA locally, edit things
>> locally, and reinstall the package when ready.  Does that help?  It can
>> probably be automated to be part of a "make local-activate-all" process.

SM> An important part of my use case is that files be used directly from the
SM> Bzr checkout.  Also I don't want to copy any of those files anywhere
SM> near my ~/ or ~/.emacs.d directory: everything should stay cleanly
SM> within the Bzr checkout.

Sure, I think that's what Chong had in mind too.  I'm pretty sure
package.el can do that (maybe a special load file will be needed though).

Ted