Move dependencies into a separate file (e.g. deps.exs)

98 views
Skip to first unread message

boris kotov

unread,
May 10, 2019, 6:09:53 AM5/10/19
to elixir-lang-core
Right now, its a bit annoying to lookup the version on hex, and then manually adding it to the deps function.

There was a discussion back in 2017 on this. https://elixirforum.com/t/mix-deps-add-functionality/4856/7
The main problem people have thought about was manipulation of mix.exs, and true, we don't want that.

Instead we can use a simple exs file for this, which should be evaluatable to a list. So its a no-brainer to add items to it. For example `mix deps.add jason`.

 defp deps, do: Code.eval_file("deps.exs")

I am posting it here, to get some feedback on that feature, but I think the integration could go into hex only and if its adopted, adding the `deps.exs` file to the `mix new`-templates so please, share you opinions on it.

Pedro Medeiros

unread,
May 10, 2019, 10:02:51 AM5/10/19
to elixir-l...@googlegroups.com
Hi boris 👋🏼

there was an old discussion on the list about that


the main thing that came was "The dependency file for mix is an Elixir program rather than just a simple JSON file. There's no way reliably and safely programatically modify the mix.exs file as a result."

I don't think evaluation an exs to get a list will make a `mix.deps.add` reliable once we could put any elixir code on that file as well.

--
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/48f096ab-c6dd-494c-8907-ca16e1b785fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Pedro Henrique de Souza Medeiros
----------------------------------
Cel: +1 (514) 641-5031
Email: pedr...@gmail.com

boris kotov

unread,
May 10, 2019, 2:46:04 PM5/10/19
to elixir-lang-core
Hi Pedro,

> I don't think evaluation an exs to get a list will make a `mix.deps.add` reliable once we could put any elixir code on that file as well.

Well, as long as the file only consists only a list, there is no problem with it. You can even have code inside the list, like 

[
  {:my_dep, System.get_env("DEP_VER")}
]

But it should't have anything other then a list, for example this should't work:

# deps.exs
f = fn -> System.get_env("DEP_VER")
[{:my_dep, f.() }]

And you can check that really simple, and print something.. 

Am Freitag, 10. Mai 2019 16:02:51 UTC+2 schrieb Pedro Medeiros:
Hi boris 👋🏼

there was an old discussion on the list about that


the main thing that came was "The dependency file for mix is an Elixir program rather than just a simple JSON file. There's no way reliably and safely programatically modify the mix.exs file as a result."

I don't think evaluation an exs to get a list will make a `mix.deps.add` reliable once we could put any elixir code on that file as well.

Le ven. 10 mai 2019, à 06 h 09, 'boris kotov' via elixir-lang-core <elixir-l...@googlegroups.com> a écrit :
Right now, its a bit annoying to lookup the version on hex, and then manually adding it to the deps function.

There was a discussion back in 2017 on this. https://elixirforum.com/t/mix-deps-add-functionality/4856/7
The main problem people have thought about was manipulation of mix.exs, and true, we don't want that.

Instead we can use a simple exs file for this, which should be evaluatable to a list. So its a no-brainer to add items to it. For example `mix deps.add jason`.

 defp deps, do: Code.eval_file("deps.exs")

I am posting it here, to get some feedback on that feature, but I think the integration could go into hex only and if its adopted, adding the `deps.exs` file to the `mix new`-templates so please, share you opinions on it.

--
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.

Andrea Leopardi

unread,
May 10, 2019, 4:44:58 PM5/10/19
to elixir-lang-core
Hi Boris,

as Pedro mentioned, this has been discussed before. Having a "data" file as opposed to a "code" file for dependencies can already be done today: you can define a file that contains dependencies as a list, and then read that file in your mix.exs file. You can also build "mix deps.add" yourself on top of this. For these reasons, we're likely not going to add this to Elixir itself: we want to empower users and give them flexibility rather than providing many solutions that try to cater to many different needs.

Andrea Leopardi


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/faf1c54d-8974-4643-a5d2-301776a479ef%40googlegroups.com.

boris kotov

unread,
May 10, 2019, 5:19:04 PM5/10/19
to elixir-lang-core

Hi Andrea,

this is not meant to be a core-related feature-request. Instead, it should go into hex.


Do you have some personal opinions on that feature, and do you feel that it is uneccessary and that it is something that fullfills a very special need? I don't think so, its basic stuff. Recently, I had to explain a friend, why you don't have that feature in elixir, and that adding deps is just unconvient compared to other environments.


However you are right, it could be added even by a average programmer like me. But this is actually a weak argument, to not discuss a feature, which was already requested many times.

Andrea Leopardi

unread,
May 10, 2019, 6:05:29 PM5/10/19
to elixir-lang-core
> its basic stuff. 

I disagree because implementing what you're asking in Elixir (or Hex, not much difference since they're shipped together) is a substantial change. Personally, I don't add libraries to projects often enough to make this a problem in any way. I just run "mix hex.info package" so that I know what the latest version is, and then copypaste what "mix hex.info" outputs to mix.exs. I don't think that "mix deps.add package" would speed up my development time too much. The drawback of having to give up code as configuration like we have today in mix.exs is not worth that saved time IMO. Hopefully that makes things a little more clear.

Cheers,

Andrea Leopardi


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/3ce4a853-948f-48a7-a186-9a23a7ae1324%40googlegroups.com.

boris kotov

unread,
May 10, 2019, 6:22:57 PM5/10/19
to elixir-lang-core
Well, it's a nice to have, not something urgent. But a nice to have for most devs, you also would use that feature, if it would be there ;)

Boris Kotov

unread,
May 10, 2019, 6:26:10 PM5/10/19
to elixir-lang-core
I meant "basic stuff" in terms of expectations.. 


Am Samstag, 11. Mai 2019 00:05:29 UTC+2 schrieb Andrea Leopardi:

Anil Kulkarni

unread,
May 11, 2019, 10:45:26 AM5/11/19
to elixir-l...@googlegroups.com
I actually built the CLI tool & json reader - it's located here: 

https://hex.pm/packages/wand 


And the usage is similar to yarn in that you can add and update and remove packages using the cli 


IMO having elixir read from a deps.json as a fallback if mix.exs doesn't define deps would be a good path forward. The json format would need to be worked out (such as for encoding atoms different than binaries).


Best, 

Anil

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/5d94715c-33b4-4d23-8f95-34a6096f868b%40googlegroups.com.

Wojtek Mach

unread,
May 14, 2019, 12:49:50 PM5/14/19
to elixir-l...@googlegroups.com
> https://hex.pm/packages/wand 

I’m glad to see community is stepping up to fill this gap. My personal opinion is such tools makes it almost “too easy” to adds deps whereas I think we should do the opposite, encouraging people to audit deps before adding them and ideally limiting deps in the first place.

In any case, just some unsolicited feedback about Wand:

1. instead of parsing JSON from Hex HTTP API, you can ask the server to provide response in External Term Format and read it using `:erlang.binary_to_term/0`:

    $ curl  -H "Accept: application/vnd.hex+erlang" https://hex.pm/api/packages/wand | elixir -e "IO.read(:all) |> :erlang.binary_to_term() |> IO.inspect()”
    %{
      "docs_html_url" => "https://hexdocs.pm/wand/“,
      …

  (Or use https://github.com/hexpm/hex_core which does this too, it’s deps-free and meant to be vendored into tools like this one, parts of it are already vendored into Hex and Rebar)

2. Instead of parsing JSON from a deps.json file, you could save Erlang terms in some deps.config file, one term per line, and read them with `:file.consult/1`. This way you could drop json dependency completely.

Benjamin Milde

unread,
May 21, 2019, 11:33:58 AM5/21/19
to elixir-lang-core
If this would be added to elixir or hex then people would expect it to work common scenarios. Given that nerves is quite a common project to work on, which has much more complex dependency handling than "just add it" this would probably result is similarly many unsatisfied people than we currently have in terms of people missing a cli command to add deps.
Reply all
Reply to author
Forward
0 new messages