Discussion:
Improving Elixir support
(too old to reply)
Pjotr Prins
2017-12-03 06:20:56 UTC
Permalink
Raw Message
I am forwarding this from the bug tracker because I believe it is of
general interest to those working on Elixir/Erlang.

http://lists.gnu.org/archive/html/bug-guix/2017-12/msg00019.html
nee
2017-12-11 00:04:19 UTC
Permalink
Raw Message
Hello, I had a short look the elixir/erlang package systems.
I'm sending my current WIP status.
It seems the following things will be required:

1. hex.pm importer
https://hex.pm is the main package repository for erlang and elixir.
I already wrote a basic importer. Hex.pm has a simple json api that
provides everything an importer needs.
I still have to write an updater.
The downloads provided by repo.hex.pm are ".tar" files.
These tars contain:
- some metadata in an erlang specific config format that is already
available via the json api.
- contents.tar.gz which contains the actual package.
- a hash that is also available via the api and the webinterface. It
looks like a sha256 hash. I haven't found anything that matches it.
I would assume it relates to the contents.tar.gz somehow.

2. a url-fetch/hex.pm orgin fetch method that unpacks the nested
contents.tar.gz that hex.pm serves. This is already done.

3. build rebar3 from source
rebar3 is the main build tool for erlang packages.
I started working on this. I download the dependencies from hex.pm
and unpack them to _build/default. The problem is that rebar3 needs the
full hex.pm package index (around 6Mbytes of binary data)
to (I think) verify the package hashes.

I looked at how nix solves this, and they have a snapshot of the
hex.pm package-index mirrored in a github repository and update it
whenever they need a newer version of a hex.pm package.

I don't really like that solution, since all packages depend on this
central snapshot, and it has to be updated whenever you want to package
or update a new hex.pm package that isn't in the old snapshot.
Maybe rebar3 can be patched to not lookup the package registry, and
just accept whatever is in the current _build directory.

4. rebar3 build system
It's probably similar to building rebar3 from source.

5. mix build system
Mix is the build tool used by elixir. It's already built in the elixir
package. Dependencies seem to be installed locally in the ./deps
directory of a project. There are also so called archives. I'm not
sure yet if they can be used as dependencies.
I'm expecting the same registry problem as with rebar3, but haven't
checked, yet.

Interesting environment variables:
- MIX_ENV # set to "prod" to build a production target
- MIX_HOME
- MIX_ARCHIVES # path where archives and loaded from and installed to
- MIX_REBAR # override the rebar executable
https://hexdocs.pm/mix/Mix.html#module-environment-variables

Interesting commands:
- mix deps.check
- mix compile
- mix archive.build
- mix archive.install
Pjotr Prins
2017-12-11 07:41:48 UTC
Permalink
Raw Message
Post by nee
Hello, I had a short look the elixir/erlang package systems.
I'm sending my current WIP status.
Good progress! Just thinking out-of-the-box here, but almost all
Elixir packages are pretty straightforward. Can we not just unpack
them and compile them? I think there is too much magic behind mix and
all that. All you really want is to compile them and have them on the
path.

Pj.

Loading...