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

dependency resolution bug using modules with git source #181

Closed
bderickson opened this issue Feb 21, 2014 · 4 comments
Closed

dependency resolution bug using modules with git source #181

bderickson opened this issue Feb 21, 2014 · 4 comments

Comments

@bderickson
Copy link

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.

#!/usr/bin/env ruby
forge "http://forge.puppetlabs.com"
mod "apt",
  :git => "https://github.com/bderickson/puppetlabs-apt",
  :ref => "00221522dc7546c9b01f199641be52ba62fb5285"

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?

@reidmv
Copy link

reidmv commented Feb 28, 2014

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. :-(

@reidmv
Copy link

reidmv commented Feb 28, 2014

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:

forge "http://forge.puppetlabs.com"

mod "apt",
  :git => "https://github.com/reidmv/puppetlabs-apt",
  :ref => "0a753ae6962fb139fd0f1d374e739b1b5a504b5a"

mod "jenkins",
  :git => "git://github.com/jenkinsci/puppet-jenkins.git",
  :ref => "055256453bf2d55d4ed7c5d8d55a827277b9ff34"

to

forge "http://forge.puppetlabs.com"

mod "puppetlabs/apt",
  :git => "https://github.com/reidmv/puppetlabs-apt",
  :ref => "0a753ae6962fb139fd0f1d374e739b1b5a504b5a"

mod "jenkins",
  :git => "git://github.com/jenkinsci/puppet-jenkins.git",
  :ref => "055256453bf2d55d4ed7c5d8d55a827277b9ff34"

...I got what I wanted and the resulting apt module was my git checkout.

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.

@carlossg
Copy link
Collaborator

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

carlossg pushed a commit that referenced this issue Mar 31, 2014
…orrectly

Update docs and warn about non qualified module names
@carlossg
Copy link
Collaborator

Updated docs to use qualified module names and added test in dcfa68d

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

No branches or pull requests

3 participants