You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Porter has mixins which are similar to plugins or packages that are listed in the porter.yaml file. However, the specific version of the mixin to install can only be provided in the Porter command. As a developer who has experience working with npm, NuGet modules, I find this limitation to be problematic.
Describe the solution you'd like
It would be more efficient to track mixin versions in the yaml file, as it is done in files like package.json and csproj, especially when it comes to debugging and dealing with broken CI. When it is in the porter.yaml, you can be sure the right version of the mixin matches what you have tested: the package behaves the same all through the development and deployment lifecycle.
Describe alternatives you've considered
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Hey!
To add clarification for future me and the community: Right now Mixins allow for clientVersion which is the version of the tool we download in the mixin. Ex: In the Terraform Mixin if we set ClientVersion to 1.1.0, then we are downloading Terraform 1.1.0 - but this is not the version of the mixin itself
What is being proposed is to specify the mixin version, so for instance:
As discussed this would be a schema change. We will have to add a function that checks what mixins are installed and if the version we want is installed. We currently have this function which we may be able to dive into and extend
Is your feature request related to a problem? Please describe.
Porter has mixins which are similar to plugins or packages that are listed in the porter.yaml file. However, the specific version of the mixin to install can only be provided in the Porter command. As a developer who has experience working with npm, NuGet modules, I find this limitation to be problematic.
Describe the solution you'd like
It would be more efficient to track mixin versions in the yaml file, as it is done in files like package.json and csproj, especially when it comes to debugging and dealing with broken CI. When it is in the porter.yaml, you can be sure the right version of the mixin matches what you have tested: the package behaves the same all through the development and deployment lifecycle.
Describe alternatives you've considered
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: