Request: Vault Extension Module Path Should be VaultName.SecretManagementExtension about secretmanagement HOT 8 CLOSED

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.92. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

from secretmanagement.

Changing the required extension vault name would be a breaking change, and all vault authors would have to update their vault modules, and I would prefer not to allow alternative naming conventions as it seems unnecessary. The current naming convention is enough to disambiguate different extension vault modules, and calls to extension vault functions. So I am marking this as 'wont' fix' for now.

from secretmanagement.

Thanks @JustinGrote do you know of any other module patterns that use .Extension?
We like the idea of having the submodule name in the PSData but arent sure if it is worth making the breaking change for...would love more input from the community on this one--thanks!

from secretmanagement.

@SydneyhSmith not currently so it's not a breaking change but it doesn't hurt to be explicit. The PSData can be an optional addition and SecretManagement can look both places so it wouldn't be breaking to add it.

from secretmanagement.

@PaulHigin @SydneyhSmith @joeyaiello @SteveL-MSFT my only thought is that there may need to be a wider standard/recommendation on this. For instance, there are now going to be PSReadline intellisense extensions. What's that going to be? If I make a powershell module and I want to implement all of this, am I going to have a bunch of seemingly arbitrary folders in my source to implement them or are they going to have a nice nomenclature, e.g. MyModule.SecretManagementExtension and MyModule.PSReadlineExtension?

from secretmanagement.

I think moving forward the extension directory name can be defined in the parent module manifest, private data field (as suggested by @SteveL-MSFT). Any new extension module can use that and avoid the current SecretManagment hard coded naming convention. In fact, SecretManagement can move to this model at any time and still be backward compatible to the hard coded naming.

But at this time, I don't see any problem with the current naming scheme for SecretManagement.

from secretmanagement.

private data field (as suggested by @SteveL-MSFT)

My original issue above:

😕

from secretmanagement.

Sorry, I forgot you suggested it! But I agree that is a better way to define the extension name.

from secretmanagement.