Why doesn't the Elixir core team accept `mix deps.add` proposals?

Chat / Discussions
41

Yikes. Remember WORM drives (write once, read many) - sed & perl are more like WORN - write once, read never.

2 Likes
42

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.

1 Like
43

Love it. Thx!

1 Like
44

Just a thought but what if the deps got abstracted out of the mix file into a formated data file like json?

45

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.

4 Likes
46

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.

5 Likes
47

I don’t disagree but was rather trying to understand why that idea was not being talked about more since it seemed like an obvious solution to the parsing issue. I think @dorgan gave me a good perspective to this idea.

1 Like
48

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.

1 Like
49

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.

50

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.

1 Like
51

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.

2 Likes
52

The pattern given to grep could be given to sed instead:

sed -n 's/^Config: \(.*\)/\1,/p'

Thus, the grep command can be removed. The command grep pattern is equivalent to sed -n '/pattern/ p'

-n tells sed to print nothing unless explicitly told to
/pattern/ selects lines matching the pattern
p command prints the selected lines

sed can execute multiple commands by grouping them with braces and terminating each command (even the last one) with a semicolon.

So, another solution could use a pattern match and two trivial substitution commands:

sed -n '/^Config: / {s///; s/$/,/; p;}'

/^Config: / “greps” for the pattern
For each match, run the following 3 commands:
s/// replaces pattern with empty string (ie deletes "Config: ")
s/$/,/ appends a comma
p prints

4 Likes