Install packages or modules globally

Hello guys , how can i install hex packages globally for other projects , instead of shipping packages with each project I create or build ,
I need some insight on this issue

Even though possible with some hacks, it’s strongly discouraged to do so.

It will cause a lot of pain and issues as soon as versions diverge between globally installed packages and locally required ones.

Also, mix will always download for local projects, causing warnings of redefining the modules of the packages that are installed globally.

4 Likes

Ok thanks for the insight

Absolutely never do this. In any language, if you can help it.

Even in quite big Elixir projects with 50+ dependencies, I’ve never seen the deps directory (where your dependencies are downloaded to) being more than 300MB. Unless you are developing on single-board computers with minuscule SD cards, just don’t.

1 Like

Yeah in our core project, which has 103 deps (including transitive dependencies), the deps folder is only 41mb.

1 Like

Isolation is a boon, embrace it :slight_smile:

But Guys, In erlang, modules or libraries can be installed global and used by other people involved in the project, but I see with elixir ,each developer involved in the project will have duplicate packages for the projects they are working on and yet if they could reference already existing modules or packages this would improve productivity and development

Yes, you can, also you can in python, ruby and C, and it causes problems everywhere.

Sometimes this problems are quite invisible, sometimes you feel it on every step you make, every breath you take.

And even for C it seems as if programmers want to get away from global libraries to project local ones, at least during development.

For erlang, I haven’t seen someone using globally installed packages/libraries since rebar3 has a hex plugin.

But as we said, you can have globally installed packages, but it will cause you problems.

You can abuse mix archive. But be warned that it will only cause you trouble.

2 Likes

Any project will inevitable have updates. And unless any of them are really well coded with all the backwards compatibility you can get, it probably will mean changes are needed to projects depending on the package. With globally installed dependencies this means an update to such a dependency results in the need to update all dependants at the same time. From my experience this is something, which seems not to be a big deal at first, but the older dependant projects get the more a problem it becomes.

If you don’t want to use e.g. hex.pm I’d look into a company wide custom package repository (e.g. mini_repo), which allows you to use proper versioning for your dependencies, while still keeping projects local / resistance from doing the proper thing small.

I’m quite interested though, how exactly this would improve productivity/development for you?

1 Like

…Okay, what? :018:

I think there’s a huge misunderstanding here.

We are talking about every project downloading their own copy of their dependencies. That way, if you have 10 projects, each can be compiled independently without the version of their dependency (say, a JSON parsing library) being changed globally because another project upgraded.

This is a blessing. You don’t get to worry about the above.

Nobody here is saying that each developer in your team must maintain a separate copy of the dependencies.

What’s not clear?

Thanks guys for this insight

Probably a bit exaggerated. There are languages having the tools which handle this problem very well. If you use ruby with bundler or even go since they introduced modules you can store your dependencies globally without getting into any troubles. If I am not wrong the same refers to rust.

Of course elixir follows its own path and that’s ok as well.

Rubies bundler installs globally, but uses sandboxing mechanisms to make it appear project local.

Go does pretty much the same, especially with modules. Before modules, dependencies were a constant source of pain.

And rust does have local deps only, with a global download cache, similar to how mixhex plugin does as well as far as I know.

Pretty much all ecosystems I have worked in through the last 15 years, have tried to move from a global package/library store to a project local one, at least for development.

C and C++ are probably the only exceptions, and even there, sandbox dev wrappers exist.

2 Likes

Nothing beats hunter.sh for that if you use CMake. ^.^

Global cache, always project local. Most other dependency managers for C++ are horribly broken and like global-only dependencies for some crazy reason…

I believe the latest .net core incarnation does something similar. Packages are stored globally under ~/.nuget/<name>/<version>/ and projects pull from there

That’s a cache as you said. Your project still has those dependencies copied to its own directory. They are not used from the global location.

Hmm… according to this https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders projects using the newer format do use the packages directly from the cache. Perhaps it’s a recent change?

Seems like it. Or I misremembered.

In any case, the original point stands: global packages are a horrible idea.

Perhaps they use it from there, still they are sandboxes/whitelisted. A project won’t see those libraries in the cache that it hasn’t specified as a dependency.