erlangmk: mention dep version number in rebar.config

[fenollp]

Fixes https://github.com/benoitc/hackney/issues/484 Turns out if a version is not specified (note that package is also not present in erlang.mk's list) then erlang.mk will fail to build certifi as a dep. cc @essen

[benoitc]

thanks a lot, willl release after lunch :)

[essen]

Yes Erlang.mk does not fetch the hex index and therefore cannot guess what the most recent version is.

[benoitc]

@fenollp just published it. Thanks!

[fenollp]

Sure no problem :)

[ericmj]

The previous version requirement was better for Hex packages – the best requirement would be ~> 3.2 or ~> 3.0. With the current requirement you wont be able to publish a package depending on certifi 2.3.1 and parse_trans 3.2.1.

[benoitc]

@ericmj unfortunately rebar3 doesn't allow that yet :( Maybe I should provide a mix package as well. Would it work?

I'm curious also, is there any reason why mix couldn't pick the top version on the longest branch of the dependencies tree like rebar?

[ericmj]

I think rebar3 does support it, example: https://github.com/lasp-lang/lasp/blob/master/rebar.config#L4.

Mix could resolve dependencies the same way rebar3 does but we feel our resolution algorithm is better because it follows all requirements in your tree and does not do implicitly chose versions for you. Changing to the rebar3 algorithm would be weird because rebar3 was created after mix and it would be a huge breaking change to change the resolution algorithm.

I'm not sure I fully understand what you mean by "pick the top version on the longest branch of the dependencies tree". I believe the reason it works in rebar3 is because it does implicit overrides in parent dependencies and if you have diverging versions in different branches it does something like implicitly picking the first one it sees or picking the highest version it has seen.

Mix on the other hand looks at all version requirements in your tree and selects versions that satisfies all the requirements. If you are not happy with the resolution or if it fails to satisfy all requirements you have to make an explicit decision by overriding dependencies.

[ericmj]

The other problem with these strict version constraints is that you have to update your package every time anyone of your dependencies is updated as evidence by https://github.com/benoitc/hackney/pull/485. This is incredibly impractical for maintainers and consumers of your package.

[essen]

How does ~> even work for rebar3? Does it invalidate what's in the rebar.lock file?

[fenollp]

@ericmj I think you are misunderstanding how dependencies work with rebar3: www.rebar3.org/docs/dependencies While it is true that parents deps take precedence over transitive versions, if such a conflict happens in the first place it can be made to trigger a build failure, using a documented flag. Versions in rebar3 are informational: there is no strictness in the config, there is only in the lock. That PR could have just had its lockfile updated (with ‘rebar3 upgrade’). So from what I understand I would say it behaves pretty much the same as mix here. Buut I may be wrong cause I’ve been using tildes for a while now!

@essen dunno. I’d say rebar3 uses the lockfile first if it exists regardless of config.

[ericmj]

What is the flag to trigger build failures? I have not seen it used in practice.

Rebar3 does not work like mix, mix only considers the lock of the top-most projects– never for dependencies. Mix uses the declared version requirements for all transitive dependencies.

[ericmj]

Only updating the lock with rebar3 upgrade would not have worked in the PR because when upgrading rebar3 looks at rebar.config where the version requirement is a fixed version.

[fenollp]

If you ever want rebar3 to abort as soon as it detects a dependency conflict, instead of skipping the file and proceeding as usual, add the line {deps_error_on_conflict, true}. to your rebar configuration file.

Yeah tildes got me there