Improve user experience for using third-party plugins

[SwampDragons]

Active work has begun on building a Packer init command. Please see the latest comment #8610 (comment) for more details

This will probably look like a packer init command paired with a builder registry. We're going to be looking to Terraform for lessons.

This issue is being opened in response to the following PRs which attempted to add builders which we are afraid we're currently stretched too thin to officially support:

packer-builder-vultr #8075
packer-builder-nutanix #8175
packer-builder-zstack #8152

I would like to make sure these builders get included in the future registry.

[nywilken]

Hello Packerista

In version v1.6.6 of Packer the core maintainers started work on Scaffolding to split up Packer plugins from Packer core in preparation for an improved plugin experience via a new packer init workflow.

Since this release we have created a Packer Plugin SDK to be used for future development. All existing plugins within the Packer repository have already been updated to use the plugin SDK, but they still currently reside under one repository.

After the v1.7.0 release which introduces the framework for Packer init, the Packer Plugin SDK, and a Packer-Plugin-Scaffolding development template, Packer plugins will be split into their own respective repositories so that each plugin can be maintained and released independently of Packer core.

Why the change?

The Packer core (the part that actually runs Packer plugins like builders, provisioners, post-processors, etc) changes less frequently than individual plugins themselves. Splitting the core from the plugins will empower maintainers to release plugin updates without being constrained by the packer core releases. In addition to the decoupling of plugins, we also want to lower the barrier of entry to get started with a new plugin (both from a development and usage perspective).

What does change for me?

Please note that the details below are subject to change as v1.7.0 is still in progress and may change by the time it is released. But if you are interested in moving forward please reach out as we are interested in your feedback.

Plugin Developers

If you are a plugin developer for Packer working on a new custom plugin you should refer to the Packer v1.7.0 Developing Plugins Documentation. If you have questions or find that you need help please feel free to reach out to packer@hashicorp.com.

⚠️ First time plugin developers may want to hold off until v1.7.0 is released so that you have the most up to date plugin SDK and development guides.

If you are a plugin developer of a plugin that is already in use you are encouraged to start taking a look at the Packer v1.7.0 Plugin Upgrade Guide.

Packer Users

If you are a user of an existing third party plugin, know that if you upgrade your installed version of Packer to v1.7.0+ you will be asked to also upgrade to a compatible version of the third party plugin. You will either be able to install it the same way you always have (i.e Installing Plugins), or if you plugin supports it you can use the new packer init command, once released, to enable automatic installation from a compatible release on GitHub.

[sylviamoss]

#10304 it's merged to the master. The PR adds required_plugins + packer init and will be released in v1.7.0.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.