Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal)

[Nic Ferrier <nferrier@ferrier.me.uk>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IIUC by "ELPA" above I guess you mean GNU ELPA (since "ELPA and MELPA"
> would otherwise combine with "and" two things of different nature).
>
>> The multi-packages users load in their emacs are tars.  But the packages
>> that are checked in to ELPA are directories of files.
>            ^^^^^^^^^^^^^^^^^^
> So I think here you mean elpa.git (part of the greater GNU ELPA).

Excellent clarification. That's what I mean in this instance.


> Indeed.  Note that for all packages (even single-file packages) there
> are yet more build steps elsewhere:
> - the creation of the <foo>-autoloads.el.
> - the creation of the *.elc files.

No. Those are not build steps. Those are installation steps. The
package artifacts (the things delivered to end users) do NOT have
auto-loads files or elc files in them. If they do they shouldn't because
that's what Emacs package.el does when it installs them.

It should go:

  build -> release -> install

elpa.git and MELPA are promoting:

  release -> (build) -> install

I don't think it's bad that MELPA promotes that. That's their
business. But I do think it matters that elpa.git works that way.


> Note that there is a fair bit a pressure to *add* rather than remove
> magic steps (the first candidate in the list is to build the *.info
> files from the *.texi files).

I agree. If the build was clearly separated this pressure would move
away into the build tools.


>> And I am really starting to think we need better testing.  24.4 looked
>> like a slog to release and it still has many bugs.
>
> FWIW, I haven't heard of any case where the issues you're pointing out
> have resulted in actual problems.  The only real reliability problem
> I've heard about linked to ELPA packages is the issue of
> compiling/installing a package when an older version is
> already installed.

Ok... I'm not sure I've come across an elpa.git package that has bugs
because it wasn't tested. But then I don't use many right now.

But my point is we agree (don't we?) that moving stuff into elpa.git
from core is broadly right and I want to encourage a testing culture.

Why do we want to move things into elpa.git? because we can fix bugs and
add features quicker.


Nic