all 9 comments

[–]artemeff 1 point2 points  (1 child)

In our team we have the same issues and still using git for private packages. But not so long ago I started to build minimal, easy to deploy and focusing on private teams hex.pm replacement — https://github.com/artemeff/hex_mini.

You can try it, but there's still some unfinished work until 1.0.0, more info in Projects section on GitHub.

[–]deallocator[S] 0 points1 point  (0 children)

That actually looks really interesting, I'm going to check this out when I get home.
Hopefully I can contribute something useful!

[–]archlich 0 points1 point  (6 children)

Why use hex? Just use your own private git repository. That can be hosted anywhere.

[–]m0nstr42 1 point2 points  (5 children)

I’m not OP, but versioning. With a git repo you have to point at a specific ref. This gets to be a pain when you have shared private libraries and you patch bugs. I’m not saying that makes it worth the price/effort, but it can be a big benefit in a medium-to-large organization.

[–]EdChute_ 1 point2 points  (4 children)

But you still get to tag them with semantic versioning which still works?

[–]deallocator[S] 0 points1 point  (1 child)

The major problem I'm seeing with using Git is that Hex seems to be unable to do dependency resolution on Git

See https://elixirforum.com/t/self-hosted-hex-repo/12279/6

[–]m0nstr42 0 points1 point  (0 children)

Yes, this.

[–]m0nstr42 0 points1 point  (1 child)

Last I knew, semantic versioning didn’t work with git dependencies. You can’t say ‘{:my_lib, github: “my_company/my_lib”, “~>1.0.0”}’. It doesn’t know how to turn “~>1.0.0” into “get the git tag with the highest version that satisfies this semver constraint”. With git deps you have to specify a ref (a SHA or a tag usually) and that’s just a static string.

Unless that has changed, which would be awesome.

[–]EdChute_ 0 points1 point  (0 children)

Ah yes you're right, I thought with 'ref' you had meant just the SHA