docker-emacs
docker-emacs copied to clipboard
Silex
Annoncements / Polls
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.
POLL
Recently Cask broke for images < 24.4 (https://github.com/cask/cask/issues/480). I have 3 options here:
- Remove Cask for all images.
- Remove Cask for images < 24.4.
- 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?
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.
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.
Philippe Vaucher writes:
So, here is the first poll:
Recently Cask broke for images < 24.4 (https://github.com/cask/cask/issues/480). I have 3 options here:
- Remove Cask for all images.
- Remove Cask for images < 24.4.
- 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
pythondependency. 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.
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.
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).
I’m late to reply, but I stopped using Cask years ago, and I’m pretty sure I don’t support < 25 anymore either.
@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.
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.)
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.
@purcell: feel free to unsubscribe 😉 I added you because I thought that you'd knew who to ping if I forgot someone 😅
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.
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.
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.
@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.
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.
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.
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.
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.
I still dream of using straight.el as a build tool somehow.
I would like that as well. See e.g. https://github.com/raxod502/straight.el/issues/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.
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.
I think the optimal solution would be to have a
-caskversion 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.
For more Cask alternatives see https://github.com/vermiculus/emake.el and https://github.com/alphapapa/makem.sh .
Note to self: also add eldev (https://github.com/doublep/eldev) in dev images
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
kegvariant 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.
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!
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.
I thought I was using alpine in CircleCI, but apparently I'm using the dev images and I can't remember why.
I will answer here.
@sirikid: thanks. Do you know what is broken? I mean, Emacs seems to work fine, I can install packages and everything. I see the recursive load but I don't really know where to investiguate.
I had this error with Alpine 3.12 (Emacs 26.3) on builds.sr.ht, but not with Alpine Edge (Emacs 27.1). Both are working fine now (3.12, edge).
Alpine images are a pain to make them work, I look at their repository and try to mimick the minimal amount of patches but still...
With my -ci refactor I could base all on ubuntu and have the images be quite small (500MB). We'll see if people really use alpine on the thread on my repo.
I also use alpine images whenever possible because they are smaller and I prefer apk over apt. I can try to help you with alpine issues when they occur.
@sirikid: ah, thanks! Last time I tried Emacs refused to build for obscure reasons. I also seem to remember a lot of dev packages were not available, like glib etc. I'll try to upgrade Alpine to 3.12 and ping you if I encounter issues.
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.
Based on the current size, the -ci ubuntu variants would be ~480MB (much smaller than the current alpine-dev). An alpine-ci would be around 250MB.
I think alpine is desirable but it's quite sensitive and thus is a pain to make Emacs build in a generic manner for all versions (I usually try to import the patches they use themselves in the alpine repo).
I also prefer the alpine-ci images. At least for the packages I use them for, the download of the docker image dominates the total CI time. This is also one of the reasons I moved away from Cask, the benefits were not enough to carry the Python runtime in the docker image.
Ok guys, it's done :rocket:
Check https://github.com/Silex/docker-emacs#images for more details. I'll keep Cask/Eldev for a few days in the dev image while you adapt your scripts then I'll remove it.
What I expect from you is to change from 27.1-dev to something like 27.1-ci or 27.1-ci-eldev for example. The images are currently building so be a bit patient :stuck_out_tongue_winking_eye:
@conao3: keg supports Emacs from 24.1 and up correct? @sirikid: eldev & alpine is still broken (see #69), help me fix this :wink:
@sirikid: eldev & alpine is still broken (see #69), help me fix this wink
Ok, I will check it again. I recently improved my Emacs debugging skills, hope this helps.
@conao3: keg supports Emacs from 24.1 and up correct?
Yes. (It may not be running on 24.1 at the moment, but in specification, keg works well on Emacs-24.1.)
Hi guys, 27.2 images should be building atm.
I think I'll drop the non-latest images of each major version, there are just too many images. That means I'd only keep 23.4, 24.5, 25.3, 26.3, 27.2 and master. Please argue about why you'd be against that.
And last but not least I'm trying to move to https://github.com/purcell/nix-emacs-ci/issues/29, that way the emacs binaries are the one from purcell and I just fight against alpine/arm32/arm64 instead of all fronts like I'm doing now with my limited time.
Any help welcome.
I think I'll drop the non-latest images of each major version, there are just too many images.
This makes sense!
I'm trying to move to purcell/nix-emacs-ci#29
I think moving towards Nix is a good way forward.
Currently I test my Emacs packages against each minor version as well. There are some reasons why that's mildly helpful:
- although you'd think minor version bumps would be smaller changes than major version bumps, they can often have similarly important changes in them---e.g.,
inhibit-messageadded in Emacs 25.3 specifically, rather than 25.1 - Ubuntu LTS doesn't always ship the most recent minor version, e.g. Ubuntu 18.04 shipped Emacs 25.2 rather than 25.3, and it's arguably somewhat useful to support Ubuntu LTS versions of Emacs since they are likely to be widely installed
But I will definitely admit that this falls into the realm of "mildly helpful", and I can't point to any specific reason why things would go wrong if we just stuck to the most recent release of each major version. If it makes maintenance more feasible, I won't object :)
Just let me know and I'll be happy to update my CI configurations to point to only the most recent release from each major version.
Oh, heh, I see you took care of removing the older images already, guess I'll update my CI now :P
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.
FYI to others who may need to update their CI, you should migrate to using
silex/emacs:25,silex/emacs:26, etc. rather thansilex/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 😉
@raxod502: sorry I missed your earlier message, but I see you managed to adapt 😆
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).
32 bit support was dropped, images use https://github.com/purcell/nix-emacs-ci, please report if anything breaks.
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 😢
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.
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.
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.
Also not using them myself, but I wonder if people using M1 Macs might have need of them?
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 (https://github.com/moby/moby/issues/22801, #38) to build Emacs < 28.
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.
It still does not build properly with QEMU, so I removed all arm64 images for now.