trim elixir version warnings post to half length

This commit is contained in:
russell@unturf.com 2026-03-19 07:47:20 -04:00
parent 83c98b7b9d
commit 4b502dbf09

View file

@ -16,72 +16,44 @@ If you run a Phoenix project on Ubuntu 24.04, you've seen these:
warning: the dependency :ecto_sqlite3 requires Elixir "~> 1.15" but you are running on v1.14.0
warning: the dependency :uri_query requires Elixir "~> 1.16" but you are running on v1.14.0
They compile. They pass tests. They run in production. So you ignore them. I ignored them for months.
Then I turned on ``--warnings-as-errors`` & my CI went red.
They compile. They pass tests. So you ignore them. I ignored them for months. Then I turned on ``--warnings-as-errors`` & my CI went red.
|
the problem
===========
Ubuntu 24.04 ships Erlang/OTP 25 & Elixir 1.14. Both arrived already behind the ecosystem when Noble launched in April 2024. The Hex package ecosystem moved to Elixir 1.15+ & 1.16+ minimum requirements throughout 2025. Phoenix 1.7 still compiles on 1.14, but its dependency tree doesn't agree.
Ubuntu 24.04 ships Erlang/OTP 25 & Elixir 1.14. The Hex ecosystem moved to 1.15+ & 1.16+ minimums throughout 2025. Phoenix 1.7 still compiles on 1.14, but its dependency tree doesn't agree.
The warnings mean: "this works today by accident, not by contract."
Dependency authors set minimum Elixir versions for a reason. They use features, they rely on behaviors, they test against those floors. When you run below the floor, you occupy a gap between "happens to compile" & "supported." That gap closes without notice the next time you ``mix deps.update``.
|
what I tried
=============
**Erlang Solutions apt repo.** Works. Installs current OTP & Elixir from a third-party PPA. Adds a dependency on a company maintaining packages for your distro version. When they stop, you stop.
**asdf / mise.** Version managers. Pin per-project via ``.tool-versions``. Flexible but adds moving parts to CI runners. A build server should not need a version manager to compile your project.
**Manual install from source.** Compiles fine. Now you own the upgrade cycle for two languages on every server that builds Elixir. Nobody wants that job.
Each approach works. Each adds a dependency you have to maintain. Each diverges from what ``apt install erlang elixir`` gives you. For a CI runner that builds multiple projects, that divergence compounds.
The warnings mean: "this works today by accident, not by contract." That gap closes without notice the next time you ``mix deps.update``.
|
what actually fixes it
======================
Ubuntu 26.04 LTS "Resolute Raccoon" drops April 23, 2026. I checked the package archive:
Ubuntu 26.04 LTS drops April 23, 2026. I checked the package archive:
- **Erlang/OTP 27.3** (package ``1:27.3.4.6+dfsg-1``)
- **Elixir 1.18.3** (package ``1.18.3.dfsg-1build1``)
- **Erlang/OTP 27.3** (``1:27.3.4.6+dfsg-1``)
- **Elixir 1.18.3** (``1.18.3.dfsg-1build1``)
That satisfies every version warning in the current Phoenix ecosystem. ``apt install erlang elixir`` on 26.04 gives you a supported toolchain with zero third-party repos.
The LTS-to-LTS upgrade path opens with 26.04.1 in August 2026. If you run an interim release (25.10), you can upgrade directly on April 23.
Every version warning disappears. ``apt install erlang elixir`` on 26.04 gives you a supported toolchain with zero third-party repos.
|
my recommendations
==================
**1. Don't chase the warnings today.** If your CI uses ``mix compile`` without ``--warnings-as-errors``, the warnings stay cosmetic. Your production release compiles with ``MIX_ENV=prod`` which doesn't run the test deps that generate most of these warnings anyway. Leave it alone.
**2. Don't add PPAs to your build server for Elixir.** Third-party repos on CI runners create invisible dependencies. When Erlang Solutions or RabbitMQ's PPA lags behind or drops your distro, your pipeline breaks & you don't know why. Distro packages break less often because the distro tests them together.
**3. If you need --warnings-as-errors now, pin your deps.** Lock the versions of swoosh, ecto_sqlite3, uri_query, & any other dep that complains. Older versions of those packages support Elixir 1.14. You lose upstream fixes but you gain a green pipeline. ``mix.lock`` already pins transitive deps — just stop running ``mix deps.update`` until you're ready to upgrade Elixir.
**4. Plan your upgrade for 26.04.** Mark April 23 on your calendar. Test your project against Elixir 1.18 & OTP 27 locally before the server upgrade. The jump from OTP 25 to 27 changes some behaviors (``Process.set_label/1`` exists now, ``rebar3_lint`` needs OTP 26+). Run your test suite against the new versions before you ``do-release-upgrade`` your build server.
**5. If you compile on the same server you deploy from, stop doing that.** Build & deploy should not share a filesystem. A CI runner compiles the release, ships the tarball, a different server runs it. The build server's Elixir version doesn't need to match production's Erlang — only the ERTS version baked into the release matters. Separate your concerns & the toolchain upgrade becomes a build-server-only change.
|
the real lesson
recommendations
================
The Elixir ecosystem moves faster than Ubuntu LTS packages. That gap opened in 2024 & won't close until April 2026. Two years of version drift.
**1. Don't chase the warnings today.** Without ``--warnings-as-errors`` they stay cosmetic. Production releases compile with ``MIX_ENV=prod`` which skips the test deps that generate most of these anyway.
This happens every LTS cycle. Ubuntu 22.04 shipped Python 3.10 while the ecosystem ran on 3.11. Ubuntu 20.04 shipped Go 1.13 while modules required 1.16. The pattern repeats because LTS freezes & ecosystems don't.
**2. Don't add PPAs for Elixir.** Third-party repos on CI runners create invisible dependencies. When they lag or drop your distro, your pipeline breaks & you don't know why.
The answer isn't "always use the latest." The answer is "know what your distro ships, know what your deps require, & plan the upgrade before the warnings become errors."
**3. If you need --warnings-as-errors now, pin your deps.** Older versions of swoosh, ecto_sqlite3, & uri_query support Elixir 1.14. Stop running ``mix deps.update`` until you're ready to upgrade.
Five weeks. Then ``apt install elixir`` does what it should have done all along.
**4. Plan for 26.04.** Test against Elixir 1.18 & OTP 27 locally before the server upgrade. The jump from OTP 25 to 27 changes some behaviors (``rebar3_lint`` needs OTP 26+, ``Process.set_label/1`` exists now).
**5. Separate build from deploy.** The build server's Elixir version doesn't need to match production's Erlang — only the ERTS version baked into the release matters.
|
This happens every LTS cycle. Ubuntu 22.04 shipped Python 3.10 while the ecosystem ran on 3.11. The pattern repeats because LTS freezes & ecosystems don't. Five weeks. Then ``apt install elixir`` does what it should have done all along.