New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Versioned shared dependencies #262
Versioned shared dependencies #262
Conversation
…rebar into improvements
…rebar into improvements
@@ -111,6 +113,17 @@ setup_env(_Config) -> | |||
end, | |||
[{"REBAR_DEPS_DIR", DepsDir}, ERL_LIBS]. | |||
|
|||
%% Set symlinks from DEPS dir to SHARED_DEPS dir | |||
%% This only works for Linux-based OS! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unix
Mac OS, *BSD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to erts sources file:make_link/2 works on newer Windows versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make_link seems to make a hard link, which does not work for directories. I did change my function to use file:make_symlink/2 and handle enotsup gracefully.
see next commit :-)
Thijs, Would you mind doing one of those:
I am using this feature in our CI environment, but need some patches from upstream rebar, too. Merging is not trivial, since it yields quite a bit of merge conflicts which I am not confident resolving myself. Thanks! |
FYI, here is the merged version (with upstream master): |
Conflicts: Makefile src/rebar_utils.erl
When using the shared deps directory, the deps in an application are actually symlinked to the shared directory. This means that when the deps are being deleted, only the symlinks are being removed. This change fixes it by following the symlink and actually removing the shared dependency.
* rebar_deps:get_shared_deps(D) now properly returns {true, _}/{false, _} tuples instead of always {true, _} * furthermore, it constructs the correct full path to the shared directory (with the branch/rev/tag suffix)
Just to let you know I ported this functionality to a more recent version of rebar (71c717d or 2.1.0-pre-42-g71c717d), here: There are minor problems which I am aware of. For example, We have been using this functionality for half a year now, and it works well. Especially on CI machines, where zero compilation time of dependencies is a major advantage (all our dependencies are tagged, so we don't run into |
@thijsterlouw ping. We abandoned basho/rebar when rebar/rebar was created. We (basho) are now back to using basho/rebar, is this PR something you'd still like to see? Has it already been merged into rebar/rebar? |
Since there hasn't been any update on this PR in so long, I'm going to assume we can close this. (basho/rebar is no longer up to date with rebar/rebar, and Basho will be switching to rebar3 soon anyway.) |
see issue #257 for a full explanation. We have tested this with Git and mainly with tags and master/head. It works great for this. Furthermore it works very nicely together with the solution for issue 258 (next pull request). It depends on symlinks (supported in Unix + Windows after Vista)
Major improvements: