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

[Sebastian Wiesner]

2013/6/25 Stefan Monnier <address@hidden>:
>> The API *has* changed.
>
> It probably has, depends what you mean by API.  Since all the code is
> accessible, any change can break some external package.
>
> If something broke for you, then please say so explicitly, and we'll see
> whether we think it could/should be fixed, or whether you're just out
> of luck.

Well, the list is long:

- "package-archive-contents" and "package-alist" have different
contents now, because the package descriptors have changed,
- "package-delete" takes a single argument only, but used to take two,
- "package-obsolete-alist" is gone,
- "package-install" doesn't accept a package name anymore,
- etc.

Since most of these changes come from the introducing of
"package-desc" struct, I know that I am out of luck.

Interestingly, all the internal API that we use doesn't seem to have
changed.  "package-menu--generate" and "package-menu--find-upgrades"
work as before, and not less awkward to use.

>> We (that is, the Carton team [1]) “use” this API.
>
> 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.

>> [1]: https://github.com/rejeep/carton
>
> I don't understand what this does.  Could you give me some description
> of what is the benefit of such a tool, either for an end-user or for
> a developer of a package?

Carton creates isolated and independent package environments.

For an end user, it's just a declarative way to specify all packages
used in her configuration, installable with a single shell command,
but for a package developer, it maintains an isolated, automated and
repeatable package environment for testing.

Say, I develop a package "foo" which depends on dash.el and s.el, and
also on ERT and Ecukes for unit and integration tests.  I manage these
dependencies through Carton, and use "carton exec" to run my test
suite.  Now

- my "~/.emacs.d" packages are separated from the packages used to run
the tests of "foo",
- so my "~/.emacs.d" is not cluttered with all sorts of development
dependencies from various packages I write,
- and the test environment of "foo" is clean of any unwanted packages,
so I cannot accidentally use a function from a package that's present
in my "~/.emacs.d" but not specified as dependency,
- the test environment of "foo" is repeatable, and can be set up with
just a single shell command, whether on my personal laptop, the
desktop system of a new contributor, or a CI service like Travis CI,
- etc.

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