emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sebastian Wiesner
Subject: Re: cl-defstruct-based package.el, now with ert tests and no external tar!
Date: Tue, 25 Jun 2013 19:32:12 +0200

2013/6/25 Stefan Monnier <address@hidden>:
>> 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).

That is pretty unfortunate…

>
>> - "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.  The “new API” is much better than the old one with two
arguments.  And it's not too hard to handle this situation in Carton:
We'll just test for the presence of a "package-desc" constructor, and
use the new API in this case, or the old one otherwise.

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.

>> - "package-install" doesn't accept a package name anymore,
>
> It does (again).

Fine, thank you :)

>> Since most of these changes come from the introducing of
>> "package-desc" struct, I know that I am out of luck.
>
> Indeed.
>
>>> 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.
>
> 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")
- update the package archive contents (e.g. "package-refresh-contents"),
- and to get a list of upgradable and obsolete packages (uhm, don't
know, we currently call all sorts of internal "package-menu--*"
functions).

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.

>> For an end user, it's just a declarative way to specify all packages
>> used in her configuration,
>
> I'd like to move in that direction: instead of letting the user say
> "install foo" and "uninstall bar", I'd like her to configure the "list
> of installed packages" (so adding an element installs it along with any
> dependencies, and removing from the list uninstalls the package (if it
> was installed) along with any of the dependencies which aren't needed
> any more).
>
>> installable with a single shell command, but for a package developer,
>> it maintains an isolated, automated and repeatable package environment
>> for testing.
>
> As you've discovered, Emacs's development is very messy, so it's no
> wonder I've never felt the need for such a controlled testing environment.
>
>> Essentially, it's Bundler, but for Emacs Lisp.
>
> That tells me more about what is Bundler than about what is Carton
> (I've never used Ruby or any of its tools) ;-)

Oh, sorry, I didn't know this, or I would have used some other
analogy.  I just made the experience that people usually don't get
what Carton does until I drop the magical word "bundler" at which
point lights go on and everything's clear :)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]