.fixtures.yml functionality in spec helper

[Brett Swift]

https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures

I think I'm doing it wrong. 

I'm testing a module, and specified zack/r10k in my .fixtures.yml file.    It complains that it can't find gcc.  I see that in the r10k/metadata.json file..   weird,  why isn't puppetlabs_spec_helper installing dependencies of my dependencies? 

I see this list that the puppet module tool takes care of for me:

└─┬ zack-r10k (v2.2.8)

  ├─┬ gentoo-portage (v2.2.0)

  │ └── puppetlabs-concat (v1.0.4)

  ├── mhuffnagle-make (v0.0.2)

  ├── puppetlabs-gcc (v0.2.0)

  ├── puppetlabs-git (v0.2.0)

  ├── puppetlabs-inifile (v1.1.3)

  ├── puppetlabs-pe_gem (v0.0.1)

  ├── puppetlabs-ruby (v0.2.1)

  ├── puppetlabs-stdlib (v4.2.2)

  └── puppetlabs-vcsrepo (v1.1.0)

but puppetlabs_spec_helper  doesn't.    <grumble grumble>

I didn't see a ticket for this on tickets.puppetlabs.com.   Is this a feature request, a defect,  or  pebcak ? 

[Garrett Honeycutt]

Hi,

puppetlabs_spec_helper does not do that. You need to specify all of your
dependencies. I would not be interested in the functionality that you
describe because as an author, I need to understand my dependencies and
to properly test them, I want to specify tagged versions in the
.fixtures.yml.

"all required modules should be listed in a file named .fixtures.yml in
the root of the project."[1]

[1] - https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[Wil Cooley]

On Sep 8, 2014 2:21 PM, "Brett Swift" <brett...@gmail.com> 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

[Brett Swift]

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? 

[Wil Cooley]

On Wed, Sep 10, 2014 at 8:39 AM, Brett Swift <brett...@gmail.com> wrote:

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? 

That's a good question and is part of the reason I disabled the automatic dependency resolution. I have no idea what you'd do in that case nor what the PMT would do, so it's up to the person writing the tests to decide.

 

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? 

Something I've wondered myself too; I think it's partly an historical accident --  For a long time, neither the PMT nor puppetlabs_spec_helper were part of Puppet itself; now the PMT is but spec_helper already has an entrenched user base.

Another good reason for them to be separate is to enable a more minimal testing environment. For example, recently I was writing tests for a new module that needed a function from another module I'd written, so either I'd have to add the other module to my fixtures and stub the Ruby library calls the function made or I could exclude the other module and just stub the Puppet function -- that latter was simplest and it would have been messier to have the module installed as a fixture and try to stub the function. (For reference, the MockFunction class from rspec-puppet-utils seems to be the easiest way to stub Puppet functions.)

And yet another good reason to keep them separate is to enable testing with various combinations of dependency versions. At least, one could if someone were to write the code to make the name of the fixtures file selectable...

Wil