From: Tom Tromey <tromey@redhat.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: ELPA and EmacsWiki Updates
Date: Mon, 03 Sep 2007 14:59:37 -0600 [thread overview]
Message-ID: <m3bqcjjwhy.fsf@fleche.redhat.com> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICCEFKDPAA.drew.adams@oracle.com> (Drew Adams's message of "Sun\, 2 Sep 2007 18\:53\:59 -0700")
>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:
>> FWIW, the reason that Icicles is not in ELPA is that the Icicles
>> author did not want it there.
Drew> Hmm. That's not quite right, Tom. What I said at the time was
Drew> that it seemed (then) that some package system (possibly ELPA)
Drew> would soon be added to Emacs, and I was intending to wait to see
Drew> what Icicles changes might be needed to adapt it for use with
Drew> the (future) standard package system.
Ok. I must have misremembered, thanks for clearing that up.
Drew> However, it's also true that I said that (1) I appreciate the
Drew> simplicity of uploading to Emacs Wiki
Yeah. That is simpler, for sure. I considered having ELPA download
straight from the wiki, but I was not comfortable with the
uncontrolled aspect of it. My concern was that if ELPA became
commonplace, someone would upload a trojan.
Drew> I'm not too clear on what I would need to do - feel free to
Drew> contact me about it. Especially if it's just a one-time change,
Drew> and not too difficult, it's likely that I will do it.
I documented what to do for single-file packages on the web site. For
a multi-file package, you must:
* Put all the files into a .tar which has the package name and
version. The files must be in a directory of the same name. E.g.,
the package "emms-3.0.tar" the files must all appear beneath the
top-level directory "emms-3.0/"
* Make a -pkg.el file in the package. This holds the call to
define-package. E.g., "emms-3.0/emms-pkg.el". The define-package
call sets the version number, description, dependencies, etc.
* If you have a texinfo manual, make a .info file and a dir file and
put those in the package directory in the tar.
In other packages I've ELPA-ized, I made a 'make elpa' Makefile target
to run info, run install-info, set the version number in the -pkg
file, and make the tar.
Drew> Is there a way for ELPA to get stuff automatically from Emacs
Drew> Wiki - that is, stuff that has been made Elpable? That would be
Drew> a big help.
There isn't. For a multi-file package it would have to be pretty
complicated.
Drew> It would be great if library authors could simply upload to one
Drew> site and have the others feed off of that. (Via RSS? I don't
Drew> know anything about RSS, so don't laugh if it's irrelevant
Drew> here.) Emacs Wiki already mirrors the Emacs-Lisp List, but it
Drew> would, IMO, be much better the other way around: it would be
Drew> good if other sites that are more like simple repositories fed
Drew> off of the code posted to the wiki.
Yeah. For the Wiki the security issue concerns me quite a bit, but
maybe this could be fixed somehow. My plan for ELPA was to move to a
hosting site that would more easily allow multiple maintainers, but I
haven't done that yet.
Drew> The wiki has no notion of packages, however, so it would be
Drew> helpful if a package system such as ELPA could feed off of the
Drew> wiki somehow.
My experience based on looking at a *lot* of Emacs packages is that
the solution will never be as convenient for authors as "dump it on
the wiki". A nicely (IMO) functioning system will always require
meta-data; the typical Emacs Lisp program handles this by a comment
and dropping the problem on the user.
Drew> See my comments above. In my case, I don't make package
Drew> "releases"
[...]
Drew> I'm not against a package system, depending on what that means,
Drew> but it would be ideal, I think, if packages were more or less
Drew> virtual, updated automatically whenever a member file is updated
Drew> on the wiki.
I see. ELPA is not a good fit for what you want then. Most
non-trivial Emacs packages are developed along more traditional lines,
with releases and (non-wiki) version control, etc.
ELPA was designed to solve a few problems that I encounter:
* Download, install, and compile a package
* Automatically handle package dependencies
* Handle upgrading a package
* Handle the case where an external package is incorporated into Emacs
core but also has ongoing external development. This is the
requirement behind much of the versioning support -- the idea is to
always choose the newer package regardless of where it appears.
Tom
next prev parent reply other threads:[~2007-09-03 20:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-02 20:38 ELPA and EmacsWiki Updates Nordlöw
2007-09-02 21:05 ` Tom Tromey
2007-09-03 1:53 ` Drew Adams
2007-09-03 20:59 ` Tom Tromey [this message]
2007-09-03 23:28 ` Drew Adams
2007-09-06 0:14 ` Tom Tromey
2007-09-06 17:00 ` Drew Adams
2007-09-09 17:06 ` Tom Tromey
2007-09-09 18:46 ` Drew Adams
2007-09-09 20:37 ` Tom Tromey
2007-09-09 21:41 ` Drew Adams
2007-09-03 5:50 ` Edward O'Connor
2007-09-03 19:57 ` Tom Tromey
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/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3bqcjjwhy.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
/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).