<base_dir>/rebar.config deps should take precedence over sub projects' deps #222

Closed
tuncer opened this Issue Feb 4, 2014 · 21 comments

Projects

None yet

8 participants

@tuncer

If a dep is requested by both <base_dir>/rebar.config and a sub project, shouldn't rebar always prefer the spec in <base_dir>/rebar.config.

cc @archaelus @jaredmorrow @Vagabond

@archaelus

👍

@Vagabond

What should happen when there is a conflict? Seems like this could cause some odd failures if some info about this is not printed somewhere.

@tuncer

What kind of conflict?

@Vagabond

If you have a dep that wants meck 0.7.2 and base wants meck 0.8.1 and they're incompatible.

@archaelus

@Vagabond but the user did that accidentally instead of my use case where I'm putting (apparently) incompatible deps in base.config deliberately?

I would probably be ok with a notice to this regard when compiling (or better yet, only when fetching/updating deps).

@tuncer

I don't know if we can detect that reliably enough to never issue false warnings. How should that logic work? @Vagabond, are you talking just about build failures or also incompatibilities only noticeable at runtime?

@archaelus

I'm happy to test patches for this issue. It affects our work day-to-day, so we'd love to see it solved.

@puzza007

If this is implemented could it please be behind a command-line option?

@tuncer

As I had suggested when the last require_*_vsn changes were discussed, maybe what rebar actually needs is a real version constraint solver. Opened #240.

@tuncer

If this is implemented could it please be behind a command-line option?

@puzza007 we should not break backwards compatibility and hiding it behind a cmdline option is a bad idea. Having said that, what would break for you, if this would be implemented?

@puzza007

@tuncer doesn't the current rebar fail to build if the versions of deps don't match? That's the behaviour I want/rely on.

@Vagabond

I depends on your deps line, if you don't match the application version and you already have a dep of that name checked out, I don't think rebar will care if you app_vsn regex is .* or something.

I guess sometimes it can be useful to overide a dep, when you know it is safe, but I don't know how to encode that knowledge into a rebar.config file.

@archaelus

The existing behaviour allows a top-level dep to override a transitive dep on get-deps only. Presumably by accident. update-deps will attempt to process the dep twice and usually ends up fetching from the top-level dep and attempting to switch to the branch/tag of the transitive dep - which usually fails.

While I would like top-level deps to unconditionally (and only notify me on a get or update dep command), I would also be with being able to indicate that I am forcing a dep override.

{deps, [{ranch, "", {git, "example.com:ranch.git", "my_custom_hacks"}, [dep_override]},
        {cowboy, "", {git, "git@github.com:extend/cowboy.git", "master}}]}.

This functionality is very important to me as I usually override at least some deps when building production systems.

@tuncer tuncer changed the title from base_dir/rebar.config deps should take precedence over sub projects' deps to `base_dir/rebar.config` deps should take precedence over sub projects' deps Jun 5, 2014
@tuncer tuncer changed the title from `base_dir/rebar.config` deps should take precedence over sub projects' deps to <base_dir>/rebar.config deps should take precedence over sub projects' deps Jun 5, 2014
@tuncer

Thinking about it, I'm not so sure this is a good solution. Do we really want to override transitive deps in the top rebar.config? That doesn't sound too practical or user friendly to me. We should probably resolve #240 and #287 first.

@puzza007

👍

@tsloughter tsloughter closed this Jun 15, 2014
@ferd

Hi, this issue was closed in an attempt to do quick basic filtering, with the benediction of rebar project owners. These issues and pull requests are not issues or code we're spitting on, but given the burden of the task and how much code rot may have happened since these were open is unknown from maintainers at this time. All tickets prior to March 2014 were closed and will be reopened on a per-request basis if we see interest from the reporter or contributor, or if some of the issues reported are still valid after the various patches that have made it since they were opened.

This is a fairly brutal first step to help us get a proper understanding of what is still valid or not, but that has been proven efficient in the past. Sorry for the inconvenience, things should go smoother from there on.

@yfyf

While you can close this to reduce the number of intertwined issues with hopes of adding more structure to the resolution of the general problem, you will eventually have to resolve the problem discussed here anyway. Perhaps the more sensible thing would be to merge some of the issues cross-referenced here (in particular #240 #287 #87) and decide on the future approach. The main task is settling with a sensible and consistent scheme for (transitive) dependency precedence during get-deps / updates / etc, but I'm sure you know.

@puzza007

I think it's best to keep this issue closed and open a new one to do things right. The method described in this issue is both unsafe and potentially very confusing.

@AeroNotix

@puzza007 agreed wholeheartedly.

@tuncer

Yeah, as suggested above, I'd also like to see more fundamental issues resolved first. However, there's probably a need for a tracking ticket with the general problem description and linking to tickets addressing sub-problems.

@ferd

This is closed already. I want to get to creating the overarching ticket that tracks the issue, but I've slowly been familiarizing myself with what rebar currently does so it can be documented first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment