-
Notifications
You must be signed in to change notification settings - Fork 209
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
dependency resolution bug using modules with git source #181
Comments
I am experiencing this same issue after trying to manage a relatively complex Puppetfile with mixed git and Forge modules, some of which have dependencies on each other. I am also able to reproduce @bderickson's experience. I tried modifying the versions specified in the Modulefile to see if that tricked librarian-puppet into using the source I specified, but while the output demonstrated that librarian-puppet could differentiate between the version from the Forge (1.4.1) and the version from git (1.4.1-test1), it still elected to install the Forge version. https://gist.github.com/reidmv/9278999 This is a huge problem, and means I can't currently use librarian-puppet for development. :-( |
Digging around in the Puppetfile.lock it looks like based on the names in my Puppetfile, "apt" and "puppetlabs/apt" are represented as different repositories. After modifying my Puppetfile from:
to
...I got what I wanted and the resulting This still feels like a bug to me but less severe and possibly something I can live with and work around for now, assuming that the name "puppetlabs/apt" actually makes the correct installation happen and these minor changes aren't just tickling the randomizer into giving me what I want by chance. |
Added tests in 31d6f5b and yes, the full module name must match or librarian thinks they are different modules and try to install them twice |
…orrectly Update docs and warn about non qualified module names
Updated docs to use qualified module names and added test in dcfa68d |
I've noticed some random behavior when a module is listed in Puppetfile with a git source and is also a dependency of some other module in the Puppetfile. I started testing with version 0.9.10 of librarian-puppet but moved onto 0.9.13 to see if updating would help. In the case of 0.9.10, I think this situation leads to a random result: either the module gets installed from Git or from the forge.
As a quick test, I've cloned the puppetlabs-apt repo and added a dummy commit that adds a file 'blah'.
https://github.com/bderickson/puppetlabs-apt
I created a Puppetfile that just installs this module using the Git source. I pointed it at the particular commit I created.
Using version 0.9.10 of librarian-puppet, I ran librarian-puppet install --clean and found that modules/apt/blah exists afterward, as expected.
So then I added the jenkins module to my Puppetfile, which has a dependency on apt. The Puppetfile and log from running librarian-puppet install --clean --verbose are here:
https://gist.github.com/bderickson/9123716
This time, modules/apt/blah doesn't exist. I made a bash script to run this several times and the result definitely seems random.
If I rerun this test using librarian-puppet 0.9.13, I consistently seem to get apt from the forge. My test file is never present.
So 0.9.13 definitely seems better in that it isn't random, but it's still a little surprising to me that I'm not getting the exact version of apt I'm specifying. Is this because librarian can't know for sure if the commit I'm giving satisfies the jenkins module's requirements? If so, wouldn't some kind of warning be warranted? Maybe use git merge-base --is-ancestor? Though that would assume that tags exist for every forge release, which actually isn't the case for the jenkins module.
Any other suggestions?
The text was updated successfully, but these errors were encountered: