From: Stefan <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org, rms@gnu.org, schierlm@gmx.de
Subject: Re: `make' written in elisp
Date: Sun, 02 Jan 2005 19:26:41 -0500 [thread overview]
Message-ID: <m1pt0nqt1q.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <x5d5wns9fs.fsf@lola.goethe.zz> (David Kastrup's message of "Mon, 03 Jan 2005 00:22:31 +0100")
[-- Attachment #1: Type: text/plain, Size: 4493 bytes --]
> 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).
It might still work, depending on how the configuration is done. I tend to
think that most of the autoconfiguration should be done upon use rather
than during installation, which basically implies "in elisp rather than in
autoconf".
> 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.
Yes, `install' does not impose a particular structure (it just looks
recursively for *.el files). But it would benefit from some conventions
(so it can safely ignore the contrib/foo.el or compat/bar.el files).
I can't find any documentation about the in-package layout used by XEmacs,
tho. Anybody knows where it's described?
> 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.
Right, it seems to be used only to discover whether a newer version is
available or not.
> 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.
`install' doesn't get involved with version management, dependencies, ...
It only tries to make it easier for users to install and setup external
packages. A package manager to also allow activation/deactivation/deletion
would be a natural addition.
> I am not convinced about the value of the centralized server approach
> to package management from XEmacs: it does not seem to lend itself
Since `install' specifically targets external packages, a centralized server
doesn't make much sense indeed. For XEmacs, it was probably
a good simplification.
> 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.
Not just tarballs but also single elisp files. Most elisp packages are
single files.
> 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.
Agreed.
> 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.
The DWIM-aspect of `install' (just look for *.el and *.info files) only
works up to a point. I've bumped into problems where some *.el files should
be ignored, or other problems where the *.info file doesn't have the `info'
extension, or where the info file simply doesn't exist and it's not clear
how to build it based on a bunch of *.texi files, ...
We could keep adding intelligence and heuristics, but it makes more sense to
devise some conventions.
> All of those certainly sound reasonable. In particular, I'd second having
> separate commands for installing system-wide and user-local packages.
Agreed, it makes more sense.
Stefan
PS: I attached my latest version, which is still "work in progress".
[-- Attachment #2: install.el --]
[-- Type: application/emacs-lisp, Size: 22759 bytes --]
[-- Attachment #3: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
next prev parent reply other threads:[~2005-01-03 0:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-30 19:31 `make' written in elisp Michael Schierl
2003-12-31 22:57 ` Richard Stallman
2003-12-31 23:14 ` Michael Schierl
2004-01-01 21:10 ` Richard Stallman
2004-01-01 21:37 ` Michael Schierl
2004-01-04 23:25 ` Stefan Monnier
2005-01-02 16:06 ` Richard Stallman
2005-01-02 23:22 ` David Kastrup
2005-01-02 23:55 ` Ralf Angeli
2005-01-03 0:07 ` David Kastrup
2005-01-03 0:25 ` Ralf Angeli
2005-01-03 4:32 ` Richard Stallman
2005-01-03 8:02 ` David Kastrup
2005-01-03 9:36 ` Eli Zaretskii
2005-01-03 16:45 ` Stefan Monnier
2005-01-03 9:10 ` Ralf Angeli
2005-01-03 18:29 ` Richard Stallman
2005-01-03 19:28 ` Ralf Angeli
2005-01-03 23:10 ` David Kastrup
2005-01-04 3:38 ` Richard Stallman
2005-01-04 11:17 ` Ralf Angeli
2005-01-03 0:26 ` Stefan [this message]
2005-01-03 11:05 ` Stephen J. Turnbull
2005-01-03 17:16 ` Stefan Monnier
2005-01-04 12:00 ` Stephen J. Turnbull
2005-01-04 13:59 ` Stefan
2005-01-04 14:07 ` Miles Bader
2004-03-31 22:31 ` patch for locate-file-completion? Nic Ferrier
2004-04-01 17:34 ` Richard Stallman
[not found] <E1CloEh-0004Sl-Hg@monty-python.gnu.org>
2005-01-04 16:10 ` `make' written in elisp Eric M. Ludlam
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1pt0nqt1q.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--cc=schierlm@gmx.de \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.