Add bootcommand mappings for left/right command and option keys

[torarnv]

Awaiting the merge of the feature in the upstream Packer SDK repo, let's override the plugin SDK with a branch that has the feature.

See hashicorp/packer-plugin-sdk#293

[edigaryev]

While I love the initial hashicorp/packer-plugin-sdk#293 because it improves DX, I don't think it's so critical at this point that we need to start depending on a fork, since one can easily work around this by using <leftSuper> and <leftAlt>.

I also have an outstanding hashicorp/packer-plugin-sdk#226, and I really hope that Packer Plugin SDK team would actually start accepting something beyond just trivial bug fixes.

@fkorotkov do you think a Cirrus Labs fork of github.com/hashicorp/packer-plugin-sdk is something that could be a middle ground here?

[torarnv]

A Cirrus Labs fork would be preferable than my repo, absolutely. I'm fine with that, as long as we can move this ahead somehow :)

I don't think it's so critical at this point that we need to start depending on a fork, since one can easily work around this by using and .

Note that left/right Option key is unmapped for the VNC driver: https://github.com/hashicorp/packer-plugin-sdk/pull/293/changes#diff-be5440cc45297db781dfd9b093cd7525f71d9e0b498f74002cba7f44c4f7bb50R84

Neither Super or Alt cover that.

[edigaryev]

Interesting, it turns out that we never needed the ⌥ in our Packer templates.

What do you need it for?

As for ⌘, it can be substituted with the <leftAltOn> and <rightAltOn> at the moment.

[torarnv]

Interesting, it turns out that we never needed the ⌥ in our Packer templates.

What do you need it for?

I use it here

  # The initially selected language at the top of the list depends on the locale/region
  # settings of the host the virtual machine was created in. If we're in a region where
  # English is the already selected entry, we can't type "English" to move to it, as that
  # will move us to the next entry in the list, ie. "English (UK)". To account for this
  # we first move to the bottom, before moving (back) to "English".
  - <wait 'English'>
  - <leftOptionOn><down><leftOptionOff>
  - english
  - <enter>

There are of course other ways to solve that particular case, but I think it makes sense for Tart's packer plugin to have a complete set of modifier key instructions :)

@fkorotkov do you think a Cirrus Labs fork of github.com/hashicorp/packer-plugin-sdk is something that could be a middle ground here?

Could we proceed with this approach? That would work well for me :)

[edigaryev]

I think it makes sense for Tart's packer plugin to have a complete set of modifier key instructions :)

What do you think about an approach similar to this:

packer-plugin-tart/builder/tart/step_run.go

Lines 261 to 267 in 0316fa6

	stringWaitRegex := regexp.MustCompile(`<wait\s*'(.+?)'>`)
	command = stringWaitRegex.ReplaceAllString(command,
	fmt.Sprintf(`%c${1}%c`, WaitForStringStart, WaitForStringEnd))
	stringClickRegex := regexp.MustCompile(`<click\s*'(.+?)'>`)
	command = stringClickRegex.ReplaceAllString(command,
	fmt.Sprintf(`%c${1}%c`, ClickStringStart, ClickStringEnd))

This way we can support custom keys while avoiding the burden of maintaining a fork.

Once Packer maintainers merge your PR, we can remove these replacements on our side.

[torarnv]

Maintaining a duplicated and separate implementation of the same feature sounds like more work/burden than maintaining a fork for a repo that doesn't update all that often, where the change is applied 1:1 with what's in the upstream PR.

[torarnv]

I also have an outstanding hashicorp/packer-plugin-sdk#226, and I really hope that Packer Plugin SDK team would actually start accepting something beyond just trivial bug fixes.

Nor does it help with your issue here.

[edigaryev]

Maintaining a duplicated and separate implementation of the same feature sounds like more work/burden than maintaining a fork for a repo that doesn't update all that often, where the change is applied 1:1 with what's in the upstream PR.

The problem is that the upstream still periodically updates, and this requires periodic manual interventions from us.

Whereas if this feature is properly implemented inside of this repository, there's literally zero maintenance.

Let's look at statistics: your PR (#178), which makes this plugin much lower-level than it needs to be (and probably for a good reason, because it simplifies the life of a lot of users) did not require any maintenance since it was merged almost a year ago, yet it's much more complicated than what I'm proposing here.

[torarnv]

Okey, let's do it like this

[torarnv]

Once these two are in, can we also cut a release so I can depend on the changes in my packer templates? Thanks!

[edigaryev]

Once these two are in, can we also cut a release so I can depend on the changes in my packer templates? Thanks!

As always! Here it is: https://github.com/cirruslabs/packer-plugin-tart/releases/tag/v1.18.0.