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

[Sebastian Wiesner <lunaryorn@gmail.com>]

2013/6/25 Stefan Monnier <monnier@iro.umontreal.ca>:
>> 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.
>
> It would have been easier for us if you had announced Carton here (or
> on gnu.emacs.sources or some such place), so we'd have known that
> someone was using the actual code rather than the UI ;-)

Well, you know now :)  Seriously, we didn't know that Carton was
getting so popular, and we can hardly announce each and every package
we write on this list, can't we?

>> - and to get a list of upgradable and obsolete packages (uhm, don't
>> know, we currently call all sorts of internal "package-menu--*"
>> functions).
>
> While the previous two sound "clear enough", this one has many
> more options.  One possibility is to provide a `package-list' function
> which returns all known packages.  Then you can use the (new)
> package-desc-dir to know if it's an installed packages or a package from
> an archive, and package-desc-status to figure out if it's obsolete (tho
> making this function return symbols rather than strings would be
> preferable if used like this).

That sound like a good idea.  It's a simple API that would fit all our
needs, and allow for much more cool tricks.

>> 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.
>
> I like for users to see the warnings, since it can give them a sense of
> potential problems (e.g. if something is obsolete), and in the absence
> of a maintainer (unmaintained packages are pretty much the rules rather
> than the exception in Emacsland), it can be very useful: they may not be
> able to fix it themselves, but at least they may bring it up so someone
> else can fix it.

Carton mostly targets developers for use in their packages.  These
have enough to do with warnings from their own packages, they can't
care for others.  On Github, many developers use it to run tests on
Travis CI.  In this case, the tons of output clutter the build log,
and make it hard to see whats actually going on.

> But having more control over this output (and prettifying it) would
> indeed be very welcome.  It is fairly intimidating/overwhelming as
> it stands.
> Maybe we could try and make it possible to redirect it to a particular
> buffer, so you can later on clean it up before displaying it.

That would be nice.  For now, we are thinking about just spawning
Emacs subprocesses to install packages, and catch and filter the
output of that subprocesses.

>> What languages do you use?  They might probably have similar tools…
>
> Agda, Coq, Haskell, C, Elisp?

Can "cabal" install packages locally?