[Proposal] Add "MIX_DEPS_PATH" env var support

79 views
Skip to first unread message

Philip Sampaio

unread,
Jun 10, 2019, 4:45:32 PM6/10/19
to elixir-lang-core
Hi guys,

We currently have some environment variables available to configure Mix and one of them is MIX_BUILD_PATH.
In our development environment we use Docker and Docker compose, and this env var helps a lot with caching and issues related to Docker for Mac.
We mount a volume outside the application directory to have a better performance. The idea is to have the same for our dependencies.

I know that we can configure the deps_path through Mix project as an option, but It would be great if we could configure this using an environment variable just like the build path.
We could call this new env var MIX_DEPS_PATH.
What do you think?

Cheers,
Philip



Allen Madsen

unread,
Jun 10, 2019, 7:09:49 PM6/10/19
to elixir-l...@googlegroups.com
Is there a reason that it's insufficient to do:

deps_path: System.get_env("MIX_DEPS_PATH") || "deps"

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/d6db2ca8-defb-4671-98f0-e77cc3a5d0f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Unified Front

unread,
Jun 11, 2019, 2:42:30 AM6/11/19
to elixir-l...@googlegroups.com
Hi all

Sorry for jumping in here, but shouldn’t that be something like this:

deps_path = System.get_env("MIX_DEPS_PATH") || “some default path"

(this level of questions should probably not be handled in here in elixir-lang-core, but rather 

R.
Fridrik.


Allen Madsen

unread,
Jun 11, 2019, 7:44:57 AM6/11/19
to elixir-l...@googlegroups.com
This is an appropriate place to discuss proposals to change the language, which the initial post did. My follow up question was questioning the merit of adding it to the language, when it seems trivial to achieve the desired result with no change.

It was deps_path: because deps_path is an option passed in a keyword list in a mix.exs file.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/FD696ED4-F126-43EE-808A-21516804355D%40gmail.com.

José Valim

unread,
Jun 11, 2019, 7:48:35 AM6/11/19
to elixir-l...@googlegroups.com
Hi Philip Sampaio!

To add to what Allen said, the reason why we added MIX_BUILD_PATH was because IDE/editors had to change the build_path so they could compile code without affecting the user workflow, and they had to do so without changing the mix.exs. In this case, it seems you have full control over the mix.exs, so I would love to know if there is any reason why setting "deps_path: ..." is not good enough.


José Valim
Skype: jv.ptec
Founder and Director of R&D


To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CsNhNh5r1em%2BDDfNM1wixisHqEe1Yj9Jkb8vzLZcT_Mjg%40mail.gmail.com.

Unified Front

unread,
Jun 11, 2019, 11:43:58 AM6/11/19
to elixir-l...@googlegroups.com
Hi all
Apologies, I didn’t realise you could do so in that context, therefore jumped to a conclusion that it was a typo…
R.
Fridrik.

Philip Sampaio

unread,
Jun 11, 2019, 3:07:29 PM6/11/19
to elixir-lang-core
Hi guys,

Thank you for your responses, and thank you, Valim, for explaining the motivation behind `MIX_BUILD_PATH`.

The idea is to keep a consistency of the possibilities to configure paths for artifacts.
We have both ways to configure build_path: mix.exs and env var. I thought it would be nice if we could have the same flexibility for deps_path.

In our case is to avoid having to change the mix.exs only because a technicality of our Docker environment, but I imagine some other scenarios like one that you have limited storage or network resources (this is mostly not a problem today, I know)
and you want to keep every dependency of your libraries and apps in a single directory. This is hard to archive if you don't have control of all mix.exs in your system (a CI server of Elixir projects is a good example of this).

So my point is more about flexibility and consistency.


On Tuesday, June 11, 2019 at 12:43:58 PM UTC-3, Unified Front wrote:
Hi all
Apologies, I didn’t realise you could do so in that context, therefore jumped to a conclusion that it was a typo…
R.
Fridrik.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-l...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-l...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-l...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-l...@googlegroups.com.

Michał Muskała

unread,
Jun 11, 2019, 3:19:22 PM6/11/19
to elixir-l...@googlegroups.com
Hi Philip,

I think what you're describing - keeping all the dependencies together - might be problematic because of versions. Mix assumes only the version it uses currently is maintained in the /deps directory - after all that's what vending is for. But this means that if you have different projects using the same deps directory they might conflict on versions.

If the goal of this is to speed up builds, maybe what is already available in mix/hex in the form of the package cache could solve your problems? In particular hex uses the $HEX_HOME/packages path to cache packages it downloads for future resolution. Maybe configuring the hex package cache to be the shared directory between projects could be a solution?

Michał.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a31b301b-af89-4272-ac05-551c2895dbec%40googlegroups.com.

Philip Sampaio

unread,
Jun 12, 2019, 7:29:41 PM6/12/19
to elixir-lang-core
Hi Michał,

I didn't know about this cache Hex does with the packages. Thank you for the explanation.
I think this is enough to solve the potential problem that I imagined about storage and network resources.

Philip


On Tuesday, June 11, 2019 at 4:19:22 PM UTC-3, Michał Muskała wrote:
Hi Philip,

I think what you're describing - keeping all the dependencies together - might be problematic because of versions. Mix assumes only the version it uses currently is maintained in the /deps directory - after all that's what vending is for. But this means that if you have different projects using the same deps directory they might conflict on versions.

If the goal of this is to speed up builds, maybe what is already available in mix/hex in the form of the package cache could solve your problems? In particular hex uses the $HEX_HOME/packages path to cache packages it downloads for future resolution. Maybe configuring the hex package cache to be the shared directory between projects could be a solution?

Michał.
Reply all
Reply to author
Forward
0 new messages