If one wants to see an example of those in the wild look at ecto_sql’s mix.exs.
LostKobrakai
Benjamin-Philip
Yeah. I am in favour of having a deps.json but it’s quite a major change (in my opinion), and I am not sure if it will be accepted till the next major release; i.e 2.0.
1
al2o3cr
How much time do folks actually spend adding dependencies? I don’t do it much personally, but maybe I’m an outlier.
IMO “remember the right options to pass mix deps.add” is almost as much cognitive load as “remember the right tuple shape to put in deps”, just with extra steps.
12
lucaong
I agree that such a mix task could be very useful, but should this maybe be a library instead of a core feature? My logic is: a library could use a file such as deps.json and instruct the user on how to set it up in mix.exs (a very simple operation on most projects), without forcing every project to adopt that structure.
4
mattei
Is this really a pressing issue? I really have no problem adding dependencies to mix.exs.
The VS Code extension, for example, fetches all dependencies on file change so it’s quite seamless.
2
dorgan
With the exception of the parameterized deps or deps being loaded from an external file, all of your examples are easy to solve just by looking at the AST. Even the Ecto example is easy to solve once you have some other stuff in place. It’s not that much of a problem with “how do you do that”, but rather with “should it work in every single place you can think of, or should it give up on the not so common cases”. Or put it another way, “is this for every single elixir developer or is this to help onboard people to mix projects like phoenix generators do”? It may as well say
Mix can't recognize your mix.exs file structure. To add <dependency> to
your project, add
{<dependency>: "~> 1.2.3"}
to your dependency list and then run mix deps.get.
So if it can’t deal with your setup it at least saves you from having to open hex, search for the package and copy paste the code from the browser to your editor.
My other concern, and the reasons I think it should be a third party library(an escript or an editor plugin) are that the Elixir team philosophy may be to work under every circumstance, and that changing the source code is doable but you need to introduce quite a lot of complexity to mix for that single use case, because mix should not only be able to add the dependency tuple, it needs to correctly update your code without messing up the formatting of the rest of the code.
3
lucaong
It is a bit tedious to go look for the latest version of a library each time one adds a dependency. That said, the issues with adding this feature in the core in my opinion overweight the benefits. If implemented as a library though, I would definitely see myself using it.
4
mattei
I actually totally understand your point now, and I’ve had this problem when accidentally stumbling upon old docs on Hex.
I disagree with those saying that a data file is the solution though: mix.exs is so powerful and it’s standard in the ecosystem, I feel like it’d be a huge step backwards to fragment the tooling in the community at this stage. Coming from the disaster that is Python tooling, the standardized tooling is a huge win already.
On another note, the solution being proposed for a mix.exs parser sounds pretty dope.
2
lucaong
Yep. If implemented as a library, I think it would be perfectly ok to simply read the mix.exs file, assuming that the dependencies are a plain static list of tuples in the deps method (and showing an informative error message otherwise), and add the new one to the list.
It would be up to the user to ensure that they follow this standard, if they choose to use the library. Elixir core cannot make such assumptions, but a library certainly can, as it is opt-in for the user.
0
