Thanks for the feedback, Gareth and Josh. We need to figure out the steps here, so this is super useful.
A couple minor comments below, and I'm consolidating the replies. On Sun, May 17, 2015 at 8:37 AM, Gareth Rushgrove <gar...@morethanseven.net> wrote: > I'd be happy to see a PR against puppet-module-skeleton > (https://github.com/garethr/puppet-module-skeleton) for how you > envisage testing against puppet-agent to work on (on Travis in this > case). That might be a good way of getting a few people from the > module community to comment too. > > Ditto a PR regarding how the standard acceptance tests in > puppet-module-skeleton would use the puppet-agent package/facter 3. > PRs for both are a great idea. I'll try to work something up in the next couple weeks. I'll probably start with the latter because the need is more pressing there. > > One of the issues I see at present is that no puppet-agent package > exists for OSX I believe, so lots of people who currently run spec > tests locally won't be able to use the puppet-agent builds at present? > Yeah, excellent point. I confirmed that we *will* have OSX puppet-agent builds (for mavericks and yosemite) -- we just haven't quite gotten there yet. Stay tuned! On Sun, May 17, 2015 at 1:03 PM, Joshua Hoblitt <j...@hoblitt.com> wrote: > I don't typically have system packages for either puppet or facter in my > dev environment as I've had bazaar issues in the past where the system > facter has leaked into the bundler env and cause odd test failures. > > Has anyone looked into embedding cfacter in a gem? > Somewhat, yes. Since it's not actually ruby code any longer, my concern is that this approach could get contorted pretty quickly. I.e. we'd end up with a variety of architecture-specific gems, and we'd have a build chain parallel to the puppet-agent build chain to generate these gems. It's also throwaway work once we start converting puppet code itself to be native (unless we did the same trick there but that extends the contortion). > Another implication, which is CI system specific and not a deal breaker, > is that having to install packages would require disabling travis > container based builds. I expect that would impact CI for the vast > majority of forge modules. > Yep, that occurred to me too. Ideally one could install all needed bits as non-root. I agree that it's not a deal-breaker, but it's definitely a nice-to-have. Thanks for the great feedback. Kylo -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALsUZFGLFhWTXJtCjgk62e%3Dvi1b8ZdYhBR9F6yTqOfcGtiL5XA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
