I see your points on wanting to know what your dependencies are, and maybe I'm missing something on how puppet's module path works. As I understand Puppet will resolve the first module on the path if it sees multiple.
Modules should use semantic versioning, so lets assume that in a hypothetical. Also lets assume that I'm developing a module with two direct dependencies, that each depend on stdlib. However one relies on 3.x.x and one 4.x.x. I assume that Puppet can only use one of those.. so which one? I see something that I don't really like in Puppetlabs' supported modules, within the metadata.json files, which is the ">=" syntax, instead of the 3.0.x" syntax. If I'm publishing a module, I don't really want to publish my module saying it will work on stdlib 5.0.0 .. until I've tested it.. so using the 4.x syntax would be my preference. That's a bit of a tangent, but it's relevant to the versioning we're talking about in .fixtures. Ultimately, if my assumption that Puppet - even in dependent modules, can only resolve one version (the first it finds) of a module on the path, then I see where the >= syntax comes from. Otherwise you'd find yourself in dependency deadlock situations. I guess my perspective comes from what might come in the future, with metadata.json ultimately being as required as a gemspec, and the puppet module loader could load more specific versions. Then there is more context around my question - but both Will and Garrett make good points as puppet stands today. Maybe I'm way off base.. it is a bit of a ramble.. sorry about that. It does beg one simple question though. Why wouldn't rspec_puppet_helper forgo .fixtures.yml, instead of using metadata.json? It's a tight coupling.. but maybe a coupling that would be a good idea? On Tuesday, 9 September 2014 11:28:17 UTC-6, Wil Cooley wrote: > > > On Sep 8, 2014 2:21 PM, "Brett Swift" <brett...@gmail.com <javascript:>> > wrote: > > > > why isn't puppetlabs_spec_helper installing dependencies of my > dependencies? > ... > > but puppetlabs_spec_helper doesn't. <grumble grumble> > > > > I didn't see a ticket for this ontickets.puppetlabs.com. Is this a > feature request, a defect, or pebcak ? > > Assuming you're talking about modules installed with "forge_modules" > (which I wrote the first cut of) instead of "repositories", I consciously > added the flag to ignore dependencies with the PMT with the expectation > that you should know what your dependencies are and be explicit about them. > > That said, I have found myself annoyed with having to remember to add all > of the (>1)th-order dependencies, especially for our mass of internal > modules. > > It also brings up the broader question of whether you really should need > to track the transitive closure of your dependencies. Other packaging > systems don't make you, so should you really have to here? > > It could be added as a configuration parameter, but then the next question > is where should that be? A configuration section in .fixtures.yml? An > environment variable? Then I get side-tracked thinking that maybe the name > of .fixtures.yml itself should be selectable by environment variable so you > could test with different combinations of versions of dependencies, etc. > > Wil > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ec21724e-5059-422d-88ab-051aa05a6b75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
