Since we’ve got a working implementation I wonder if we can reach out to the folks at GitHub to get Hex dependencies detected automatically just like the mainstream ecosystems. I know we were able to do that with treesitter support for highlighting and code navigation in GitHub.
Any updates on supporting Rebar3 and Gleam?
I’ve already reached out to GitHub about the possibility to integrate this into GitHub itself and run for all Elixir projects. The project is engineered in a way that should also make it simple for them to integrate. (Small self-contained Burrito based binary)
For now we should try to get it implemented in many repositories so that GitHub will see the interest of the community.
On Gleam / Rebar3: We’re discussing the possibility to build this for rebar3 as well in the EEF. There’s however a few uncertainties that we have to clear up first. I did not yet look into gleam.
I wonder if they will have any concerns of introducing a new stack (Elixir + BEAM) into their build pipeline. I suspect they’d prefer a go binary or a ruby script both for CI and maintenance reasons. I guess we’ll know in time.
Unfortunately the Mix Dependencies are not that simple. The files do not contain all the info and are written in Elixir.
I had to implement multiple strategies, one being an actual Mix Runtime that loads the project config:
You are saying that it’s not enough to implement a parser for mix.exs and mix.lock in another language because there is stuff from them that has to be ran / evaluated in the BEAM VM itself? And only through that to get all necessary info to do GitHub dependency submission?
mix.exs can contain arbitrary elixir code. So you need an elixir compiler and runtime.
Oh, yeah, and in fact dependencies can, ahem, depend on the Mix.env, true.
Sigh. That really makes this whole ordeal more complex than it should have been.
EDIT: Though thinking of it, it still is not that bad. One can just grab their final mix.lock and only work with that. That technically makes the whole thing automatable with any other programming language, no? Especially those that produce statically linked binaries like Golang and Rust.
Yes, mix.exs files are arbitrary Elixir Code. mix.lock always has the same format, but still is elixir code.
Depending on the SCM (Git / Path, Hex, …), there will be an entry in the lockfile (optional) and it contains different content per SCM. For example, Hex saves the transitive dependencies, Git does not.
To get all the info out, I had to have mix running. (Mix.in_project)
This makes me feel like dependencies as code is both a blessing and a curse. It enables us to add/remove deps programmatically in ways that would be very difficult in other languages to do and at the same time makes a lot of basic and standard functionality so much harder to setup.
Wouldn’t the topmost lockfile of the root repo have the entire dependency tree? Then it is just a question of if the lockfile is included in the git repo or not.
Is there a standard for tracking cross language dependencies? Like in the case of an NIF with Rust or C dependencies (leaving aside the lack of any uniformity with and C/C++ for now?
Unfortunately, no
SBoMs are doing this. We’re working on making this happen.
© Copyright Elixir Forum | Terms | Privacy & Cookies
