update plugin documentation
This commit is contained in:
parent
247119e1c3
commit
ccbd8b8abf
|
@ -17,9 +17,9 @@ writing plugins that are simply distributed with Packer. For example, all the
|
|||
builders, provisioners, and more that ship with Packer are implemented
|
||||
as Plugins that are simply hardcoded to load with Packer.
|
||||
|
||||
This page will cover how to install and use plugins. If you're interested in
|
||||
developing plugins, the documentation for that is available the [developing
|
||||
plugins](/docs/extending/plugins.html) page.
|
||||
This section will cover how to install and use plugins. If you're interested in
|
||||
developing plugins, the documentation for that is available below, in the [developing
|
||||
plugins](#developing-plugins) section.
|
||||
|
||||
Because Packer is so young, there is no official listing of available Packer
|
||||
plugins. Plugins are best found via Google. Typically, searching "packer plugin
|
||||
|
@ -32,11 +32,11 @@ Packer plugins are completely separate, standalone applications that the core of
|
|||
Packer starts and communicates with.
|
||||
|
||||
These plugin applications aren't meant to be run manually. Instead, Packer core
|
||||
executes these plugin applications in a certain way and communicates with them.
|
||||
For example, the VMware builder is actually a standalone binary named
|
||||
`packer-builder-vmware`. The next time you run a Packer build, look at your
|
||||
process list and you should see a handful of `packer-` prefixed applications
|
||||
running.
|
||||
executes them as a sub-process, run as a sub-command (`packer plugin`) and
|
||||
communicates with them. For example, the VMware builder is actually run as
|
||||
`packer plugin packer-builder-vmware`. The next time you run a Packer build,
|
||||
look at your process list and you should see a handful of `packer-` prefixed
|
||||
applications running.
|
||||
|
||||
## Installing Plugins
|
||||
|
||||
|
@ -153,12 +153,10 @@ using standard installation procedures.
|
|||
The specifics of how to implement each type of interface are covered in the
|
||||
relevant subsections available in the navigation to the left.
|
||||
|
||||
~> **Lock your dependencies!** Unfortunately, Go's dependency management
|
||||
story is fairly sad. There are various unofficial methods out there for locking
|
||||
dependencies, and using one of them is highly recommended since the Packer
|
||||
codebase will continue to improve, potentially breaking APIs along the way until
|
||||
there is a stable release. By locking your dependencies, your plugins will
|
||||
continue to work with the version of Packer you lock to.
|
||||
~> **Lock your dependencies!** Using `govendor` is highly recommended since
|
||||
the Packer codebase will continue to improve, potentially breaking APIs along
|
||||
the way until there is a stable release. By locking your dependencies, your
|
||||
plugins will continue to work with the version of Packer you lock to.
|
||||
|
||||
### Logging and Debugging
|
||||
|
||||
|
|
Loading…
Reference in New Issue