website: update website to point to proper directory

config_unix.go

@@ -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)

config_windows.go

@@ -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

website/source/docs/extend/plugins.html.markdown

@@ -36,43 +36,31 @@ applications running.
 
 ## Installing Plugins
 
-Plugins are installed by modifying the [core Packer configuration](/docs/other/core-configuration.html). Within
+The easiest way to install a plugin is to name it correctly, then place
-the core configuration, each component has a key/value mapping of the
+it in the proper directory. To name a plugin correctly, make sure the
-plugin name to the actual plugin binary.
+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.
 
-For example, if we're adding a new builder for CustomCloud, the core
+Once the plugin is named properly, Packer automatically discovers plugins
-Packer configuration may look like this:
+in the following directories in the given order. If a conflicting plugin is
+found later, it will take precedence over one found earlier.
 
-<pre class="prettyprint">
+  1. The directory where `packer` is, or the executable directory.
-{
-  "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
+  2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d` on
-of the "type" configuration key for the builder definition.
+     Windows.
 
-The value, "packer-builder-custom-cloud", is the path to the plugin binary.
+  3. The current working directory.
-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
+The valid types for plugins are:
-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
+* `builder` - Plugins responsible for building images for a specific platform.
-list is below:
 
-* `builders` - A key/value pair of builder type to the builder plugin
+* `command` - A CLI sub-command for `packer`.
-  application.
 
-* `commands` - A key/value pair of the command name to the command plugin
+* `post-processor` - A post-processor responsible for taking an artifact
-  application. The command name is what is executed on the command line, like
+    from a builder and turning it into something else.
-  `packer COMMAND`.
 
-* `provisioners` - A key/value pair of the provisioner type to the
+* `provisioner` - A provisioner to install software on images created by
-  provisioner plugin application. The provisioner type is the value of the
+    a builder.
-  "type" configuration used within templates.