Code.eval_string() raises warnings when parsing Mix.lock

[Thibaut Barrère]

Hello!

A slightly exotic use-case, but I would like to have your opinion :-)

While doing maintenance work, I often leverage the fact that Mix.lock content is "valid Elixir" to implement useful stuff.

Two examples are:

- https://github.com/etalab/transport-site/blob/master/generate_deps_changelogs.exs to automatically generate "diff" sections on maintenance PR (see "Changelogs" sections at https://github.com/etalab/transport-site/pull/3814)

- other tooling to verify that unwanted dependencies have not been replaced unwillingly (example at https://github.com/etalab/transport-site/issues/3820, there is code in addition to French!)

The point I want to bring is that this call (at least on Elixir 1.15):

Code.eval_string(File.read!("mix.lock"))

raises warnings such as:

warning: found quoted keyword "mox" but the quotes are not required. Note that keywords are always atoms, even when quoted. Similar to atoms, keywords made exclusively of ASCII letters, numbers, and underscores and not beginning with a number do not require quotes

  nofile:78:4

This is not a super blocking point at this stage, but I wonder if ensuring that Mix.lock is formatted in a way that does not lead to warning would be a possibility here?

Alternatively, what would be better ways to get the same value (maybe leveraging Mix internals), without having to "migrate" the format?

The tooling I use is here to stay, and worst case I can either ignore the warnings, or "pre-process" the file to remove them, if needed.

Thanks!

-- Thibaut

[Wojtek Mach]

Please use ElixirForum and such to ask questions as broader community can answer as well as see replies. This ML tends to be focus on feature requests.

On v1.16 you should be able to pass emit_warnings: false. I believe there are equivalents on prior versions, they should be documented in this function: https://hexdocs.pm/elixir/Code.html#string_to_quoted/2

[Thibaut Barrère]

Thanks Wojtek - I was unsure if this would result in a potential change request (on the format of Mix.lock itself), hence my posting here, but well noted!

Thanks for hint as well, that should do!

-- Thibaut