Replace ElDev with Eask

[joshbax189]

Closes #243

As you can see from the diffs, the replacement is quite straightforward. I like Eask because of all the tools it allows you to bootstrap with a single command. Also the dev is quite active.

Looks like the successful action's running time went from 1m 40s down to 1m using Eask.

Changes

• use silex/emacs:ver-ci-eask image to cut out an install step
• move byte-compile-warnings setting from eldev file to all files
  Eask doesn't have a script preamble file like eldev, but I think putting this in each file is cleaner as it silences the warnings for
  users too.

Examples

• failing run
  Shows --debug stack trace.

Questions/Extra Comments

On the hack:
This is due to a quirk in package-install. It seems to ignore built-in packages when explicitly requested (e.g. (package-install 'transient) does nothing), but does upgrade built-in packages when they are dependencies (e.g. (package-install 'docker) triggers an upgrade of built in transient).

This was an issue for emacs 28, which has transient 0.3.7 built in.

Adding docker itself as a dependency (scoped to develop) and then manually uninstalling it leaves the environment intact. Since the dependencies are resolved by package.el anyway, the resulting installed dependencies match what we would expect by following the dependencies in the Eask file.

In my opinion, the packages in depends-on should override the built-in packages so that the environment does match what you would get by running (package-install 'docker). I'll make an issue for that in the Eask repo.

Let me know if there are any workflows from eldev that you use and I can find the Eask equivalent and maybe add them to the readme.

Cheers!

[Silex]

Ah, reusing the docker-emacs images is a genius idea 👍 😄

That's awesome thanks!

[Silex]

@joshbax189 did you get around to make the issue about depends-on on the eask repo? do you think the transient workaround is still needed?

[Silex]

Ah, actually the hack does not even work anymore:

https://github.com/Silex/docker.el/actions/runs/18870745106/job/53848281237

Installing 5 package dependencies...

  - [1/5] Installing aio (1.0)... done v
  - [2/5] Installing dash (2.20.0)... done v
  - [3/5] Installing s (1.13.0)... done v
  - [4/5] Installing tablist (1.1)... done v
  - [5/5] Skipping transient (0.10.1)... already installed X

(Total of 4 dependencies installed, 1 skipped)

[Silex]

Meh, the hack is still needed even tho the output is the same:

https://github.com/Silex/docker.el/actions/runs/18871365025

Weird.

[Silex]

Oh ok, using --dev triggers a silent install of the dependencies... 😞

[joshbax189]

IIRC, the underlying issue is package.el ignoring version numbers in some cases:

• installing transient directly, it ignores version number and just checks the package name
• installing transient as a dependency, this works correctly

The hack works by triggering the "install as a dependency" code path by including docker.el as a --dev dependency (not included when running eask install normally) then reusing the installed packages in the next build step.

There is also an issue with Eask displaying the wrong installed version number, in this case the "already installed" line has the wrong version number.

After poking it for a bit, I wasn't sure how I could sum it up in an issue that wouldn't devolve into a philosophical debate about what Eask should do: does it replicate package.el and what the package user would experience, or does it do exactly what the developer wants? OTOH, it is annoying...

So, in summary:

• the hack is still required
• I'll make an issue documenting it
• it will probably result in a "wont-fix" because package.el is wacky

[Silex]

@joshbax189 thanks!

Out of curiosity, I recently switched from package.el to straight, and it was very _straight_forward 😉

Is this something we can maybe leverage to "simplify" this issue?

Not a big deal, just curious.

[joshbax189]

it was very _straight_forward 😉

It is really nice isn't it! My gut feeling though, is that making the github action "too perfect" risks masking other issues that might come from package.el... I guess it's kind of like unit testing vs integration testing at the package level.

A separate point is that straight is aimed at users not package developers, so using it within the GH action might be awkward.

[Silex]

Ah, good points. Thanks, let's keep it like it is then.