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: Stefan Monnier
Subject: Re: cl-defstruct-based package.el, now with ert tests and no external tar!
Date: Tue, 25 Jun 2013 09:58:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

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

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

> - "package-obsolete-alist" is gone,

Won't be "fixed" either.

> - "package-install" doesn't accept a package name anymore,

It does (again).

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

> 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) ;-)


        Stefan



reply via email to

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