Commit 30501967 authored by Mitchell Hashimoto's avatar Mitchell Hashimoto

website: update website to point to proper directory

parent 25868e1a
......@@ -13,7 +13,7 @@ import (
)
func configFile() (string, error) {
dir, err := configDir()
dir, err := homeDir()
if err != nil {
return "", err
}
......@@ -22,6 +22,15 @@ func configFile() (string, error) {
}
func configDir() (string, error) {
dir, err := homeDir()
if err != nil {
return "", err
}
return filepath.Join(dir, ".packer.d"), nil
}
func homeDir() (string, error) {
// First prefer the HOME environmental variable
if home := os.Getenv("HOME"); home != "" {
log.Printf("Detected home directory from env var: %s", home)
......
......@@ -16,7 +16,7 @@ var (
const CSIDL_APPDATA = 26
func configFile() (string, error) {
dir, err := configDir()
dir, err := homeDir()
if err != nil {
return "", err
}
......@@ -25,6 +25,15 @@ func configFile() (string, error) {
}
func configDir() (string, error) {
dir, err := homeDir()
if err != nil {
return "", err
}
return filepath.Join(dir, "packer.d"), nil
}
func homeDir() (string, error) {
b := make([]uint16, syscall.MAX_PATH)
// See: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx
......
......@@ -36,43 +36,31 @@ applications running.
## Installing Plugins
Plugins are installed by modifying the [core Packer configuration](/docs/other/core-configuration.html). Within
the core configuration, each component has a key/value mapping of the
plugin name to the actual plugin binary.
For example, if we're adding a new builder for CustomCloud, the core
Packer configuration may look like this:
<pre class="prettyprint">
{
"builders": {
"custom-cloud": "packer-builder-custom-cloud"
}
}
</pre>
In this case, the "custom-cloud" type is the type that is actually used for the value
of the "type" configuration key for the builder definition.
The value, "packer-builder-custom-cloud", is the path to the plugin binary.
It can be an absolute or relative path. If it is not an absolute path, then
the binary is searched for on the PATH. In the example above, Packer will
search for `packer-builder-custom-cloud` on the PATH.
After adding the plugin to the core Packer configuration, it is immediately
available on the next run of Packer. To uninstall a plugin, just remove it
from the core Packer configuration.
In addition to builders, other types of plugins can be installed. The full
list is below:
* `builders` - A key/value pair of builder type to the builder plugin
application.
* `commands` - A key/value pair of the command name to the command plugin
application. The command name is what is executed on the command line, like
`packer COMMAND`.
* `provisioners` - A key/value pair of the provisioner type to the
provisioner plugin application. The provisioner type is the value of the
"type" configuration used within templates.
The easiest way to install a plugin is to name it correctly, then place
it in the proper directory. To name a plugin correctly, make sure the
binary is named `packer-TYPE-NAME`. For example, `packer-builder-amazon-ebs`
for a "builder" type plugin named "amazon-ebs". Valid types for plugins
are down this page more.
Once the plugin is named properly, Packer automatically discovers plugins
in the following directories in the given order. If a conflicting plugin is
found later, it will take precedence over one found earlier.
1. The directory where `packer` is, or the executable directory.
2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d` on
Windows.
3. The current working directory.
The valid types for plugins are:
* `builder` - Plugins responsible for building images for a specific platform.
* `command` - A CLI sub-command for `packer`.
* `post-processor` - A post-processor responsible for taking an artifact
from a builder and turning it into something else.
* `provisioner` - A provisioner to install software on images created by
a builder.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment