Annoncements / Polls

[Silex]

Hello!

@DamienCassou, @NicolasPetton, @gonewest818, @jgkamat, @dpsutton, @raxod502, @justinbarclay, @bbatsov, @purcell, @Fuco1

First of all, sorry for the notification. This is my attempt at solving the recurrent pattern of me asking you guys what you want. Futur annoncements / polls will be done here, so you can simply unsubscribe from this issue if you don't want me to ping you from time to time.

Please don't hesitate to @someone the ones I forgot or point them here (so they can subscribe to the issue), I'm only semi-aware of where my images are used.

[Silex]

POLL

Recently Cask broke for images < 24.4 (cask/cask#480). I have 3 options here:

1. Remove Cask for all images.
2. Remove Cask for images < 24.4.
3. Wait until the issue fixes itself in Cask.

My preference would go to 1 because I installed Cask for @DamienCassou, and he tells me he does not use Cask anymore. It also somewhat forces Cask on everyone and nowadays there are other package management tools.

So, who uses Cask in my images? This would also allow to remove the python dependency. If we remove Cask, who would like to keep the python dependency?

[Silex]

ANNONCEMENT

• All the images (except 23.4) are multiarchs (amd64 / i386 / arm64 / arm32).
• Added ping & wget to the dev images.
• Removed the unused environment variables.

[bbatsov]

I'm still using Cask for the tests of most of my Emacs projects, so I'd prefer 2). Not sure what's the state of Cask's development, but to my knowledge it still doesn't have any convenient alternatives.

[jgkamat]

Philippe Vaucher writes:

So, here is the first poll: Recently Cask broke for images < 24.4 (cask/cask#480). I have 3 options here: 1. Remove Cask for all images. 2. Remove Cask for images < 24.4. 3. Wait until the issue fixes itself in Cask. My preference would go to 1 because I installed Cask for @DamienCassou, and he tells me he does not use Cask anymore. It also somewhat forces Cask on everyone and nowadays there are many other package management tools. So, who uses Cask in my images? This would also allow to remove the `python` dependency. If we remove Cask, who would like to keep the python dependency?

I personally still use cask, but I don't currently depend on these images (I just went through all my projects) so removing them is fine from my point of view. However, If I did use these packages it would be very frustrating to see cask support simply dropped (with no upgrade path). Since this is an emacs package (and not a python one) I would assume few would mind the removal of python.

[DamienCassou]

I don't use Cask and I don't use Emacs < 25.

[Cask] still doesn't have any convenient alternatives.

What do you need that you find in Cask and not in makem.sh or eldev?

very frustrating to see cask support simply dropped (with no upgrade path)

Anyone can install anything on top of a Docker image. That's what users of other build systems use. Keeping Cask in the images is convenient for the Cask users because it makes their builds faster. But not having Cask in the image doesn't mean there is nothing one can do to get it back.

[Silex]

Thanks guys. I think this is enough evidence to keep Cask. I'll follow in the issue wether < 24.4 is still worth supporting (we don't support 23.4 already).

[gonewest818]

I’m late to reply, but I stopped using Cask years ago, and I’m pretty sure I don’t support < 25 anymore either.

[Silex]

@gonewest818: thanks, not caring about < 25 seems to be a trend here. Maybe in the future it makes sense to only support the latest version of each (e.g only 23.4, 24.5, 25.3, 26.3...) like the ruby images do.

[snogge]

I do still use the 23.4 image for some projects, but mostly because I've not been forced to stop. I've also stopped using Cask as I spent more time debugging that than working on my project.
For most of my projects, the download of the image takes more time than running the tests, making image size important. Excluding Cask and Python makes a big difference.
On the other hand I do not want to spend time installing packages as part of my test cycle. So I've got my own variant of the images that include the tools I need; bash, bzip2, git, make, tar. (Some of those might be included in the base image now.)

[purcell]

For my part, I'm just using my https://github.com/purcell/nix-emacs-ci/ with no Docker in sight, so I don't have a strong opinion on any of this, sorry.

[Silex]

@purcell: feel free to unsubscribe 😉 I added you because I thought that you'd knew who to ping if I forgot someone 😅

[Silex]

For most of my projects, the download of the image takes more time than running the tests, making image size important. Excluding Cask and Python makes a big difference

Maaaaybe I could start thinking about maintaining -cask variants but this gets annoying very quickly, as once you start to go down this road there are tens of variants.

@snogge: that said if you just use the base silex/emacs:VERSION without the -dev prefix there's no cask no dev tools or anything, so the image is small. If you use the alpine version it is even smaller. I couldn't find on your profile where you actually used my images (found projects that used EVM or custom docker images tho), so it's hard for me to really comment.

[conao3]

Thanks, @Silex to know this issue via ansi.el issue (I hopped some issues from the issue).
Sorry for this degrade by my change. The reason is here.

---

@bbatsov

I'm still using Cask for the tests of most of my Emacs projects, so I'd prefer 2). Not sure what's the state of Cask's development, but to my knowledge it still doesn't have any convenient alternatives.

Recently, keg.el registered to MELPA.
keg is an alternative Cask, written by pure Elisp.
By install keg instead of Cask, make images remove Python to reduce the image size.

[snogge]

I base my own images on the non-cask version. You can see my fork here https://github.com/snogge/docker-emacs . I'm not up to date with the latest development on master.

What I would like to do is to trigger a rebuild of my docker-files each time you push new images to dockerhub. So far I've not seen a way to do that, but I do very little work with docker so maybe I'm missing something obvious.

[Silex]

@snogge: thanks for your example. Your -ci variants are interesting. I'll consider them, between the basic images and the full blown dev images with the source.

[lassik]

How seamless is the transition from Cask to Keg? Cask also seems to be mostly elisp, with only the front-end script in Python; Keg is all elisp.

[conao3]

The Keg and Cask files have differences in syntax, so a few changes are needed.
As for the subcommands, they are almost identical.
In the future, make Keg work just fine for packages that don't have a Keg file.

[raxod502]

Maybe in the future it makes sense to only support the latest version of each

For now, straight.el supports Emacs 24.5 and later. None of my other projects even support that version. I think your suggestion is reasonable.

[Fuco1]

I still dream of using straight.el as a build tool somehow. I use Cask but only due to momentum on my older projects and it's slowly falling apart. Me and the other maintainers don't really put in the work anymore :/

I think the optimal solution would be to have a -cask version of the images, this is pretty common for other projects, like docker itself which maintains docker, docker-git, docker-dind etc.

[raxod502]

I still dream of using straight.el as a build tool somehow.

I would like that as well. See e.g. radian-software/straight.el#100. Half the time when I try to use Cask it just fails with an inscrutable package-archive-related error message and refuses to do anything.

[bbatsov]

Btw, today there's also https://github.com/doublep/eldev (another Cask alternative). I've played with it a bit and it seems pretty solid so far.

[Silex]

I think the optimal solution would be to have a -cask version of the images, this is pretty common for other projects, like docker itself which maintains docker, docker-git, docker-dind etc.

Yes I think I'll move toward that direction. -ci, -cask, -dev, etc. I'll make a proposal table.

[bbatsov]

I like that idea!

[snogge]

For more Cask alternatives see https://github.com/vermiculus/emake.el and https://github.com/alphapapa/makem.sh .

[Silex]

Note to self: also add eldev (https://github.com/doublep/eldev) in dev images

[Silex]

Okay eldev was added to the dev images which should be available in a few minutes.

About the table, let's start with something like this:

os	tag	tools
ubuntu	27.1	emacs/curl/gnupg/imagemagick
ubuntu	27.1-dev	[27.1] + git/source/gcc/devdeps
ubuntu	27.1-ci	[27.1] + git/make
ubuntu	27.1-ci-cask	[27.1-ci] + python/cask
ubuntu	27.1-ci-eldev	[27.1-ci] + eldev
ubuntu	27.1-ci-keg	[27.1-ci] + keg
alpine	27.1-alpine	emacs/curl/gnupg/imagemagick
alpine	27.1-alpine-dev	[27.1-alpine] + git/source/gcc/devdeps
alpine	27.1-alpine-ci	[27.1-alpine] + git/make
alpine	27.1-alpine-ci-cask	[27.1-alpine-ci] + python/cask
alpine	27.1-alpine-ci-eldev	[27.1-alpine-ci] + eldev
alpine	27.1-alpine-ci-keg	[27.1-alpine-ci] + keg

Questions:

• do all alpine variants make sense? who uses the alpine variants and which ones? Supporting alpine makes my life more difficult because of weird bugs.
• does keg variant make sense?
• any suggestions?

Keep in mind that this table makes sense to be presented like this, but in the real world it's the dev image that is built first and then the normal image COPY emacs from it.

[DamienCassou]

do all alpine variants make sense? who uses the alpine variants and which ones? Supporting alpine makes my life more difficult because of weird bugs.

I use the alpine variants usually because they are smaller which makes everything faster and puts less pressure on the build server. I won't mind much if you get rid of all alpine variants though. I only care about -ci.

does keg variant make sense?

I don't use keg nor do I plan to use it.

Thank you for your great work!

[conao3]

Cask is not maintained and there are no more new feature additions. (I'm saying as the maintainer of cask.)
Yes, Cask is already stable, but it can't keep up with Emacs, which is still evolving rapidly.
I think the move to Keg from Cask is a promise.

[raxod502]

FYI to others who may need to update their CI, you should migrate to using silex/emacs:25, silex/emacs:26, etc. rather than silex/emacs:25.3, silex/emacs:26.3, etc. which will break when a new minor version is released.

[Silex]

FYI to others who may need to update their CI, you should migrate to using silex/emacs:25, silex/emacs:26, etc. rather than silex/emacs:25.3, silex/emacs:26.3, etc. which will break when a new minor version is released.

That would only happen for silex/emacs:27.2 because there won't be any more release for the 25/26 series etc 😉

[Silex]

@raxod502: sorry I missed your earlier message, but I see you managed to adapt 😆

[Silex]

I'm not far from being able to switch to purcell's https://github.com/purcell/nix-emacs-ci

This means that 32 bit support will be gone and I'm currently trying to keep X support. I'll ping you when it goes live so you can report breakage (if any).

[Silex]

32 bit support was dropped, images use https://github.com/purcell/nix-emacs-ci, please report if anything breaks.

[Silex]

Hello,

Apparently giflib 4 support was dropped (https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/aliases.nix#L378), which means 23.4 X support will be complicated.

Then 25.3 now refuse to build on arm64 because Invalid function: "DEAD", the bugtracker suggests https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10749 but I wasn't able to fix it.

I'll try to build it "vanilla" like purcell does, but that means that X support will be gone 😢

[Silex]

Ok I disabled X for 23.4 only, and disabled arm64 for 25.3 (see #85).

[Silex]

The server that was lended to me to build arm64 images won't be available anymore in a while.
Honestly, building arm images was a real PITA and I'm more interested in getting rid of them than trying to save them at all costs.

If you are using the arm64 images please make some noise so we figure a way to maintain them.

[DamienCassou]

Honestly, building arm images was a real PITA and I'm more interested in getting rid of them than trying to save them at all costs.

@NicolasPetton and I have stopped depending on these images. Thank you very much for maintaining them for so long! We are very grateful.

[pataquets]

Not using it myself, but AFAIK, Docker build and push Github Actions can trivially build multi arch images, arm64 included. Won't it be of any help?
Just my 2c.

[raxod502]

Also not using them myself, but I wonder if people using M1 Macs might have need of them?

[Silex]

Not using it myself, but AFAIK, Docker build and push Github Actions can trivially build multi arch images, arm64 included. Won't it be of any help?

The problem is not getting an arm64 box for free, the problem is getting one where you can disable ASLR (moby/moby#22801, #38) to build Emacs < 28.

[Silex]

Also not using them myself, but I wonder if people using M1 Macs might have need of them?

You're correct. I guess I could try the QEMU route once more to check the latest version, but if it fails I just give up.

[Silex]

It still does not build properly with QEMU, so I removed all arm64 images for now.

[raxod502]

I don't think it should be a tragedy, as I believe on the M1 macs you can still run x86 images, it is just using some emulation which degrades performance. And it seems unlikely that performance is of critical concern for Emacs inside Docker.

[Silex]

There's an issue with manual builds of nix-emacs-ci so I dropped X support for now and use nix-emacs-ci directly.

I'm considering doing that anyway because not many people seems to care about X support and it speeds image build time, also it solves the problem of outdated master images.

[Silex]

I'll also remove dev images they feel uselesss. Basically now it's nix-emacs-ci in a docker image with ci tools.

[Silex]

Following on the "wrap nix-emacs-ci" idea, now all nix-emacs-ci versions are supported (a7c96ef). I plan on refactoring the code to make a simpler README and use a build matrix so most of the images.yml will go away.