RE: ELPA and EmacsWiki Updates

[Drew Adams]

> Drew> The ELPA version is likely to be stale, due to my laziness.
>
> Then that's another reason that ELPA is not a good match for your
> purposes.  I don't think it is too valuable to users to host stale
> packages.

I agree. On the other hand, some people will hear of ELPA and go to ELPA
looking for packages. They won't necessarily know, for instance, to look for
Icicles on Emacs Wiki. In that case, it could be helpful to make sure that
ELPA has Icicles, even if it is not necessarily the latest and greatest.

You might also consider hosting a list of "packages" or libraries that are
not Elpable, with links to where to obtain them. Yes, those links will
become outdated, but such a wide-ranging list could still help users. They
might go first to ELPA looking for things, and it would then serve also as a
directory of what is available. I'm guessing that you've considered this and
decided against it, but I'll still make the suggestion ;-).

> Drew> But why the constraint that a package have an overall
> version number?
>
> Here is a (semi-) real example.  ELPA includes EMMS.  But, I've heard
> that someday EMMS will be included in Emacs.  And, I suppose that EMMS
> will continue to be developed outside Emacs as well -- this is common
> for larger packages (gnus, erc, etc), especially because Emacs has a
> very slow release cycle.
>
> Suppose I install EMMS 3.0 now, then sometime later upgrade to Emacs
> 23 which (let's suppose) includes EMMS 3.1.  How does package.el know
> which EMMS to use?
>
> This is the scenario I wanted to solve -- one that has bit me numerous
> times over the course of my Emacs life.  Version numbers are a simple,
> conventional way to solve it.
>
> To continue the scenario, if EMMS 3.2 comes out, I can upload it to
> ELPA and folks can use it; and when they upgrade to Emacs 24 they
> won't have to do anything special.
>
> This isn't the only thing ELPA is good for, but it was one of the use
> cases I designed for.

That's clearly expressed, and I understand all that. My question is why
impose version numbers on _all_ "packages" just to make them available at
ELPA. IOW, the need for package versions for some packages does not imply
such a need for all packages.

You have a high standard for packages. You might consider also having a
lower standard with correspondingly less ELPA support, thus allowing lighter
weight packages to benefit from some of what ELPA offers. I'm thinking of
both users and authors here - not every library needs to be a buttoned-down
package at the level you've defined it, IMO. What's appropriate for a large,
communal project is not necessarily also appropriate for a simple but
perhaps multi-file library.

> Drew> Why not separate this physical packaging from the logical
> Drew> packaging that is simply declaring the set of needed files?
>
> I thought about things like this.  But, in the end I decided to try
> KISS as much as possible.  And it turns out that most packages fit
> nicely into this approach.

I understand. I have no idea how much work would be involved in an approach
such as I suggested. It's just something that seems good to me from the
point of view of users and authors - for at least some (e.g. simple)
packages.

> Drew> It would be great if an author could simply register a package
> Drew> description with your site, and have the site automatically
> Drew> periodically retrieve the requisite files from a specified
> Drew> source (which in my case would be Emacs Wiki).
>
> This opens the trojan door again.
>
> Also, IME it is rare for packages to be upload-ready.  They typically
> don't follow the comment guidelines.  Packages with dependencies on
> other packages need ELPA-specific comments as well.

Again, I have nothing against adding "package-level" comments that are
specific for ELPA.

It would be preferable, of course, to do that in a form that could be used
by multiple package systems, but perhaps it's not yet possible to
standardize that. I personally don't want to get into one format for ELPA,
another for GNU Emacs, another for ELL, and so on. But that's life, I guess.

> Your ideas are interesting though.  I'm just not sure they would work
> that well in practice.  E.g., I've looked through ELL numerous times.
> It is, unfortunately, full of broken links.  That is something that is
> inevitable with a multi-site approach.  Instead I was trying for
> something like "Ohio State Elisp Archive meets CPAN-ish trivial
> install".

I too used to use OSELA, until it fell off the edge of the Earth.

> Drew> Maybe I'm missing the boat here. The package system doesn't
> Drew> actually install packages for the user, does it? It just makes
> Drew> them available for download, right? And it controls (checks)
> Drew> dependencies and maybe other potential consistency gotchas,
> Drew> right?
>
> Nope, it does download, dependency resolution (both at activation time
> and download time), and install.  And deletion, too, whenever I get
> around to it.
>
> FWIW you can try out ELPA in just a couple minutes.  There's an
> auto-installer on the web page.  Run that, then:
>
> * M-x package-list-packages
> * "r" (re-reads the package list from ELPA)
> * "i" to mark for install, "x" to execute the installs
>
> I suggest 'bubbles' as a starter package.  After it is installed,
> M-x bubbles.

OK, will do.

> Drew> I can see why ELPA allows package versions, for example, but why
> Drew> would it require them for all packages it handles?
>
> Simplicity.  Honestly I didn't consider that there would be a package
> without a version.  Versioning is just, well, conventional and normal
> :).

So call me unconventional and abnormal ;-).

> Drew> I figured it was only downloading. How does ELPA help a
> user install and
> Drew> compile? Do you provide make files etc. that one can use on various
> Drew> platforms, or how does it work?
>
> ELPA takes a very simple approach.  It downloads the package and
> installs it in ~/.emacs.d/elpa/, then byte-compiles the .el files.  It
> also extracts autoloads.  If those things don't work, I simply don't
> upload the package.
>
> The auto-installer adds a line to your .emacs.  When Emacs starts,
> package.el will do a dependency check and activate whatever packages
> it can.  (So, e.g., you can change Emacs versions and things mostly
> still work.)

Ouch! I don't want to tell you what to do or not do, but I don't much like
the idea of something (even something I initiate) mucking with my .emacs.
Anyway, that's another story, and I'm sure you have good reasons for doing
it the way you do.

> Activation means modifying load-path and evaluating the autoloads.  If
> the package contains a 'dir' file, package.el also modifies the info
> path.

Ouch again!

I sure hope there is a foolproof way to uninstall - a way that backs out all
of the automatic changes that you make to a user's environment. Been bit by
this kind of "helper" tool too much to welcome it blindly.

> >> * Automatically handle package dependencies
>
> Drew> Dependencies between packages or just among the files of a package?
>
> Between packages.  E.g., lisppaste or weblogger require xml-rpc.  If
> you install one of the former, the latter will be installed.  Likewise
> for activation.
>
> One other big goal for ELPA was to take the pain out of installing
> Emacs Lisp packages -- to focus on the user experience.  We certainly
> could write something "dumb" (not meaning that in a bad way) that
> simply downloads a .el and drops it somewhere.  In my view this only
> solves part of the problem... dependencies matter too.  So do some
> things not easily enforceable in a tool: does the package have
> autoload comments in place?  Does it respect Emacs namespace rules?
> Key-binding rules?  Etc.  I do try to review packages for things like
> this before uploading (e.g., that is why quilt.el isn't there).
>
> So, part of the mission here is raising the standards for Emacs
> add-ons.

Please consider not necessarily raising the standards for all Emacs add-ons
to the same level. Not every contribution needs to be at your level of
"packageness", IMO.

> Drew> Is it also OK if there is no notion of upgrading, for some package?
>
> Since version numbers are assumed, all upgrading means is, install a
> newer version.

Right. I meant is it OK if there is no notion of version number. The answer
seems to be no.

> Anyway, I hope I've answered your questions.  I didn't answer them all
> since I thought some of the answers would be redundant given other
> answers.  If I missed something important I'm happy to talk and talk
> about ELPA :-)

Yes, thanks.