From: Sebastian Wiesner <lunaryorn@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs development discussions <emacs-devel@gnu.org>,
Daniel Hackney <dan@haxney.org>, Dmitry Gutov <dgutov@yandex.ru>
Subject: Re: cl-defstruct-based package.el, now with ert tests and no external tar!
Date: Tue, 25 Jun 2013 14:19:08 +0200 [thread overview]
Message-ID: <CALf2awRh5SohoCR=gbr80GaH9XnSxD4vfG8rhgn_gQHnZm9Mpg@mail.gmail.com> (raw)
In-Reply-To: <jwvppvbc7mp.fsf-monnier+emacs@gnu.org>
2013/6/25 Stefan Monnier <monnier@iro.umontreal.ca>:
>> 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.
next prev parent reply other threads:[~2013-06-25 12:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 18:44 cl-defstruct-based package.el, now with ert tests and no external tar! Daniel Hackney
2013-04-04 1:55 ` Stefan Monnier
2013-04-05 16:32 ` Dmitry Gutov
2013-04-05 19:21 ` Stefan Monnier
2013-04-05 20:51 ` Daniel Hackney
2013-04-06 21:02 ` Ted Zlatanov
2013-04-07 0:43 ` Stefan Monnier
[not found] ` <jwv7gjt4arv.fsf-monnier+emacs@gnu.org>
2013-04-25 2:52 ` Daniel Hackney
2013-06-01 19:39 ` Dmitry Gutov
2013-06-04 21:25 ` Daniel Hackney
2013-06-05 15:10 ` Ted Zlatanov
2013-06-05 21:42 ` Dmitry Gutov
2013-06-24 12:44 ` Sebastian Wiesner
2013-06-25 1:19 ` Stefan Monnier
2013-06-25 12:19 ` Sebastian Wiesner [this message]
2013-06-25 13:58 ` Stefan Monnier
2013-06-25 17:32 ` Sebastian Wiesner
2013-06-25 18:23 ` Stefan Monnier
2013-06-25 20:43 ` Sebastian Wiesner
2013-06-26 0:28 ` Stefan Monnier
2013-06-25 22:07 ` Daniel Hackney
2013-06-26 23:04 ` Nic Ferrier
[not found] ` <CAMqXDZtwnS-qUs8vCghYun0JZVuzofy4sCTMqdSskB2jJ9fq=g@mail.gmail.com>
[not found] ` <jwvobd3mg6l.fsf-monnier+emacs@gnu.org>
2013-06-12 2:18 ` Stefan Monnier
2013-06-21 4:20 ` Stefan Monnier
2013-06-21 7:49 ` Dmitry Gutov
2013-06-21 14:56 ` Stefan Monnier
2013-06-24 23:38 ` Dmitry Gutov
2013-06-25 21:49 ` Daniel Hackney
2013-06-26 7:35 ` Dmitry Gutov
2013-06-27 9:38 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALf2awRh5SohoCR=gbr80GaH9XnSxD4vfG8rhgn_gQHnZm9Mpg@mail.gmail.com' \
--to=lunaryorn@gmail.com \
--cc=dan@haxney.org \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).