search

erlef / rebar3_hex

Rebar3 Hex library
Apache License 2.0
101 stars 49 forks source link

Fix handling of binary version specs #168

Closed filmor closed 4 years ago

starbelly commented 4 years ago

Hi, @filmor did you have a case where a version was not a binary? We get the version numbers from the projects rebar.lock file and those are stored in binary.

filmor commented 4 years ago

This is the code path that takes the version specification from the rebar.config, if specified there. And the error was the other way round, the code only works with a list while rebar3 handles binaries in the {deps, [...]}. just fine.

starbelly commented 4 years ago

Ahh yeah, gotcha. So, later in the execution path we do call binarify/1 on version... so I'm still not sure there was a bug, but I'm not sure there wasn't either... do you have a case?

filmor commented 4 years ago

The problem is not the content of the version, it's the guard expression here. This commit shows a diff that was required: https://github.com/rusterlium/erlang-cargo/commit/9a2b12ebc5ac4395670cebbfd3defba6fbb69c71

The corresponding hex packages are here: https://hex.pm/packages/cargo The diff between the pushed packages is this: https://diff.hex.pm/diff/cargo/0.1.0..0.1.1

You can see how the only (real) difference between these two is that I converted the dependency line from {jsx, <<"~> 2.8">>} to {jsx, "~> 2.8"} and this resulted in a corrected hex_metadata.config.

starbelly commented 4 years ago

Gotcha. I wasn't aware that this binary for the version in rebar3 is actually allowed, thus it should be allowed here as well.

tsloughter commented 4 years ago

@filmor curious, what is the mix.exs for?