I’ve personally not seen one for artifactory but it is extensible in mix.deps as I recall, you’d just specify your own SCM module (maybe a manager too?) and you can use it to specify dep locations too as I recall. I’m unsure on the details as I’ve not made one, but maybe @josevalim or someone will pop in to clarify how with links to documentation?

Artifactoy has had an open jira item since about 2016 to support this, that appears to now be on the 2021 roadmap.

Additionally, I was able to host elixir client libs in a generic artifactory repo by using a modified version of the mix hex.registry build that my much-more-experienced co-worker helped me with. It borrows from the source of mix hex.registry build but uses the existing metadata files and modifies them instead of re-writing them.

Pipeline:

• create directory structure outlined by hexpm here
• download meta data files from the artifactory repo (names, versions, packages/*)
• add new .tar files to tarballs/
• use our custom mix task (containerized in a CI pipeline) to update the metadata files
• upload new .tar files and updated metadata files

For some reasons - such as auditing and network requirement, etc. - having Elixir support in such artifact/package management software is often wanted, even elixir package is just source code package. Note that go is adopting “package” system and Artifactory and Nexus support Go as well…

These are tickets for Elixir, for the reference.

• Artifactory: [RTFACT-14011] - Jira
• Nexus: Log in - Sonatype JIRA

For related discussion and resource:

@matreyes Unfortunately, I’m not at liberty to share the mix task itself, but here’s some more info that should help.

First, take a look at the docs here: https://hex.pm/docs/self_hosting around self-hosting. Follow the guide, particularly, the section around “Building the registry”. Take a look at the contents of the dir you created - you’ll see some folders and files (names, versions, public_key, and packages/*). These are the “metadata” files that I was talking about. There is also the tarballs directory (more on that below)

If you’re hosting the registry yourself, have direct access to the server hosting it, and you want to add a new package, you can simply add the generated tar to the tarballs/ dir and re-run the mix hex.registry build ... command, just like what is outlined in the link above.

This is where the artifactory difficulty comes in - when you’re updating a self-hosted registry, all of your tar files need to be present. All those metadata files I mentioned - they get regenerated based on the contents of the tarballs/ dir. If you’re using a CI pipeline, for example, to publish client libs that means you need to pull the contents of your entire registry (all those metadata files + all the tarballs) into your pipeline’s workspace, add your new tarballs, re-build the registry and then push it back up to wherever you pulled it from (whether thats artifactory, or somewhere else). That is what drove the solution I mentioned above - as the registry grows, pulling down all those tarballs is 1) completely unnecessary and 2) will become intractable over time.

This is where the custom mix task comes in - the biggest difference between our mix task and the mix task mix hex.registry build ... is that we don’t re-generate the metadata files, we update them. All we need to pull down from artifactory are the metadata files into our CI pipeline’s workspace - we don’t need any of the existing tarballs. Then we add the new tarballs locally, run the custom mix task, and push it all up to artifactory.

There is an obvious simpler solution if you’re not tied to artifactory and simply want to just host a private registry somewhere yourself - on the machine you’re hosting your registry, just write a simple API in front of it to accept tarballs for your packages, add them in the tarballs/ dir and run the mix hex.registry build ... command.

The solution I described was necessary simply because 1) we’re tied to artifactory and 2) we can’t set up any custom scripts/tasks to run on artifactory when things are uploaded to a repository.

Our custom mix task is simply a modified, self-serving version of the source of the mix hex.registry build ... command. I would suggest spending some time looking over the source here: https://github.com/hexpm/hex/blob/v0.21.2/lib/mix/tasks/hex.registry.ex as well as the hex docs here: https://hexdocs.pm/hex/Mix.Tasks.Hex.Registry.html

Hope that helps!

Artifactory is for binary artifacts which can be linked at compile time with your application, like JAR files in Java. AFAIK, there is no such thing as linkable binaries in Elixir. Like with Golang the dependency manager gets sources which are in some way vendored and compiled along your application. In short, I don’t see more use of Artifactory for Elixir than for Golang for example.