facter 2.0.1.rc1-universal-darwin

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 09203ccf21d37452ffef44bdbd3a3dccecc09ed8
+  data.tar.gz: a439679e95420277cdd03065bd1ad90f3ab30a79
+SHA512:
+  metadata.gz: a8d74b12820a4741f5c97900c1e9cf5848a5c1688e6a34e4ed05f2102b8b1ea946df0d4bc1d1974f5474633507996d43a7e0c05767ff936717fd103c60255fc3
+  data.tar.gz: 28bed2f6624c92256e5c284c4dcc105c37c8ba7078dc7f1a6c3cd1cd9b1c2631f0b261dc9e089413efaf909249fbc8a8ec1f72c4ca16ccd403233a60e098ac3c

data/COMMITTERS.md

@@ -0,0 +1,194 @@
+Committing changes to Facter
+====
+
+We would like to make it easier for community members to contribute to facter
+using pull requests, even if it makes the task of reviewing and committing
+these changes a little harder.  Pull requests are only ever based on a single
+branch, however, we maintain more than one active branch.  As a result
+contributors should target their changes at the facter-2 branch. This makes the
+process of contributing a little easier for the contributor since they don't
+need to concern themselves with the question, "What branch do I base my changes
+on?"  This is already called out in the [CONTRIBUTING.md](http://goo.gl/XRH2J).
+
+Therefore, it is the responsibility of the committer to re-base the change set
+on the appropriate branch which should receive the contribution.
+
+The rest of this document addresses the concerns of the committer.  This
+document will help guide the committer decide which branch to base, or re-base
+a contribution on top of.  This document also describes our branch management
+strategy, which is closely related to the decision of what branch to commit
+changes into.
+
+Terminology
+====
+
+Many of these terms have more than one meaning.  For the purposes of this
+document, the following terms refer to specific things.
+
+**contributor** - A person who makes a change to facter and submits a change
+set in the form of a pull request.
+
+**change set** - A set of discrete patches which combined together form a
+contribution.  A change set takes the form of Git commits and is submitted to
+facter in the form of a pull request.
+
+**committer** - A person responsible for reviewing a pull request and then
+making the decision what base branch to merge the change set into.
+
+**base branch** - A branch in Git that contains an active history of changes
+and will eventually be released using semantic version guidelines.  The branch
+named master will always exist as a base branch.
+
+Committer Guide
+====
+
+This section provides a guide to follow while committing change sets to facter
+base branches.
+
+How to decide what release(s) should be patched
+---
+
+This section provides a guide to help a committer decide the specific base
+branch that a change set should be merged into.
+
+The latest minor release of a major release is the only base branch that should
+be patched. Older minor releases in a major release do not get patched. Before
+the switch to [semantic versions](http://semver.org/) committers did not have
+to think about the difference between minor and major releases.  Committing to
+the latest minor release of a major release is a policy intended to limit the
+number of active base branches that must be managed.
+
+Security patches are handled as a special case.  Security patches may be
+applied to earlier minor releases of a major release.
+
+How to commit a change set to multiple base branches
+---
+
+A change set may apply to multiple releases.  In this situation the change set
+needs to be committed to multiple base branches.  This section provides a guide
+for how to merge patches across releases, e.g. 2.7 is patched, how should the
+changes be applied to 3.0?
+
+First, merge the change set into the lowest numbered base branch, e.g. 2.7.
+Next, merge the changed base branch up through all later base branches by using
+the `--no-ff --log` git merge options.  We commonly refer to this as our "merge
+up process" because we merge in once, then merge up multiple times.
+
+When a new minor release branch is created (e.g. 3.1.x) then the previous one
+is deleted (e.g. 3.0.x). Any security or urgent fixes that might have to be
+applied to the older code line is done by creating an ad-hoc branch from the
+tag of the last patch release of the old minor line.
+
+Code review checklist
+---
+
+This section aims to provide a checklist of things to look for when reviewing a
+pull request and determining if the change set should be merged into a base
+branch:
+
+ * All tests pass
+ * Are there any platform gotchas? (Does a change make an assumption about
+   platform specific behavior that is incompatible with other platforms?  e.g.
+   Windows paths vs. POSIX paths.)
+ * Is the change backwards compatible? (It should be)
+ * Are there YARD docs for API changes?
+ * Does the change set also require documentation changes? If so is the
+   documentation being kept up to date?
+ * Does the change set include clean code?  (software code that is formatted
+   correctly and in an organized manner so that another coder can easily read
+   or modify it.)  HINT: `git diff --check`
+ * Does the change set conform to the contributing guide?
+
+
+Commit citizen guidelines:
+---
+
+This section aims to provide guidelines for being a good commit citizen by
+paying attention to our automated build tools.
+
+ * Don’t push on a broken build.  (A broken build is defined as a failing job
+   in the [Facter](https://jenkins.puppetlabs.com/view/Facter/)
+   page.)
+ * Watch the build until your changes have gone through green
+ * Update the ticket status and target version.  The target version field in
+   our issue tracker should be updated to be the next release of facter.  For
+   example, if the most recent release of facter is 2.0.1 and you merge a
+   backwards compatible change set into facter-2, then the target version should
+   be 2.1.0 in the issue tracker.)
+ * Ensure the pull request is closed (Hint: amend your merge commit to contain
+   the string `closes #123` where 123 is the pull request number.
+
+Example Procedure
+====
+
+This section helps a committer rebase a contribution onto an earlier base
+branch, then merge into the base branch and up through all active base
+branches.
+
+Suppose a contributor submits a pull request based on facter-2.  The change set
+fixes a bug reported against facter 2.0.1 which is the most recently released
+version of facter.
+
+In this example the committer should rebase the change set onto the stable
+branch since this is a bug rather than new functionality.
+
+First, the committer pulls down the branch using the `hub` gem.  This tool
+automates the process of adding the remote repository and creating a local
+branch to track the remote branch.
+
+    $ hub checkout https://github.com/puppetlabs/facter/pull/1234
+    Branch jeffmccune-fix_foo_error set up to track remote branch fix_foo_error from jeffmccune.
+    Switched to a new branch 'jeffmccune-fix_foo_error'
+
+At this point the topic branch is a descendant of facter-2, but we want it to
+descend from stable.  The committer creates a new branch then re-bases the
+change set:
+
+    $ git branch bug/stable/fix_foo_error
+    $ git rebase --onto stable master bug/stable/fix_foo_error
+    First, rewinding head to replay your work on top of it...
+    Applying: (#23456) Fix FooError that always bites users in 2.0.1
+
+The `git rebase` command may be interpreted as, "First, check out the branch
+named `bug/stable/fix_foo_error`, then take the changes that were previously
+based on `facter-2` and re-base them onto `stable`.
+
+Now that we have a topic branch containing the change set based on the correct
+release branch, the committer merges in:
+
+    $ git checkout stable
+    Switched to branch 'stable'
+    $ git merge --no-ff --log bug/stable/fix_foo_error
+    Merge made by the 'recursive' strategy.
+     foo | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 foo
+
+Once merged into the first base branch, the committer merges up to facter-2:
+
+    $ git checkout facter-2
+    Switched to branch 'facter-2'
+    $ git merge --no-ff --log stable
+    Merge made by the 'recursive' strategy.
+     foo | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 foo
+
+And then merges up to master:
+
+    $ git checkout master
+    Switched to branch 'master'
+    $ git merge --no-ff --log stable
+    Merge made by the 'recursive' strategy.
+     foo | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 foo
+
+Once the change set has been merged "in and up." the committer pushes.  (Note,
+the checklist should be complete at this point.)  Note that the stable,
+facter-2 and master branches are being pushed at the same time.
+
+    $ git push puppetlabs master:master facter-2:facter-2 stable:stable
+
+That's it!  The committer then updates the pull request, updates the issue in
+our issue tracker, and keeps an eye on the build status.

data/CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# How to contribute
+
+Third-party patches are essential for keeping facter great. We simply can't
+access the huge number of platforms and myriad configurations for running
+facter. We want to keep it as easy as possible to contribute changes that
+get things working in your environment. There are a few guidelines that we
+need contributors to follow so that we can have a chance of keeping on
+top of things.
+
+## Getting Started
+
+* Make sure you have a [Jira account](http://tickets.puppetlabs.com)
+* Make sure you have a [GitHub account](https://github.com/signup/free)
+* Submit a ticket for your issue, assuming one does not already exist.
+  * Clearly describe the issue including steps to reproduce when it is a bug.
+  * Make sure you fill in the earliest version that you know has the issue.
+* Fork the repository on GitHub
+
+## Making Changes
+
+* Create a topic branch from where you want to base your work.
+  * This is usually the facter-2 branch.
+  * Only target release branches if you are certain your fix must be on that
+    branch.
+  * To quickly create a topic branch based on facter-2; `git branch
+    fix/facter-2/my_contribution facter-2` then checkout the new branch with `git
+    checkout fix/facter-2/my_contribution`.  Please avoid working directly on the
+    `facter-2` branch.
+* Make commits of logical units.
+* Check for unnecessary whitespace with `git diff --check` before committing.
+* Make sure your commit messages are in the proper format.
+
+````
+    (#99999) Make the example in CONTRIBUTING imperative and concrete
+
+    Without this patch applied the example commit message in the CONTRIBUTING
+    document is not a concrete example.  This is a problem because the
+    contributor is left to imagine what the commit message should look like
+    based on a description rather than an example.  This patch fixes the
+    problem by making the example concrete and imperative.
+
+    The first line is a real life imperative statement with a ticket number
+    from our issue tracker.  The body describes the behavior without the patch,
+    why this is a problem, and how the patch fixes the problem when applied.
+````
+
+* Make sure you have added the necessary tests for your changes.
+* Run _all_ the tests to assure nothing else was accidentally broken.
+
+## Submitting Changes
+
+* Sign the [Contributor License Agreement](http://links.puppetlabs.com/cla).
+* Push your changes to a topic branch in your fork of the repository.
+* Submit a pull request to the repository in the puppetlabs organization.
+* Update your ticket to mark that you have submitted code and are ready for it to be reviewed.
+  * Include a link to the pull request in the ticket
+
+# Additional Resources
+
+* [More information on contributing](http://links.puppetlabs.com/contribute-to-puppet)
+* [Bug tracker (Jira)](http://tickets.puppetlabs.com)
+* [Contributor License Agreement](http://links.puppetlabs.com/cla)
+* [General GitHub documentation](http://help.github.com/)
+* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
+* #puppet-dev IRC channel on freenode.org

data/Gemfile

@@ -0,0 +1,43 @@
+if gem_source = ENV['GEM_SOURCE']
+  source gem_source
+else
+  source "https://rubygems.org"
+end
+
+# C Ruby (MRI) or Rubinius, but NOT Windows
+platforms :ruby do
+  gem 'watchr', :group => :development
+  gem 'pry', :group => :development
+  gem 'yard', :group => :development
+  gem 'redcarpet', '<= 2.3.0', :group => :development
+end
+
+group :development, :test do
+  gem 'rake'
+  gem 'rspec', "~> 2.11.0"
+  gem 'mocha', "~> 0.10.5"
+  gem 'json', "~> 1.7", :platforms => :ruby
+  gem 'puppetlabs_spec_helper'
+end
+
+require 'yaml'
+data = YAML.load_file(File.join(File.dirname(__FILE__), 'ext', 'project_data.yaml'))
+bundle_platforms = data['bundle_platforms']
+data['gem_platform_dependencies'].each_pair do |gem_platform, info|
+  if bundle_deps = info['gem_runtime_dependencies']
+    bundle_platform = bundle_platforms[gem_platform] or raise "Missing bundle_platform"
+    platform(bundle_platform.intern) do
+      bundle_deps.each_pair do |name, version|
+        gem(name, version, :require => false)
+      end
+    end
+  end
+end
+
+gem 'facter', ">= 1.0.0", :path => File.expand_path("..", __FILE__)
+
+if File.exists? "#{__FILE__}.local"
+  eval(File.read("#{__FILE__}.local"), binding)
+end
+
+# vim:ft=ruby

data/LICENSE

@@ -0,0 +1,15 @@
+Facter - Host Fact Detection and Reporting
+
+Copyright 2005-2012 Puppet Labs Inc
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

data/README.md

@@ -0,0 +1,33 @@
+Facter
+======
+
+This package is largely meant to be a library for collecting facts about your
+system.  These facts are mostly strings (i.e., not numbers), and are things
+like the output of `uname`, public ssh keys, the number of processors, etc.
+
+See `bin/facter` for an example of the interface.
+
+Running Facter
+--------------
+
+Run the `facter` binary on the command for a full list of facts supported on
+your host.
+
+Adding your own facts
+---------------------
+
+See the [Adding Facts](http://docs.puppetlabs.com/guides/custom_facts.html)
+page for details of how to add your own custom facts to Facter.
+
+Running Specs
+-------------
+
+* bundle install --path .bundle/gems
+* bundle exec rake spec
+
+Note: external facts in the system facts.d directory can cause spec failures.
+
+Further Information
+-------------------
+
+See http://www.puppetlabs.com/puppet/related-projects/facter for more details.

data/Rakefile

@@ -0,0 +1,79 @@
+# Rakefile for facter
+
+# We need access to the Puppet.version method
+$LOAD_PATH.unshift(File.expand_path("lib"))
+require 'facter/version'
+
+$LOAD_PATH << File.join(File.dirname(__FILE__), 'tasks')
+
+require 'rake'
+Dir['tasks/**/*.rake'].each { |t| load t }
+
+begin
+  load File.join(File.dirname(__FILE__), 'ext', 'packaging', 'packaging.rake')
+rescue LoadError
+end
+
+['rubygems',
+'rspec',
+'rspec/core/rake_task',
+'rcov',].each do |lib|
+  begin
+    require lib
+  rescue LoadError
+  end
+end
+
+
+build_defs_file = 'ext/build_defaults.yaml'
+if File.exist?(build_defs_file)
+  begin
+    require 'yaml'
+    @build_defaults ||= YAML.load_file(build_defs_file)
+  rescue Exception => e
+    STDERR.puts "Unable to load yaml from #{build_defs_file}:"
+    STDERR.puts e
+  end
+  @packaging_url  = @build_defaults['packaging_url']
+  @packaging_repo = @build_defaults['packaging_repo']
+  raise "Could not find packaging url in #{build_defs_file}" if @packaging_url.nil?
+  raise "Could not find packaging repo in #{build_defs_file}" if @packaging_repo.nil?
+
+  namespace :package do
+    desc "Bootstrap packaging automation, e.g. clone into packaging repo"
+    task :bootstrap do
+      if File.exist?("ext/#{@packaging_repo}")
+        puts "It looks like you already have ext/#{@packaging_repo}. If you don't like it, blow it away with package:implode."
+      else
+        cd 'ext' do
+          %x{git clone #{@packaging_url}}
+        end
+      end
+    end
+    desc "Remove all cloned packaging automation"
+    task :implode do
+      rm_rf "ext/#{@packaging_repo}"
+    end
+  end
+end
+
+task :default do
+  sh %{rake -T}
+end
+
+if defined?(RSpec::Core::RakeTask)
+  desc "Run all specs"
+  RSpec::Core::RakeTask.new do |t|
+    t.pattern ='spec/{unit,integration}/**/*_spec.rb'
+    t.fail_on_error = true
+  end
+
+  RSpec::Core::RakeTask.new('spec:rcov') do |t|
+    t.pattern ='spec/{unit,integration}/**/*_spec.rb'
+    t.fail_on_error = true
+    if defined?(Rcov)
+      t.rcov = true
+      t.rcov_opts = ['--exclude', 'spec/*,test/*,results/*,/usr/lib/*,/usr/local/lib/*,gems/*']
+    end
+  end
+end

data/bin/facter

@@ -0,0 +1,16 @@
+#!/usr/bin/env ruby
+
+# Bundler and rubygems maintain a set of directories from which to
+# load gems. If Bundler is loaded, let it determine what can be
+# loaded. If it's not loaded, then use rubygems. But do this before
+# loading any facter code, so that our gem loading system is sane.
+if not defined? ::Bundler
+  begin
+    require 'rubygems'
+  rescue LoadError
+  end
+end
+
+require 'facter/application'
+
+Facter::Application.run(ARGV)