rebar get-deps and semver

[define-null]

If other vsn than ".*" is used in rebar deps section rebar will fail to get dependency because the process of changing version to tag is done at post_compile time.

ERROR: Dependency dir /media/dev/erlang-app/deps/depapp failed application validation with reason:
{version_mismatch,{"/media/dev/erlang-app/deps/depapp/src/depapp.app.src",
{expected,"2.0.*"},
{has,"semver"}}}.
ERROR: 'get-deps' failed while processing /media/dev/erlang-app: rebar_abort

[jwilberding]

@ericbmerritt Do you know why this would be?

[ericbmerritt]

Yea. I didn't think about that. Rebar is pulling down the app and checking the version, because we fix the version post compile things when you constrain the dep in rebar. That constraint is checked immediately after the app is pulled into the local deps. This is another example of rebar not making a good package manager.

Unfortunately, there are not a lot of ways to directly fix this since we don't have hooks around pulling the deps and rebar doesn't compile this stuff before it checks the version. There are two work arounds that I can see.

• Don't use the expected tuple (granted not a very good work around)
• Use the new version bumping code. (probably the best way to go)

The latter is new functionality that (as long as the rebar vsn plugin is referenced in the config) will take the version specified in the app.src and semver it. That is, in the above example, you could put {vsn, "2.0.0"} in your app metadata and the vsn plugin would semver it to {vsn, "2.0.0+build.."} in the same way it does now. The main difference is that its not pulling the version from the tag its pulling it from when the version changed in the app.src. Its a quite a bit slower then using tags, but usually the time is so small that you don't notice anyway.

[define-null]

I assume it's possible to make pre and post hook on get-deps command. At pre_hook change expected version to "*" then after get-deps run properly change version back in post_hook, replace version with semver of the dependency app if needed and than run the same check as rebar do.
p.s. As I understand the latest variant your mention discards all the benefits of using this plugin, because we have to watch both carefully for the tags and for the vsn written in app.src file.

[ericbmerritt]

I will look into that. I suspect that those hooks don't exist, for better or worse.

The purpose of this plugin is to ensure that all versions are unique (that is that different code never gets the same version). It supports tags simply as a convenience to the user. So the latest variant still supports all the benefits this plugin is intended to support, it just means that you have to manually add a tag every time you change explicit versions in the app.src. Rather then having the version of the app.src derived from a tag.

[ericbmerritt]

ok. I just dug in and found that these hooks do exist and, at least in newer versions of rebar, allow config updating. The downside is that there is no official api for this stuff so it could change at any time.