My team is building various micro-services using elixir.
Some of needs of systems is shared (for example: authentication).
To not duplicate code in each system, we create a some libraries implementing shared code between systems. This libraries contains business rules, therefore, not be open-sourced.
I would like create a private repository in our infrastructure, but, I dont find a documentation wich describe the process of it to me.
mix deps.get behavior, I see it gets packages from repo.hex.pm, which in turn is a S3 bucket, therefore, I conclude that it is not very hard.
Can someone help-me to found the documentation about it?
There is good documentation at https://hex.pm itself. You can host your own internal installation of hexpm (it’s a Phoenix app, yay! ) and then you can use the :repo option in the relevant depencies in the mix.exs file as noted in the docs here.
Another option: use git (if you use git )
You can specify git url and ref/tag (see git options), or use submodule with path option.
There is also Private packages in Hex (currently in beta), which has different pros & cons.
From my experience on using private repo for ruby gem… git way is much simpler since you can use git+ssh authentication like the main repo. There are some benefits of having private package repo for backup and audit purpose, but that usually applies only when you fetch all packages from the repo.
There is already a request to support hex on Artifactory - RTFACT-14011: Support for Erlang “hex” repos.
Git works if you have one or two packages but at the moment you have multiple packages and they depend each other, Hex private is probably the best option since we can’t perform dependency resolution on top of Git.
As far as I remember, just for comparison, Ruby bundler uses git to fetch packages and then checks gemspec for version and its dependency - so I can keep two private packages in git, depending each other with version constraints.
How does mix handle this? It seems to do the same thing.
The obvious disadvantages of using git is that you now need to resolve version constraints since you do not use hex.
I don’t know if this existed at the time this thread was originally posted, but looks like setting up an
organization on http://hex.pm is going to be the cleanest way to do this. You could deploy your own self-hosted version of the hex.pm app but it seems that this is ultimately going to be the easiest way to get going out of the box that still permits full resolution dependency, and without having to personally maintain an external/private hex.pm service.
Remember that with git you can access individual private repositories from a github account, but as @josevalim mentioned
mix will not perform dependency resolution on those apps and you may end up with conflicts, and possibly having to maintain the dependencies for your private elixir libraries in the top-level app in which they’re being used. This might work for a very simple application but breaks and is clumsy to maintain at scale.
If you don’t want to use hex.pm organizations for whatever reason I’m sure you could also configure this on your own server, though the setup overhead will be more involved. I get the sense too that hex.pm organizations will become an increasingly common workflow in Elixir projects, and will be easier to onboard other developers already familiar with that relatively straightforward process.
Apparently I’m still locked on this topic - @wojtekmach introduced MiniRepo roughly three months ago which looks like a good way to get a quick, private hex server up and running if cloning and deploying all of hex.pm proves to be overkill.
That said, I’ve found @ericmj and the hex.pm team to be extremely helpful and supportive. Seems like any of the above options will work well. Really just depends on personal preferences.
One more note here - I recently spent a couple of hours digging through the hex.pm application source code and deploying the application locally. While it’s pretty easy to get it going in development, the
prod environment has a few runtime dependencies for services like a Fastly-backed CDN, Rollbar error handling, AWS credentials for S3 access, and mailer credentials, which may be overkill for a small internal deployment.
Here is the full scope of the environment variables required by a production release:
Hex.pm releases are also configured for Docker by default, backed by Kubernetes, which may additionally prove overkill for a smaller setup with a handful of users. That said, bootstrapping an edeliver config is not difficult for this setup and was easy to get going.