Elixir 1.6 has been released but I cannot see any Elixir 1.6 debian package in the Erlang solutions repository. What is happening?
What is happening?
That package is maintained by Erlang Solutions, not the Elixir core team. Considering 1.6.0 was released just 5 days ago, it’s reasonable to assume Erlang Solutions hasn’t yet released a new Debian package.
You could try contacting Erlang Solutions and asking for an ETA on a new package release, or if in a hurry, use an alternative package system/installation method like GitHub - asdf-vm/asdf: Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more, GitHub - taylor/kiex: Elixir version manager or building from source.
1 Like
As a general rule, if you haven’t added an external repository to a package manager, it’s likely maintained by a separate maintainer for that package manager, not the people making the thing itself. I’d recommend going with an alternative installation method for both Erlang and Elixir (I personally use kerl for Erlang and exenv together with elixir-build for Elixir).
Lots of people are very happy with asdf, as @pma already mentioned. It also deals with installs for other things/languages, so it’s a good bet it could serve you even outside of Elixir.
It’s not done by the core team but it is still documented as the official way to install it at this page: https://elixir-lang.org/install.html#unix-and-unix-like. This is confusing because one would expect the package to be ready for the release.
Thanks for the suggestions of using other package system, nonetheless I prefer to avoid as much as possible and installed from source.
Then I would suggest that you go to the following page: Debian -- Error
There you’ll see who the maintainers are for debian’s elixir package and you can contact them to get it up to date. Don’t be afraid to get involved with your Linux distribution and the things that it uses. It’s because people like you care that there are maintainers for package managers that aren’t part of the core team. If you’re excited about Debian and you’re seeing something being done less efficiently than it should be, make sure it gets done.
Note that using the debian package isn’t “from source” in that it’s not actually compiling from source and it’s not “from source” in that it doesn’t come from the Elixir team.
1 Like
Thanks. To clarify: I did a git clone and compiled the source.
@gon782 the OP is referring not to the official debian package for Elixir, but to the separate third-party Erlang Solutions package repository: Index of debian/pool
1 Like
In general, you should prefer third party package managers over out-of-tree-builds.
If though, by building from source you mean, creating a proper DEB file and installing this in your system, thats of course the best thing you can do if the correct version is not (yet) available in upstream package repositories.
Therefore I’d suggest the following order of installation methods:
- Official package sources of a distribution
- Third party repository (PPA, overlays, community repositories, however they are called in the context of your package manager)
- Manually creating a local package and install from that
- Use a third party package or environment manager
- Wait for the package beeing available via 1 to 4
- Do an out-of-tree-build from source
- Copy precompiled binaries bliendly into your harddrive
Option 4 can of course become the only valid option when you often have to change the version of a tool.
Options 2 and 3 may swap around depending on corporate policies or the clients demands, but in such cases often nothing but option 1 is valid anyway…
Even though I prefer option 4 over 6 and 7, they all have a problem in common: They make your package database come out of sync. They force you to install libraries manually. When you remove something installed by the means of this methods, your package manager wont realize that you do not need libfoo anymore, but also the other way around is true. Your package manager wont realise that you need a libbar as well when you install the new version of X-lang. You have to track those dependencies by hand and in worst case scenaries you have to do that even cross project and on multiple workstations…
Yes, my bad. Literally all of the points still stand, though. When there is an issue with third party sources for packages, it’s probably a pertinent idea to go to the third party itself, unless there is a clear indication that the third party should be an official mirror of the project.
Edit:
As an added point to all of this: It will, at some point, become important to run several different versions of Elixir. I’m working on several of my own projects as well as contracting work in Elixir and while I’m obviously free to use whatever I want for my own projects it’s always helpful to test with new versions and maintain compatibility with stable versions. On top of that it’s very important while working on other people’s projects to check that what you’re doing makes sense across several different versions as well as keeping the code future proof.
At some point, having several versions of Elixir and having folder-local version settings (1.6 stable for one project, 1.7.0-dev/master for another) will become advisable, if not needed. It’s better to come prepared for that than to rely on a package maintainer to bump versions, even if it’s someone who ought to have a vested interest in keeping up with the times.
1 Like
Definitely agreed. I’ve moved to asdf for this since it has great support for erlang, elixir, ruby, and nodejs among others. Much nicer than having a separate system for each programming language. Here’s a list of their supports languages: GitHub - asdf-vm/asdf-plugins: Convenience shortname repository for asdf community plugins
1 Like
Yes, if I was setting up my Elixir now I’d definitely go with asdf. At some point in the near future I’ll likely move as many of my programming language installs to it as possible and check where the water is leaking to see if maybe it can be my one-stop shop on clean Linux installs.
