Re: `make' written in elisp

[David Kastrup]

Richard Stallman <address@hidden> writes:

> A year after you posted it, I finally read the source code of install.el.
> (I was too backlogged to read source code last January.)
>
> I found that it was extremely clean and appealing code.  If a
> package system for Emacs can mean something like this, I am in favor
> of it.

Judging from the comments, this installer might more or less get along
at least with some XEmacs packages, as well as some other packages
with a regular enough structure (AUCTeX has in the mean time gotten a
new autoconf-based installer very similar to that of preview-latex, so
the latest versions probably will not work with install.el).

As far as I understand the XEmacs package system (at which I have
taken a cursory glance at best), it consists of several parts:

a) a directory layout.  XEmacs packages have a standard way of placing
Elisp, info, data and other files in a layout under the top package
directory.  In addition there are some standard file names for
initializing of packages and installation.  In short, this part of the
package system is basically just file layout conventions relative to a
package-specific top directory.

We don't have any conventions for packages intended for Emacs as far
as I can see.  It certainly would not be bad to have something like
that: if people make code for Emacs, and if we can agree on some
layout that makes it easier for stuff to work out of the box, it
certainly might be worthwhile to state some conventions.

b) version management.  Versions must basically be floats, higher
versions correspond to later versions, are usually based on some CVS
archive and not at all with actual package versions.  Uh.

c) a package manager that will download and upgrade packages.  It
might do so in user-specific and system-wide packages.

d) central download archives that will provide all packages, updated
by packagers (often different from the actual creators of software) on
central servers.

e) it does not offer AFAIR: dependencies and standard tests (for
executables, directories and other stuff) that autoconf provides.  A
bit of framework for that might be nice for obliterating some
necessities for installation.  Even though installing MSYS is not
particularly hard, it still seems to be a barrier for some people.


I am not convinced about the value of the centralized server approach
to package management from XEmacs: it does not seem to lend itself
overly well to getting reasonably updated packages from third
developers (who often have their own download areas from which they
offer their stuff, and those would not normally be visible to the
package manager that just looks at one server for all packages at one
time IIUC).

But I do think that we should try to offer some way of installing
external Lisp code if one has acquired it as a zip or tar archive in
some manner already.

And in those respects where the directory structure and layout
conventions of an XEmacs package would seem reasonable, there seems
little point in inventing something else.

Stefan, having met those problems when writing install.el already,
would probably be a lot more qualified to comment on my impressions
and on the versatility of the package layout he has been catering for.

> I would suggest some small changes.

[...]

All of those certainly sound reasonable.  In particular, I'd second
having separate commands for installing system-wide and user-local
packages.  IIRC (I might well be mistaken), XEmacs automatically
picked one or the other automatically, based on whether one had
previous private packages, and that was less than great.  In
particular, I tend to install a CVS version of Emacs into its own tree
(from my own user), and this means that I can, as a user, install
packages into this Emacs' system tree.  But that does not imply that I
don't want to install some stuff also in my user-local tree (which
would get shared by the regular Emacs as well).

Having separate commands would appear to be beneficial.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum