Put updated package.el in ELPA? (and cl-lib backport)

Put updated package.el in ELPA? (and cl-lib backport)

[Daniel Hackney]

Yeah, yeah, I'm obsessed with package.el. So sue me ;)

Since my branch of package.el wasn't ready in time for 24.3, I'd like to
distribute it via ELPA itself. This would let us develop new features
(like Org-based READMEs) and make them available to people without
having to wait for 24.4. Obviously, this is a big deal and, if not done
carefully, could break a lot of people's installations. Real care and
frequent testing would be needed to ensure a smooth rollout. Any changes
to "archive-contents" or "FOO-pkg.el" files would need to be backward-
and forward-compatible. Luckily, the current package.el is perfectly
fine with extra elements in "FOO-pkg.el" files as well as
"archive-contents".

Is this something you all think would be appropriate?

On a related note, my branch of package.el relies on `cl-lib' from 24.3.
It would be impractical to maintain two versions, one using
`cl-defstruct' and the other using `defstruct'. Since people should be
migrating towards `cl-lib' in general, this presents a problem: either
use `cl' and get byte compiler warning or use `cl-lib' and restrict your
audience to 24.3 users.

I propose an ELPA-installable package called `cl-lib' which would be
like 24.3's `cl', but in reverse. It would consist of a bunch of aliases
to the `cl' functions and macros so that authors on <= 24.2 could use
`cl-*' functions without excluding everyone not on 24.3.

Once someone upgrades to 24.3, they should be transitioned to the
built-in `cl-lib'. This could be done by setting the version number of
the ELPA `cl-lib' to be lower than the built-in version in 24.3 so that
when package.el is activating packages, it would see that there is a
newer version of `cl-lib' already loaded and skip the ELPA-based
`cl-lib'.

Thoughts?

--
Daniel Hackney

Re: Put updated package.el in ELPA? (and cl-lib backport)

[Stefan Monnier]

> Yeah, yeah, I'm obsessed with package.el. So sue me ;)
> Since my branch of package.el wasn't ready in time for 24.3, I'd like to
> distribute it via ELPA itself. This would let us develop new features
> (like Org-based READMEs) and make them available to people without
> having to wait for 24.4. Obviously, this is a big deal and, if not done
> carefully, could break a lot of people's installations. Real care and
> frequent testing would be needed to ensure a smooth rollout. Any changes
> to "archive-contents" or "FOO-pkg.el" files would need to be backward-
> and forward-compatible. Luckily, the current package.el is perfectly
> fine with extra elements in "FOO-pkg.el" files as well as
> "archive-contents".

> Is this something you all think would be appropriate?

I don't think that would solve the problem: we don't want to force
people to install a newer package.el to access GNU ELPA with Emacs<=24.3.

IOW the only solution is to make sure that whatever new feature we
implement does not break access with older package.el.

> I propose an ELPA-installable package called `cl-lib' which would be
> like 24.3's `cl', but in reverse. It would consist of a bunch of aliases
> to the `cl' functions and macros so that authors on <= 24.2 could use
> `cl-*' functions without excluding everyone not on 24.3.

I think that would be fine.  Even better if it also works for Emacs-23.


        Stefan

Re: Put updated package.el in ELPA? (and cl-lib backport)

[Daniel Hackney]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

"Stefan Monnier" <monnier@iro.umontreal.ca> wrote:

> > Is this something you all think would be appropriate?
>
> I don't think that would solve the problem: we don't want to force
> people to install a newer package.el to access GNU ELPA with Emacs<=24.3.
>
> IOW the only solution is to make sure that whatever new feature we
> implement does not break access with older package.el.

The version of package.el shipped with 24.2 is forward-compatible for both
-pkg.el files and archive-contents. It simply ignores any additional
attributes at the end of the package-desc vectors.

So older versions won't break, but they (obviously) won't use the the new
features.

> > I propose an ELPA-installable package called `cl-lib' which would be
> > like 24.3's `cl', but in reverse. It would consist of a bunch of aliases
> > to the `cl' functions and macros so that authors on <= 24.2 could use
> > `cl-*' functions without excluding everyone not on 24.3.
>
> I think that would be fine.  Even better if it also works for Emacs-23.

I'll look into it. I don't know the internals of cl at all. Is there
anything else needed other than a big giant pile of `defalias's?

[-- Attachment #2: Type: text/html, Size: 1492 bytes --]

Re: Put updated package.el in ELPA? (and cl-lib backport)

[Stefan Monnier]

> I'll look into it.  I don't know the internals of cl at all.  Is there
> anything else needed other than a big giant pile of `defalias's?

I haven't thought about it at all.
You can start with that.  You may bump into a few conflicts where
"cl-<foo>" already exists in the old cl.el.

Also it'd be good to make sure that code that works with your cl-lib.el
also works with the "real" cl-lib.el, i.e. pay attention to the few
subtle incompatibilities (e.g. cl-flet not being the same as flet).
This "compatibility cl-lib" should not aim to be a 100% equivalent to
cl-lib but only a faithful subset.  IOW better not provide cl-flet at
all than to provide cl-flet as an alias to flet.


        Stefan

Re: Put updated package.el in ELPA? (and cl-lib backport)

[Chong Yidong]

Daniel Hackney <dan@haxney.org> writes:

> The version of package.el shipped with 24.2 is forward-compatible for
> both -pkg.el files and archive-contents. It simply ignores any
> additional attributes at the end of the package-desc vectors.
>
> So older versions won't break, but they (obviously) won't use the the
> new features.

Which is a perfectly fine situation; I don't see the rush.  I'd rather
keep package.el a core Emacs package, tightly coupled to Emacs releases,
than deal with a ton of ugly compatibility code in package.el (or its
package) to make it work on Emacs < 24.3.