Skip to content
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

Closed

Conversation

thijsterlouw
Copy link

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:

  • allow different rebar projects to share the same dependencies, without running into version-mismatches
  • allow to set the shared deps dir via REBAR_SHARED_DEPS_DIR env var (useful for moving all deps to a central location in a large environment without touching all rebar.config files)

@@ -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!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unix

Mac OS, *BSD

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true :-)

Copy link

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.

Copy link
Author

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 :-)

@motiejus
Copy link
Contributor

Thijs,

Would you mind doing one of those:

  1. merge master in
  2. rebase on top of basho/master (probably more preferable for rebar maintainer)

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!

@motiejus
Copy link
Contributor

FYI, here is the merged version (with upstream master):

https://github.com/Motiejus/rebar/tree/merged_with_ver_deps

thijsterlouw and others added 9 commits July 24, 2012 09:12
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)
@motiejus
Copy link
Contributor

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:
https://github.com/spilgames/rebar/tree/shared_deps

There are minor problems which I am aware of. For example, get_shared_deps_dir has ambiguous meaning in the current context, so I had to temporarily rename our get_shared_deps_dir to get_spil_shared_deps_dir, which is terrible. If you have a vision how this behavior could fit to current rebar, please let me know, so I can update all config names, rename functions and update other references.

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 HEAD problems). If you want I can open a new pull request to rebar/rebar, but please let me know I should rebase the commits on top of new master first (shared_deps mentioned above is simply merged). If yes, I would probably squash them to a single commit.

@jaredmorrow
Copy link
Contributor

@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?

@nickelization
Copy link

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants