Jira (FACT-853) Move native facter codebase to facter#master

[Michael Smith (JIRA)]

Title: Message Title

Michael Smith commented on FACT-853   Re: Move native facter codebase to facter#master My current thoughts on use-cases are: Anyone using Puppet 4.x as a gem will pick up Facter 2.x. If they want to use Facter 3, perform manual install steps. A Puppet module developer can Use the Puppet gem for spec testing Use AIO, with development gems installed into it, for spec testing (later to become a Module SDK) A Puppet source developer can Install Facter 3 manually, then develop Puppet Later, install a development environment using Devkit (will be the easiest route with native agent) A Puppet specs run can Use the Puppet gem Should have no dependence on Facter implementation, therefore Facter 2.x vs Facter 3 doesn't matter unless we have API changes. Move to completely mocking Facter behavior in Puppet specs based on API definition. Acceptance catches unexpected changes in Facter API. Mocking Facter API in Puppet specs could be contentious; that covers integration testing, which should cover code integration. That's not easy to do with separately built native packages. Ensuring integration tests run with actual Facter is the main argument for providing a Facter 3 binary gem, and in the future having the native agent build process depend on Facter 3 binaries. Add Comment   This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.