How to get packer to use "dev" version of plugin

[deepankarsharma]

The GNUmakefile supplied with this project helpfully provides a dev target that builds the plugin and copies it to ~/.packer.d/plugins. However I am currently unable to get packer to use that generated version.

Here is what "packer-plugin-lxdapi describe" returns for me
{"version":"0.0.4-dev","sdk_version":"0.3.1","api_version":"x5.0","builders":["builder"],"post_processors":[],"provisioners":[],"datasources":[]}

Here is the output from packer when I try to use my plugin. You can see that it finds the plugin under "/home/dman/.packer.d/plugins/packer-plugin-lxdapi". However I cant seem to find a packer invocation / version specification where I could coax packer into using this locally built packer plugin over the ones that are uploaded from github.

Could you please clarify what the local development workflow for plugins should look like?

2023/02/20 04:05:38 [INFO] Packer version: 1.8.5 [go1.18.9 linux amd64] 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [TRACE] discovering plugins in /usr/bin 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [TRACE] discovering plugins in /home/dman/.packer.d/plugins 2023/02/20 04:05:38 [DEBUG] Discovered plugin: lxdapi = /home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.2_x5.0_linux_amd64 2023/02/20 04:05:38 [DEBUG] Discovered plugin: lxdapi = /home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.4_x5.0_linux_amd64 2023/02/20 04:05:38 [INFO] found external [builder] builders from lxdapi plugin 2023/02/20 04:05:38 [DEBUG] Discovered plugin: lxdapi = /home/dman/.packer.d/plugins/packer-plugin-lxdapi 2023/02/20 04:05:38 [INFO] found external [builder] builders from lxdapi plugin 2023/02/20 04:05:38 [TRACE] discovering plugins in . 2023/02/20 04:05:38 [INFO] PACKER_CONFIG env var not set; checking the default config file path 2023/02/20 04:05:38 [INFO] PACKER_CONFIG env var set; attempting to open config file: /home/dman/.packerconfig 2023/02/20 04:05:38 [WARN] Config file doesn't exist: /home/dman/.packerconfig 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [INFO] Setting cache directory: /home/dman/.cache/packer 2023/02/20 04:05:38 Old default config directory found: /home/dman/.packer.d 2023/02/20 04:05:38 [TRACE] listing potential installations for "github.com/deepankarsharma/lxdapi" that match "0.0.4-dev". plugingetter.ListInstallationsOptions{FromFolders:[]string{"/usr/bin/packer", ".", "/home/dman/.packer.d/plugins"}, BinaryInstallationOptions:plugingetter.BinaryInstallationOptions{APIVersionMajor:"5", APIVersionMinor:"0", OS:"linux", ARCH:"amd64", Ext:"", Checksummers:[]plugingetter.Checksummer{plugingetter.Checksummer{Type:"sha256", Hash:(*sha256.digest)(0xc0001fab80)}}}} 2023/02/20 04:05:38 [TRACE] version "v0.0.2" of file "/home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.2_x5.0_linux_amd64" does not match constraint "0.0.4-dev" 2023/02/20 04:05:38 [TRACE] version "v0.0.4" of file "/home/dman/.packer.d/plugins/github.com/deepankarsharma/lxdapi/packer-plugin-lxdapi_v0.0.4_x5.0_linux_amd64" does not match constraint "0.0.4-dev"

[deepankarsharma]

Commenting the "packer" block in the example causes the development plugin to be loaded. I am unblocked now, but leaving ticket open in case you want to use this to update the documentation.

[nywilken]

Glad you were able to unblock yourself @deepankarsharma. This is a know limitation of using the required_plugins block with dev binaries, and one we need to document. I'll keep this open for visibility and close once we update our plugin developer documentation. Cheers.

[sudomateo]

I'm working on an Oxide Packer plugin and I came to this repository to report this same issue when I stumbled upon this existing issue.

The suggestion to comment the packer block does not work for me.

> packer version
Packer v1.12.0

> packer init template.pkr.hcl

No plugins requirement found, make sure you reference a Packer config
containing a packer.required_plugins block. See
https://www.packer.io/docs/templates/hcl_templates/blocks/packer
for more info.

Here's my template.pkr.hcl.

# packer {
#   required_plugins {
#     oxide = {
#       version = ">= v0.0.1"
#       source  = "github.com/oxidecomputer/oxide"
#     }
#   }
# }

source "oxide-instance" "example" {}

build {
  sources = [
    "source.oxide-instance.example",
  ]
}

As it stands, the code in this scaffolding repository does not set up an optimal development flow since it builds a pre-release binary (i.e., v0.0.1-dev) that packer init is unable to use.

> PACKER_LOG=TRACE packer init template.pkr.hcl
2025/05/13 22:21:56 [INFO] Packer version: 1.12.0 [go1.22.9 linux amd64]
...
2025/05/13 22:21:56 ignoring pre-release plugin "/home/sudomateo/.config/packer/plugins/github.com/oxidecomputer/oxide/packer-plugin-oxide_v0.0.1-dev_x5.0_linux_amd64"
2025/05/13 22:21:56 [TRACE] getting available versions for the github.com/oxidecomputer/oxide plugin
2025/05/13 22:21:56 [DEBUG] github-getter: getting "https://api.github.com/repos/oxidecomputer/packer-plugin-oxide/git/matching-refs/tags"
...
Failed getting the "github.com/oxidecomputer/oxide" plugin:
        * GET https://api.github.com/repos/oxidecomputer/packer-plugin-oxide/git/matching-refs/tags: 404 Not Found []

1 error occurred:
        * GET https://api.github.com/repos/oxidecomputer/packer-plugin-oxide/git/matching-refs/tags: 404 Not Found []

Note the ignoring pre-release plugin log line which comes from packer/plugin-getter/plugins.go.

if ver.Prerelease() != "" && opts.ReleasesOnly {
    log.Printf("ignoring pre-release plugin %q", path)
    continue
}

This logic, coupled with the following logic in command/init.go means that packer init always ignores pre-release binaries.

opts := plugingetter.ListInstallationsOptions{
    PluginDirectory: c.Meta.CoreConfig.Components.PluginConfig.PluginDirectory,
    BinaryInstallationOptions: plugingetter.BinaryInstallationOptions{
        OS:              runtime.GOOS,
        ARCH:            runtime.GOARCH,
        APIVersionMajor: pluginsdk.APIVersionMajor,
        APIVersionMinor: pluginsdk.APIVersionMinor,
        Checksummers: []plugingetter.Checksummer{
            {Type: "sha256", Hash: sha256.New()},
        },
        ReleasesOnly: true,
    },
}

There are a few ways to solve this issue.

1. Update the development flow to build a release binary instead of a pre-release binary. This works and is quite easy to do but it encourages bad development practices.
2. Update packer init and possibly other subcommands with a new configuration option to set the value for ReleaseOnly. That way, users can run packer init --release-only false or similar to successfully install the pre-release binary.

[sudomateo]

The wonderful @nywilken linked me to the Predictable plugin loading in Packer 1.11 blog post that describes that Packer v1.11 and later should be treating -dev binaries specially so that the development binary is used when no other newer binary that matches the version constraint is present.

Even with this new knowledge, the packer init command continues to fail as mentioned previously. However, I noticed that packer validate and packer build successfully use the development binary so I am unblocked. Thank you for that.

Now that I'm looking at this with fresh eyes, perhaps the packer init command is meant to fail in this way since its responsibility is to install missing plugins and the development binary was already installed via packer plugins install, making packer init irrelevant. If that's the case I would recommend updating documentation to inform developers of this development flow since it's an unusual break from the normal init then build or apply that developers may be used to from Packer or Terraform.

Regardless, I'm unblocked. Here are the steps I used to troubleshoot this. The describe subcommand on the plugin binary was extremely helpful. I'm not sure if that's documented anywhere but the first I've heard of it was from the aforementioned blog post.

> go build -ldflags="-X 'main.VersionPreRelease=dev'" -o packer-plugin-oxide

> ./packer-plugin-oxide describe | jq
{
  "version": "0.0.1-dev",
  "sdk_version": "0.6.1",
  "api_version": "x5.0",
  "builders": [
    "instance"
  ],
  "post_processors": [],
  "provisioners": [],
  "datasources": [
    "image"
  ],
  "protocol_version": "v2"
}

> packer plugins install --path packer-plugin-oxide "github.com/oxidecomputer/oxide"
Successfully installed plugin github.com/oxidecomputer/oxide from /home/sudomateo/oxide/packer-plugin-oxide/packer-plugin-oxide to /home/sudomateo/.config/packer/plugins/github.com/oxidecomputer/oxide/packer-plugin-oxide_v0.0.1-dev_x5.0_linux_amd64

> ls -l ~/.config/packer/plugins/github.com/oxidecomputer/oxide/
total 38092
-rwxr-xr-x. 1 sudomateo sudomateo 38998136 May 14 14:56 packer-plugin-oxide_v0.0.1-dev_x5.0_linux_amd64*
-rw-r--r--. 1 sudomateo sudomateo       64 May 14 14:56 packer-plugin-oxide_v0.0.1-dev_x5.0_linux_amd64_SHA256SUM


> head -n 8 template.pkr.hcl
packer {
  required_plugins {
    oxide = {
      version = ">= v0.0.1"
      source  = "github.com/oxidecomputer/oxide"
    }
  }
}

> packer init template.pkr.hcl
Failed getting the "github.com/oxidecomputer/oxide" plugin:
1 error occurred:
        * GET https://api.github.com/repos/oxidecomputer/packer-plugin-oxide/git/matching-refs/tags: 404 Not Found []

> packer build template.pkr.hcl
oxide-instance.example: output will be in this color.

==> oxide-instance.example: Creating Oxide instance!
==> oxide-instance.example: Viewing Oxide instance!
==> oxide-instance.example: Using SSH communicator to connect: 172.21.252.115
==> oxide-instance.example: Waiting for SSH to become available...