* Packages for old Emacs versions @ 2022-03-06 15:40 Philip Kaludercic 2022-03-08 1:20 ` Thiago Jung Bauermann 2022-03-08 12:05 ` zimoun 0 siblings, 2 replies; 6+ messages in thread From: Philip Kaludercic @ 2022-03-06 15:40 UTC (permalink / raw) To: guix-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packages for old Emacs versions 2022-03-06 15:40 Packages for old Emacs versions Philip Kaludercic @ 2022-03-08 1:20 ` Thiago Jung Bauermann 2022-03-13 20:53 ` Philip Kaludercic 2022-03-08 12:05 ` zimoun 1 sibling, 1 reply; 6+ messages in thread From: Thiago Jung Bauermann @ 2022-03-08 1:20 UTC (permalink / raw) To: Philip Kaludercic; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packages for old Emacs versions 2022-03-08 1:20 ` Thiago Jung Bauermann @ 2022-03-13 20:53 ` Philip Kaludercic 2022-03-15 8:08 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Philip Kaludercic @ 2022-03-13 20:53 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packages for old Emacs versions 2022-03-13 20:53 ` Philip Kaludercic @ 2022-03-15 8:08 ` Ludovic Courtès 2022-03-16 16:08 ` Philip Kaludercic 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2022-03-15 8:08 UTC (permalink / raw) To: Philip Kaludercic; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packages for old Emacs versions 2022-03-15 8:08 ` Ludovic Courtès @ 2022-03-16 16:08 ` Philip Kaludercic 0 siblings, 0 replies; 6+ messages in thread From: Philip Kaludercic @ 2022-03-16 16:08 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packages for old Emacs versions 2022-03-06 15:40 Packages for old Emacs versions Philip Kaludercic 2022-03-08 1:20 ` Thiago Jung Bauermann @ 2022-03-08 12:05 ` zimoun 1 sibling, 0 replies; 6+ messages in thread From: zimoun @ 2022-03-08 12:05 UTC (permalink / raw) To: guix-devel; +Cc: Philip Kaludercic 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-03-16 16:54 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-03-06 15:40 Packages for old Emacs versions Philip Kaludercic 2022-03-08 1:20 ` Thiago Jung Bauermann 2022-03-13 20:53 ` Philip Kaludercic 2022-03-15 8:08 ` Ludovic Courtès 2022-03-16 16:08 ` Philip Kaludercic 2022-03-08 12:05 ` zimoun
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.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).