vagrant-packet 0.1.2 → 0.1.3

data/vendor/bundle/ruby/2.5.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/plugins/guest-capabilities.html.md

@@ -1,104 +0,0 @@
----
-layout: "docs"
-page_title: "Guest Capabilities - Plugin Development"
-sidebar_current: "plugins-guestcapabilities"
-description: |-
-  This page documents how to add new capabilities for guests to Vagrant,
-  allowing Vagrant to perform new actions on specific guest operating systems.
-  Prior to reading this, you should be familiar with the plugin development
-  basics.
----
-
-# Plugin Development: Guest Capabilities
-
-This page documents how to add new capabilities for [guests](/docs/plugins/guests.html)
-to Vagrant, allowing Vagrant to perform new actions on specific guest
-operating systems.
-Prior to reading this, you should be familiar
-with the [plugin development basics](/docs/plugins/development-basics.html).
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
-  advanced topic that only experienced Vagrant users who are reasonably
-  comfortable with Ruby should approach.
-</div>
-
-Guest capabilities augment [guests](/docs/plugins/guests.html) by attaching
-specific "capabilities" to the guest, which are actions that can be performed
-in the context of that guest operating system.
-
-The power of capabilities is that plugins can add new capabilities to
-existing guest operating systems without modifying the core of Vagrant.
-In earlier versions of Vagrant, all the guest logic was contained in the
-core of Vagrant and was not easily augmented.
-
-## Definition Component
-
-Within the context of a plugin definition, guest capabilities can be
-defined like so:
-
-```ruby
-guest_capability "ubuntu", "my_custom_capability" do
-  require_relative "cap/my_custom_capability"
-  Cap::MyCustomCapability
-end
-```
-
-Guest capabilities are defined by calling the `guest_capability` method,
-which takes two parameters: the guest to add the capability to, and the
-name of the capability itself. Then, the block argument returns a class
-that implements a method named the same as the capability. This is
-covered in more detail in the next section.
-
-## Implementation
-
-Implementations should be classes or modules that have a method with
-the same name as the capability. The method must be immediately accessible
-on the class returned from the `guest_capability` component, meaning that
-if it is an instance method, an instance should be returned.
-
-In general, class methods are used for capabilities. For example, here
-is the implementation for the capability above:
-
-```ruby
-module Cap
-  class MyCustomCapability
-    def self.my_custom_capability(machine)
-      # implementation
-    end
-  end
-end
-```
-
-All capabilities get the Vagrant machine object as the first argument.
-Additional arguments are determined by the specific capability, so view the
-documentation or usage of the capability you are trying to implement for more
-information.
-
-Some capabilities must also return values back to the caller, so be aware
-of that when implementing a capability.
-
-Capabilities always have access to communication channels such as SSH
-on the machine, and the machine can generally be assumed to be booted.
-
-## Calling Capabilities
-
-Since you have access to the machine in every capability, capabilities can
-also call _other_ capabilities. This is useful for using the inheritance
-mechanism of capabilities to potentially ask helpers for more information.
-For example, the "redhat" guest has a "network\_scripts\_dir" capability that
-simply returns the directory where networking scripts go.
-
-Capabilities on child guests of RedHat such as CentOS or Fedora use this
-capability to determine where networking scripts go, while sometimes overriding
-it themselves.
-
-Capabilities can be called like so:
-
-```ruby
-machine.guest.capability(:capability_name)
-```
-
-Any additional arguments given to the method will be passed on to the
-capability, and the capability will return the value that the actual
-capability returned.

data/vendor/bundle/ruby/2.5.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/plugins/guests.html.md

@@ -1,102 +0,0 @@
----
-layout: "docs"
-page_title: "Custom Guests - Plugin Development"
-sidebar_current: "plugins-guests"
-description: |-
-  This page documents how to add new guest OS detection to Vagrant, allowing
-  Vagrant to properly configure new operating systems. Prior to reading this,
-  you should be familiar with the plugin development basics.
----
-
-# Plugin Development: Guests
-
-This page documents how to add new guest OS detection to Vagrant, allowing
-Vagrant to properly configure new operating systems.
-Prior to reading this, you should be familiar
-with the [plugin development basics](/docs/plugins/development-basics.html).
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
-  advanced topic that only experienced Vagrant users who are reasonably
-  comfortable with Ruby should approach.
-</div>
-
-Vagrant has many features that requires doing guest OS-specific
-actions, such as mounting folders, configuring networks, etc. These
-tasks vary from operating system to operating system. If you find that
-one of these does not work for your operating system, then maybe the
-guest implementation is incomplete or incorrect.
-
-## Definition Component
-
-Within the context of a plugin definition, new guests can be defined
-like so:
-
-```ruby
-guest "ubuntu" do
-  require_relative "guest"
-  Guest
-end
-```
-
-Guests are defined with the `guest` method. The first argument is the
-name of the guest. This name is not actually used anywhere, but may in the
-future, so choose something helpful. Then, the block argument returns a
-class that implements the `Vagrant.plugin(2, :guest)` interface.
-
-## Implementation
-
-Implementations of guests subclass `Vagrant.plugin("2", "guest")`. Within
-this implementation, only the `detect?` method needs to be implemented.
-
-The `detect?` method is called by Vagrant at some point after the machine
-is booted in order to determine what operating system the guest is running.
-If you detect that it is your operating system, return `true` from `detect?`.
-Otherwise, return `false`.
-
-Communication channels to the machine are guaranteed to be running at this
-point, so the most common way to detect the operating system is to do
-some basic testing:
-
-```
-class MyGuest < Vagrant.plugin("2", "guest")
-  def detect?(machine)
-    machine.communicate.test("cat /etc/myos-release")
-  end
-end
-```
-
-After detecting an OS, that OS is used for various
-[guest capabilities](/docs/plugins/guest-capabilities.html) that may be
-required.
-
-## Guest Inheritance
-
-Vagrant also supports a form of inheritance for guests, since sometimes
-operating systems stem from a common root. A good example of this is Linux
-is the root of Debian, which further is the root of Ubuntu in many cases.
-Inheritance allows guests to share a lot of common behavior while allowing
-distro-specific overrides.
-
-Inheritance is not done via standard Ruby class inheritance because Vagrant
-uses a custom [capability-based](/docs/plugins/guest-capabilities.html) system.
-Vagrant handles inheritance dispatch for you.
-
-To subclass another guest, specify that guest's name as a second parameter
-in the guest definition:
-
-```ruby
-guest "ubuntu", "debian" do
-  require_relative "guest"
-  Guest
-end
-```
-
-With the above component, the "ubuntu" guest inherits from "debian." When
-a capability is looked up for "ubuntu", all capabilities from "debian" are
-also available, and any capabilities in "ubuntu" override parent capabilities.
-
-When detecting operating systems with `detect?`, Vagrant always does a
-depth-first search by searching the children operating systems before
-checking their parents. Therefore, it is guaranteed in the above example
-that the `detect?` method on "ubuntu" will be called before "debian."

data/vendor/bundle/ruby/2.5.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/plugins/host-capabilities.html.md

@@ -1,64 +0,0 @@
----
-layout: "docs"
-page_title: "Host Capabilities - Plugin Development"
-sidebar_current: "plugins-hostcapabilities"
-description: |-
-  This page documents how to add new capabilities for hosts to Vagrant, allowing Vagrant to perform new actions on specific host operating systems. Prior to reading this, you should be familiar with the plugin development basics.
----
-
-# Plugin Development: Host Capabilities
-
-This page documents how to add new capabilities for [hosts](/docs/plugins/hosts.html)
-to Vagrant, allowing Vagrant to perform new actions on specific host
-operating systems.
-Prior to reading this, you should be familiar
-with the [plugin development basics](/docs/plugins/development-basics.html).
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
-  advanced topic that only experienced Vagrant users who are reasonably
-  comfortable with Ruby should approach.
-</div>
-
-Host capabilities augment [hosts](/docs/plugins/hosts.html) by attaching
-specific "capabilities" to the host, which are actions that can be performed
-in the context of that host operating system.
-
-The power of capabilities is that plugins can add new capabilities to
-existing host operating systems without modifying the core of Vagrant.
-In earlier versions of Vagrant, all the host logic was contained in the
-core of Vagrant and was not easily augmented.
-
-## Definition and Implementation
-
-The definition and implementation of host capabilities is identical
-to [guest capabilities](/docs/plugins/guest-capabilities.html).
-
-The main difference from guest capabilities, however, is that instead of
-taking a machine as the first argument, all host capabilities take an
-instance of `Vagrant::Environment` as their first argument.
-
-Access to the environment allows host capabilities to access global state,
-specific machines, and also allows them to call other host capabilities.
-
-## Calling Capabilities
-
-Since you have access to the environment in every capability, capabilities can
-also call _other_ host capabilities. This is useful for using the inheritance
-mechanism of capabilities to potentially ask helpers for more information.
-For example, the "linux" guest has a "nfs\_check\_command" capability that
-returns the command to use to check if NFS is running.
-
-Capabilities on child guests of Linux such as RedHat or Arch use this
-capability to mostly inherit the Linux behavior, except for this minor
-detail.
-
-Capabilities can be called like so:
-
-```ruby
-environment.host.capability(:capability_name)
-```
-
-Any additional arguments given to the method will be passed on to the
-capability, and the capability will return the value that the actual
-capability returned.

data/vendor/bundle/ruby/2.5.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/plugins/hosts.html.md

@@ -1,99 +0,0 @@
----
-layout: "docs"
-page_title: "Custom Hosts - Plugin Development"
-sidebar_current: "plugins-hosts"
-description: |-
-  This page documents how to add new host OS detection to Vagrant, allowing
-  Vagrant to properly execute host-specific operations on new operating systems.
-  Prior to reading this, you should be familiar with the plugin development
-  basics.
----
-
-# Plugin Development: Hosts
-
-This page documents how to add new host OS detection to Vagrant, allowing
-Vagrant to properly execute host-specific operations on new operating systems.
-Prior to reading this, you should be familiar
-with the [plugin development basics](/docs/plugins/development-basics.html).
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
-  advanced topic that only experienced Vagrant users who are reasonably
-  comfortable with Ruby should approach.
-</div>
-
-Vagrant has some features that require host OS-specific actions, such as
-exporting NFS folders. These tasks vary from operating system to operating
-system. Vagrant uses host detection as well as
-[host capabilities](/docs/plugins/host-capabilities.html) to perform these
-host OS-specific operations.
-
-## Definition Component
-
-Within the context of a plugin definition, new hosts can be defined
-like so:
-
-```ruby
-host "ubuntu" do
-  require_relative "host"
-  Host
-end
-```
-
-Hosts are defined with the `host` method. The first argument is the
-name of the host. This name is not actually used anywhere, but may in the
-future, so choose something helpful. Then, the block argument returns a
-class that implements the `Vagrant.plugin(2, :host)` interface.
-
-## Implementation
-
-Implementations of hosts subclass `Vagrant.plugin("2", "host")`. Within
-this implementation, only the `detect?` method needs to be implemented.
-
-The `detect?` method is called by Vagrant very early on in its initialization
-process to determine if the OS that Vagrant is running on is this host.
-If you detect that it is your operating system, return `true` from `detect?`.
-Otherwise, return `false`.
-
-```
-class MyHost < Vagrant.plugin("2", "host")
-  def detect?(environment)
-    File.file?("/etc/arch-release")
-  end
-end
-```
-
-After detecting an OS, that OS is used for various
-[host capabilities](/docs/plugins/host-capabilities.html) that may be
-required.
-
-## Host Inheritance
-
-Vagrant also supports a form of inheritance for hosts, since sometimes
-operating systems stem from a common root. A good example of this is Linux
-is the root of Debian, which further is the root of Ubuntu in many cases.
-Inheritance allows hosts to share a lot of common behavior while allowing
-distro-specific overrides.
-
-Inheritance is not done via standard Ruby class inheritance because Vagrant
-uses a custom [capability-based](/docs/plugins/host-capabilities.html) system.
-Vagrant handles inheritance dispatch for you.
-
-To subclass another host, specify that host's name as a second parameter
-in the host definition:
-
-```ruby
-host "ubuntu", "debian" do
-  require_relative "host"
-  Host
-end
-```
-
-With the above component, the "ubuntu" host inherits from "debian." When
-a capability is looked up for "ubuntu", all capabilities from "debian" are
-also available, and any capabilities in "ubuntu" override parent capabilities.
-
-When detecting operating systems with `detect?`, Vagrant always does a
-depth-first search by searching the children operating systems before
-checking their parents. Therefore, it is guaranteed in the above example
-that the `detect?` method on "ubuntu" will be called before "debian."

data/vendor/bundle/ruby/2.5.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/plugins/index.html.md

@@ -1,27 +0,0 @@
----
-layout: "docs"
-page_title: "Plugins"
-sidebar_current: "plugins"
-description: |-
-  Vagrant comes with many great features out of the box to get your environments
-  up and running. Sometimes, however, you want to change the way Vagrant does
-  something or add additional functionality to Vagrant. This can be done via
-  Vagrant plugins.
----
-
-# Plugins
-
-Vagrant comes with many great features out of the box to get your environments up
-and running. Sometimes, however, you want to change the way Vagrant does something
-or add additional functionality to Vagrant. This can be done via Vagrant
-_plugins_.
-
-Plugins are powerful, first-class citizens that extend Vagrant using a
-well-documented, stable API that can withstand major version upgrades.
-
-In fact, most of the core of Vagrant is [implemented using plugins](https://github.com/hashicorp/vagrant/tree/master/plugins).
-Since Vagrant [dogfoods](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) its own
-plugin API, you can be confident that the interface is stable and well supported.
-
-Use the navigation on the left below the "Plugins" section to learn more
-about how to use and build your own plugins.

data/vendor/bundle/ruby/2.5.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/plugins/packaging.html.md

@@ -1,114 +0,0 @@
----
-layout: "docs"
-page_title: "Packaging and Distribution - Plugin Development"
-sidebar_current: "plugins-packaging"
-description: |-
-  This page documents how to organize the file structure of your plugin
-  and distribute it so that it is installable using standard installation
-  methods. Prior to reading this, you should be familiar with the plugin
-  development basics.
----
-
-# Plugin Development: Packaging & Distribution
-
-This page documents how to organize the file structure of your plugin
-and distribute it so that it is installable using
-[standard installation methods](/docs/plugins/usage.html).
-Prior to reading this, you should be familiar
-with the [plugin development basics](/docs/plugins/development-basics.html).
-
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
-  advanced topic that only experienced Vagrant users who are reasonably
-  comfortable with Ruby should approach.
-</div>
-
-## Example Plugin
-
-The best way to describe packaging and distribution is to look at
-how another plugin does it. The best example plugin available for this
-is [vagrant-aws](https://github.com/mitchellh/vagrant-aws).
-
-By using [Bundler](http://bundler.io) and Rake, building a new
-vagrant-aws package is easy. By simply calling `rake package`, a
-`gem` file is dropped into the directory. By calling `rake release`,
-the gem is built and it is uploaded to the central [RubyGems](https://rubygems.org)
-repository so that it can be installed using `vagrant plugin install`.
-
-Your plugin can and should be this easy, too, since you basically
-get this for free by using Bundler.
-
-## Setting Up Your Project
-
-To setup your project, run `bundle gem vagrant-my-plugin`. This will create a
-`vagrant-my-plugin` directory that has the initial layout to be a RubyGem.
-
-You should modify the `vagrant-my-plugin.gemspec` file to add any
-dependencies and change any metadata. View the [vagrant-aws.gemspec](https://github.com/mitchellh/vagrant-aws/blob/master/vagrant-aws.gemspec)
-for a good example.
-
-<div class="alert alert-warning">
-  <p>
-    <strong>Do not depend on Vagrant</strong> for your gem. Vagrant
-    is no longer distributed as a gem, and you can assume that it will
-    always be available when your plugin is installed.
-  </p>
-</div>
-
-Once the directory structure for a RubyGem is setup, you will want
-to modify your Gemfile. Here is the basic structure of a Gemfile for
-Vagrant plugin development:
-
-```ruby
-source "https://rubygems.org"
-
-group :development do
-  gem "vagrant", git: "https://github.com/hashicorp/vagrant.git"
-end
-
-group :plugins do
-  gem "my-vagrant-plugin", path: "."
-end
-```
-
-This Gemfile gets "vagrant" for development. This allows you to
-`bundle exec vagrant` to run Vagrant with your plugin already loaded,
-so that you can test it manually that way.
-
-The only thing about this Gemfile that may stand out as odd is the
-"plugins" group and putting your plugin in that group. Because
-`vagrant plugin` commands do not work in development, this is how
-you "install" your plugin into Vagrant. Vagrant will automatically
-load any gems listed in the "plugins" group. Note that this also
-allows you to add multiple plugins to Vagrant for development, if
-your plugin works with another plugin.
-
-Next, create a `Rakefile` that has at the very least, the following
-contents:
-
-```ruby
-require "rubygems"
-require "bundler/setup"
-Bundler::GemHelper.install_tasks
-```
-
-If you run `rake -T` now, which lists all the available rake tasks,
-you should see that you have the `package` and `release` tasks. You
-can now develop your plugin and build it!
-
-You can view the [vagrant-aws Rakefile](https://github.com/mitchellh/vagrant-aws/blob/master/Rakefile)
-for a more comprehensive example that includes testing.
-
-## Testing Your Plugin
-
-To manually test your plugin during development, use
-`bundle exec vagrant` to execute Vagrant with your plugin loaded
-(thanks to the Gemfile setup we did earlier).
-
-For automated testing, the
-[vagrant-spec](https://github.com/hashicorp/vagrant-spec)
-project provides helpers for both unit and acceptance testing
-plugins. See the giant README for that project for a detailed
-description of how to integrate vagrant-spec into your project.
-Vagrant itself (and all of its core plugins) use vagrant-spec
-for automated testing.