Re: cl-defstruct-based package.el, now with ert tests and no external tar!

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> Just to clarify: the reason why all this has changed without any
>> discussion is because there was not supposed to be any API.
>> `package.el' was only meant to provide an interactive UI, pretty much
>> (plus a few functions, basically the autoloaded ones).
> That is pretty unfortunate…

Agreed.  But that's what we have to work with.

>>> - "package-archive-contents" and "package-alist" have different
>>> contents now, because the package descriptors have changed,
>> Right.  This won't be "fixed".
>>> - "package-delete" takes a single argument only, but used to take two,
>> We could definitely "fix this".

> I didn't say you should “fix it”, and I don't think you should
> actually.

I thought so (it might have been worthwhile if it had been the last
incompatibility left).

> I just said that things would have been easier for us, if we had been
> made aware of these changes, e.g. by the NEWS file or some other kind
> of announcement.  Had I not followed this list, we would not have
> noticed these changes at all, and would probably have reported
> pointless bugs for them.

It would have been easier for us if you had announced Carton here (or
on gnu.emacs.sources or some such place), so we'd have known that
someone was using the actual code rather than the UI ;-)

>> Tell us what you need, then, and we can improve it.  As mentioned, what
>> you think as the public API doesn't even really exist, so the design is
>> very much open.

> Well, we need an API to
> - install packages by name (e.g. "package-install")

Done ;-)

> - update the package archive contents
>   (e.g. "package-refresh-contents"),

Done ;-)

> - and to get a list of upgradable and obsolete packages (uhm, don't
> know, we currently call all sorts of internal "package-menu--*"
> functions).

While the previous two sound "clear enough", this one has many
more options.  One possibility is to provide a `package-list' function
which returns all known packages.  Then you can use the (new)
package-desc-dir to know if it's an installed packages or a package from
an archive, and package-desc-status to figure out if it's obsolete (tho
making this function return symbols rather than strings would be
preferable if used like this).

> Another point on the wishlist would be to control all the output of
> package.el, mostly to suppress all sorts of byte-compiler and autoload
> generation messages which are meaningless to the user, unless there is
> an error.

I like for users to see the warnings, since it can give them a sense of
potential problems (e.g. if something is obsolete), and in the absence
of a maintainer (unmaintained packages are pretty much the rules rather
than the exception in Emacsland), it can be very useful: they may not be
able to fix it themselves, but at least they may bring it up so someone
else can fix it.

But having more control over this output (and prettifying it) would
indeed be very welcome.  It is fairly intimidating/overwhelming as
it stands.
Maybe we could try and make it possible to redirect it to a particular
buffer, so you can later on clean it up before displaying it.

> What languages do you use?  They might probably have similar tools…

Agda, Coq, Haskell, C, Elisp?


        Stefan