Packages for old Emacs versions

Packages for old Emacs versions

[Philip Kaludercic]

Hi,

reading [0], I would like to ask if there is any interest in
up-streaming the work I have been doing to build old versions of Emacs
using Guix (the main use-case is to help with testing Emacs packages on
various versions)[1]?  My fear is that with further upstream development,
there might be conflicts between the packages I inherit from (emacs,
emacs-no-x, emacs-minimal) and the packages I have definined in [1].
An easy fix might be to not rely on the upstream package definitions,
but I am not certain if there are any down-sides I haven't considered.

Of course, if the Guix project isn't interested in providing old
versions of packages, then I will continue look into maintaining my own
channel.

[0] https://guix.gnu.org/manual/en/html_node/Creating-a-Channel.html
[1] https://git.sr.ht/~pkal/guix-emacs-historical

-- 
	Philip Kaludercic

Re: Packages for old Emacs versions

[Thiago Jung Bauermann]

Hello Philip,

Philip Kaludercic <philipk@posteo.net> writes:

> reading [0], I would like to ask if there is any interest in
> up-streaming the work I have been doing to build old versions of Emacs
> using Guix (the main use-case is to help with testing Emacs packages on
> various versions)[1]?

This is a very interesting use of Guix!

> My fear is that with further upstream development,
> there might be conflicts between the packages I inherit from (emacs,
> emacs-no-x, emacs-minimal) and the packages I have definined in [1].
> An easy fix might be to not rely on the upstream package definitions,
> but I am not certain if there are any down-sides I haven't considered.
>
> Of course, if the Guix project isn't interested in providing old
> versions of packages, then I will continue look into maintaining my own
> channel.

I don’t have much experience with the Guix projects and its preferences
and practices, so I can’t tell if it would be interested or not,
unfortunately. I just wanted to mention that if not, another upstreaming
option could be the Guix-Past channel:

https://gitlab.inria.fr/guix-hpc/guix-past

-- 
Thanks
Thiago

Re: Packages for old Emacs versions

[zimoun]

Hi Philip,

If I read correctly, the repositority [1] provides many recipes which
create various Emacs VM.  Cool!

Well, from my point of view, these should live in a channel.  Maybe the
channel guix-past is a good location.  Somehow, it would be better to
have a channel with binary substitutes.

That's the easy part, somehow.  Using one of these old Emacs VM, then
the user cannot install any Emacs package via Guix -- because the Emacs
packages provided by Guix are bytecompiled by the emacs-build-system
using the package emacs-minimal and thus although the bytecode is
"stable", there is not guarantee that it is compatible.  Concretely,

    guix install emacs@24 emacs-foo

then 'M-x foo' and who knows if it would work.  The Emacs packages have
to be rebuild using the correct Emacs VM -- in the example Emacs 24.

From my point of view, the best is to use packages transformations.
Give a look at:

    https://issues.guix.gnu.org/41732

for instance, let say 'package-with-explicit-emacs' and it would ease to
get one old Emacs VM and Emacs packages build with it.  WDYT?


This 'package-with-explicit-emacs' could be provided by Guix itself;
which help for testing 'emacs-next', say.

The old Emacs VM could be in a channel, say guix-past.  Then, this very
same transformation could be applied.


Cheers,
simon

1: https://git.sr.ht/~pkal/guix-emacs-historical

Re: Packages for old Emacs versions

[Philip Kaludercic]

Thiago Jung Bauermann <bauermann@kolabnow.com> writes:

>> My fear is that with further upstream development,
>> there might be conflicts between the packages I inherit from (emacs,
>> emacs-no-x, emacs-minimal) and the packages I have definined in [1].
>> An easy fix might be to not rely on the upstream package definitions,
>> but I am not certain if there are any down-sides I haven't considered.
>>
>> Of course, if the Guix project isn't interested in providing old
>> versions of packages, then I will continue look into maintaining my own
>> channel.
>
> I don’t have much experience with the Guix projects and its preferences
> and practices, so I can’t tell if it would be interested or not,
> unfortunately. I just wanted to mention that if not, another upstreaming
> option could be the Guix-Past channel:
>
> https://gitlab.inria.fr/guix-hpc/guix-past

While interesting, this appears to be a closed project, so I am
uncertain how I could contribute my package definitions upstream.

Would it be unconventional for me to try and set up my own repository?

-- 
	Philip Kaludercic

Re: Packages for old Emacs versions

[Ludovic Courtès]

Hi,

Philip Kaludercic <philipk@posteo.net> skribis:

> Thiago Jung Bauermann <bauermann@kolabnow.com> writes:
>
>>> My fear is that with further upstream development,
>>> there might be conflicts between the packages I inherit from (emacs,
>>> emacs-no-x, emacs-minimal) and the packages I have definined in [1].
>>> An easy fix might be to not rely on the upstream package definitions,
>>> but I am not certain if there are any down-sides I haven't considered.
>>>
>>> Of course, if the Guix project isn't interested in providing old
>>> versions of packages, then I will continue look into maintaining my own
>>> channel.
>>
>> I don’t have much experience with the Guix projects and its preferences
>> and practices, so I can’t tell if it would be interested or not,
>> unfortunately. I just wanted to mention that if not, another upstreaming
>> option could be the Guix-Past channel:
>>
>> https://gitlab.inria.fr/guix-hpc/guix-past
>
> While interesting, this appears to be a closed project, so I am
> uncertain how I could contribute my package definitions upstream.

Contributions to Guix-Past are open to anyone.  Unfortunately, creating
an account on gitlab.inria.fr is pretty tedious (essentially you need to
put me as your “mentor” when applying for an account), in addition to
being annoying in the first place.

I think we could consider moving it to a more convenient place, be it
sr.ht, notabug.org, or even Savannah (in which case we’d use the same
workflow as with the rest of Guix).

Thoughts?

> Would it be unconventional for me to try and set up my own repository?

No, of course not.  It’s better if we can team up IMO, but if
maintaining your own repo works better for you, that’s okay.

Thanks,
Ludo’.

Re: Packages for old Emacs versions

[Philip Kaludercic]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Philip Kaludercic <philipk@posteo.net> skribis:
>
>> Thiago Jung Bauermann <bauermann@kolabnow.com> writes:
>>
>>>> My fear is that with further upstream development,
>>>> there might be conflicts between the packages I inherit from (emacs,
>>>> emacs-no-x, emacs-minimal) and the packages I have definined in [1].
>>>> An easy fix might be to not rely on the upstream package definitions,
>>>> but I am not certain if there are any down-sides I haven't considered.
>>>>
>>>> Of course, if the Guix project isn't interested in providing old
>>>> versions of packages, then I will continue look into maintaining my own
>>>> channel.
>>>
>>> I don’t have much experience with the Guix projects and its preferences
>>> and practices, so I can’t tell if it would be interested or not,
>>> unfortunately. I just wanted to mention that if not, another upstreaming
>>> option could be the Guix-Past channel:
>>>
>>> https://gitlab.inria.fr/guix-hpc/guix-past
>>
>> While interesting, this appears to be a closed project, so I am
>> uncertain how I could contribute my package definitions upstream.
>
> Contributions to Guix-Past are open to anyone.  Unfortunately, creating
> an account on gitlab.inria.fr is pretty tedious (essentially you need to
> put me as your “mentor” when applying for an account), in addition to
> being annoying in the first place.
>
> I think we could consider moving it to a more convenient place, be it
> sr.ht, notabug.org, or even Savannah (in which case we’d use the same
> workflow as with the rest of Guix).
>
> Thoughts?

Personally I would prefer an anything that doesn't use the GitHub-esque
"Pull Request" mechanism, and I guess as long as it is all Free
Software, Savannah should do the job.

>> Would it be unconventional for me to try and set up my own repository?
>
> No, of course not.  It’s better if we can team up IMO, but if
> maintaining your own repo works better for you, that’s okay.

I would certainly appreciate it, having run into a number of issues and
being frequently confused while writing the package definitions I had
linked above.

> Thanks,
> Ludo’.

-- 
	Philip Kaludercic