Using my own private shared library in multiple projects locally as well as on a remote server

Questions / Help
1

On my local computer I have a shared library and several projects that use it, this way:

  # mix.ex
  # [.............]
  {:my_shared_lib, "~> 0.1", path: "../my_shared_lib"}

The library should remain private. I don’t to publish it in a public repository at github.

  1. Is this a wise way to share it between multiple projects?

  2. Will it work on a server in production? How will I bring there the shared library? Or how will I statically link it to my projects in production?
    I use edeliver and distillery for deploying.

2

Since your release is compiled your source code doesn’t need to leave your development machine.

2 Likes
3

What do you mean?

4

Exactly what he says.

Just trigger your deployment process and make sure the build machine can “see” the path dependency at the same place. It might be necessary to do a local build to achieve that.

After building edeliver will just push the compiled artifacts, but not the source code, to the actual host.

But to be honest, unless you have an umbrella or poncho project, don’t use path dependencies, and never use path dependencies living outside of your project root.

Path dependencies will eventually become a major problem when sharing the source code…

1 Like
5

You don’t have to publish your package publicly!

You could:

  1. Use a git reference to your github/gitlab so when you build it it will clone to the point in time you referenced (you can even reference a tag/commit)
  2. Use hex.pm private hosting
  3. Setup your own hex.pm repo

Just use #1, your current way (linking to a folder locally) should only be used for development IMHO.

2 Likes
6

the build machine can’t “see” the path dependency because a build machine is a remote one.

How to do local build? which I’ll use for production after.
“mix build”?

7

And what would it be if not publishing my package publicly if I uploaded it to my github/gitlab repo? a repo would have to be public

8

I don’t plan to share it

9

You can have private repositories, you just need to add a public key of which it’s private key is known to the build host.

As far as I know you can add such as a read-only key on a per repo base.

1 Like
10

That’s a part of a solution. If that works at all. And I don’t want to have to use hex.pm in order for a whole approach to work

11

I source libraries from a private Github repo. I use SSH credentials locally and an access key in production. The access key is tied to a service account that only has read access to certain repos.

Wrote about it some time ago on https://stephenbussey.com/2018/02/05/sourcing-libraries-from-private-github.html. I still use this approach today.

2 Likes
12

Will that work with private repositories at bitbucket and gitlab too?

13

Yes, it should.

And if such a service account is not available, then just use a read only SSH key as I proposed earlier.

Also please be aware that I never proposed hex.pm, but private git repositories.

1 Like
14

As I said there are multiple options. ANd yes it does work, I’ve been using this approach for years for private repos. Your production code shouldn’t be building your project, your CI/CD pipeline should be which creates a release for you which your prod server then runs. Your CI/CD pipeline should have access to your deploy key, see https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys for docs.

Maybe just try it and see how it works for you? Github/bitbucket/gitlab all offer free private repos for a single user.