* Put updated package.el in ELPA? (and cl-lib backport)
@ 2012-11-02 18:01 Daniel Hackney
2012-11-02 22:58 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Hackney @ 2012-11-02 18:01 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Put updated package.el in ELPA? (and cl-lib backport)
2012-11-02 18:01 Put updated package.el in ELPA? (and cl-lib backport) Daniel Hackney
@ 2012-11-02 22:58 ` Stefan Monnier
2012-11-02 23:24 ` Daniel Hackney
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2012-11-02 22:58 UTC (permalink / raw)
To: Daniel Hackney; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Put updated package.el in ELPA? (and cl-lib backport)
2012-11-02 22:58 ` Stefan Monnier
@ 2012-11-02 23:24 ` Daniel Hackney
2012-11-03 2:22 ` Stefan Monnier
2012-11-03 11:23 ` Chong Yidong
0 siblings, 2 replies; 5+ messages in thread
From: Daniel Hackney @ 2012-11-02 23:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Put updated package.el in ELPA? (and cl-lib backport)
2012-11-02 23:24 ` Daniel Hackney
@ 2012-11-03 2:22 ` Stefan Monnier
2012-11-03 11:23 ` Chong Yidong
1 sibling, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2012-11-03 2:22 UTC (permalink / raw)
To: Daniel Hackney; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Put updated package.el in ELPA? (and cl-lib backport)
2012-11-02 23:24 ` Daniel Hackney
2012-11-03 2:22 ` Stefan Monnier
@ 2012-11-03 11:23 ` Chong Yidong
1 sibling, 0 replies; 5+ messages in thread
From: Chong Yidong @ 2012-11-03 11:23 UTC (permalink / raw)
To: Daniel Hackney; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-11-03 11:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-02 18:01 Put updated package.el in ELPA? (and cl-lib backport) Daniel Hackney
2012-11-02 22:58 ` Stefan Monnier
2012-11-02 23:24 ` Daniel Hackney
2012-11-03 2:22 ` Stefan Monnier
2012-11-03 11:23 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.