Unity optional dependencies as packages in their own right

[petemounce]

I've seen that it's possible to install Unity optional dependencies via additional parameters when installing the unity package (eg /sa etc). This is great.

However, if I create a package that takes unity as a dependency, then because of chocolatey/choco#488 I cannot specify those additional parameters (let's say that my package wants unity with both linux and osx build support).

Therefore - would it be possible to get those optional dependencies as packages in their own right? Or, would you be open to a PR that generated a package for each of these dependencies, for you to then push when there are new versions? It looks like your update.ps1 could be adjusted to do that.

[jtcmedia]

My only concern is if this might break Chocolatey convention. The target support and other parameters aren't applications in their own right; simply extensions to Unity's functionality. An analogy is the VirtualBox Extension Pack for VirtualBox. In those cases, a separate package isn't made.
That being said, Unity does nicely wrap each of these in their own installers so this can be easily implemented. Another option would be to install all these extensions as default and change the parameters to negation (give a parameter to NOT have it installed). That should solve the Unity as a dependency problem. Out of curiosity, when would Unity be made a dependency? I can't think of any scenario that you describe. In any case, I will have to ask the Chocolatey moderators if making these extensions separate packages is allowed.

[petemounce]

I've asked the chocolatey team via gitter.

My use-case is that my company wants to create an installer package for their product, and their product can require Unity, with particular optional extras installed. The version of Unity depended on changes with our own product - ie, we might release a new version and only support x-y version of Unity. Installing via package manager drastically reduces the complexity of the initial user onboarding and ongoing maintenance.

[petemounce]

@jtcmedia According to the chocolatey team creating one package per optional extra would be fine. See conversation linked.

[dragon788]

If they aren't completely standalone it makes sense for the additional packages to depend on Unity. That is similar to how KeePass-keepasshttp plugin and the KeePass language files work.

https://chocolatey.org/packages/keepass-keepasshttp

[jtcmedia]

I believe @petemounce wants the option to install these additional packages as parameters to Unity in addition to the usual cist. Is there any issue with doing that @dragon788 ?

[petemounce]

No; I'd like to be able to list the unity extras as individual dependencies of my package, to avoid needing to use the --params.

See https://chocolatey.org/packages/spatial _> dependencies.json. I want to list the unity extras that I depend on as individual dependencies.

[petemounce]

I issued one PR per package in the thinking that that would be easier to review. I

• based each one on a copy of unity-metro
• adjusted the nuspec version to be 5.5.0 (so that the updater would find a new version)
• ran update.ps1

[jtcmedia]

Do you still need the 5.5.0 version of these? Otherwise I have to submit two versions for every package.

[petemounce]

I think probably not; thanks. I took a look at the auto updater and decided it wasn't worth it; we'll be supporting 5.5.1 soon enough.

[jtcmedia]

All the 5.5.1 packages have been submitted and approved so I am going to close this issue now.
Jason