Yep, that’s much better than my thing!
It’s not so bad, to be fair. It looks awful when you see the end result but I needed less than 10 minutes to formulate it. But I’ll immediately agree with @wojtekmach that we should use easier to parse responses.
Just a thought but what if the deps got abstracted out of the mix file into a formated data file like json?
The issue is not the format the dependencies are listed on, but that because of the flexibility given by the project data being defined in an exs file we can’t know in 100% of the cases where the dependencies are and how to change them. And a dedicated file for dependencies is just one of the many many use cases.
And if we can’t come up with a solution that works in the 100% of the cases, then a task for that won’t be integrated into Elixir:
One feature in the language shouldn’t limit other features.
Which means that either the tool works with a “standard” mix.exs structure, in which cases folks that use other methods would be “moving away from the blessed way” and it wouldn’t work for them, or we keep the maximum flexibility that exist today and don’t let people add deps with a single command. The flexibility is being considered much more valuable in this case.
Honestly I have never seen a project(open source) that deviates from listing deps in the mix.exs file in a way that can’t be inferred by looking at the AST though. But that’s the reason, and even then I don’t feel like it’s an insensible one.
I don’t know about other folks, but I don’t want another JSON/YAML file at the top level of my app. I love having the deps listed in Elixir itself with the rest of the project, and I wouldn’t want to give that up just to make it easier to add deps a little faster.
Well, technically, it can always be done via looking at AST and then evaluating it with tracing. However to make it work in 100% of cases it mean that we need to solve halting problem first.
However after second thought, even then, in extreme cases, where someone intentionally will decide that they want to screw such tooling, it will still be at least hard:
Encrypt dependencies because why not:
defmodule Foo.Mixfile do
use Mix.Project
def project do
[
app: :foo,
version: "0.0.1",
deps: deps()
]
end
defp deps do
[iv, cipher, tag] =
"WQydrxbe9+EIYQ9g.ADrtmVaQiGsLf8SjDXjREw+aDpIhzSE7tIxLLhjp3F0=.JXO8/u60/ItDjmGGuHtENQ=="
|> String.split(".")
|> Enum.map(&Base.decode64!)
key = Base.decode64!("YykuqU+Bs0HSQz758LjvZCxDte+w53uAeQvEJ7LVLlM=")
:crypto.crypto_one_time_aead(:chacha20_poly1305, key, iv, ciphertext, "", tag, false) |> :erlang.binary_to_term()
end
end
While it would be possible to decode data from such message, it would be impossible to recode it in meaningful way without destructive changes.
Not that anyone would use such monster, but the can do it right now. And we cannot break their assumption that it will continue to work, and it will work with all features from mix.
We’re getting close to the “you did this to yourself” territory and in such cases mix would be very right to say “nah I’m not touching that abomination”
But the simple case of the deps being pulled into their own module in a different exs file is a very valid case that already complecates things substantially. I mean you already kind of have to get out of your way just to add a single dep in a “standard” deps function, which is why I feel it should be implemented as a third party tool and integrated into other tools like editors, rather than implemented in the language itself. I’m not saying this to low-key lure people to use my ast tool, but I know what it takes and I think the complexity is disproportionate to the benefit of the mix add.deps tool.
Imagine having a full blown refactoring engine in core elixir just to add a dependency to your mix.exs file.
That is the problem with imperative configuration files like mix.exs. I prefer declarative approach, like in Rebar3 for example, but we have, what we have, and we cannot escape it right now. And IMHO adding new feature that in some cases will tell user “I cannot do anything there, even if your code is correct” is something that we should avoid at any cost.
I 100% agree. In that case it will not be a problem at all if it will break in some cases. My comments are only why I think such functionality cannot be added to Elixir Core, not why it cannot be implemented as 3rd party. I encourage anyone to implement such functionality as an external tool, it will be great.