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

[Daniel Hackney <dan@haxney.org>]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Well, the list is long:
>
> 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).

Part of the motivation for my changes was to give package.el more of
an API which would be usable by developers. There is certainly plenty
more which could be done, like having more of the refresh and
mark-upgradable functionality present in non-UI functions.

>>> What API?
>> Well, the package.el API, that is, "package-install",
>> "package-delete", "package-alist", and unfortunately a number of
>> internal functions ("package--*"), too, because the public API is
>> somewhat limited.

I separated things according to the principle of foo-public and
foo--private, so (theoretically) libraries using package.el should
only have to use package-foo functions and variables and none of
package--bar.

> 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.

I intended to define a public API which would be solid enough to be
considered stable(ish).

>> Essentially, it's Bundler, but for Emacs Lisp.

I had thought about/proposed something along similar lines when
looking into version-parsing libraries [1], but was told that since
Emacs is not a production environment, it's not worth worrying too
much about exact version compatibility ranges (as in "package foo
depends on package bar >= 1.2.3 and < 1.3.0). Given that MELPA uses
simple date stamps from development versions, fine-grained control
over dependency graphs does not seem to be that important.

But who knows, maybe the presence of better version management will
enable more complex dependencies.

[1] http://www.haxney.org/2010/03/comparing-emacs-version-parsing.html

-- 
Daniel Hackney