Allow for multiple "package instances"

[dragon788]

What You Are Seeing?

I can only install one "copy" of a package at a time, even if it is a zip package that would support modifying the configuration and installing multiple copies.

What is Expected?

I would like to have Chocolatey allow me to install the package with various different arguments (config settings) and have some way of displaying the different "configs" I have installed, even if this requires a new flag like -mpi or something.

Discussion

UPDATE: As Chocolatey Gitter chat is now unavailable, I've added a screenshot of the Gitter chat.

Feature Request

Add the ability to provide multiple package instances, with a "required" flag/parameter that specifies the string that will be used to identify the different versions after they are installed.

For example: choco list -l MyPackage

After allowing multiple instances: MyPackage MyPackage CustomInstall MyPackage NotVanilla

The additional ones would be installed via `choco install --multipackageinstances -params '"ConfigName=CustomInstall OtherArgs=etc"'.

[ferventcoder]

Thanks for adding this. This is likely further out on the roadmap due to other dependencies.

[Zyther]

+1 on this feature.

I have an idea as to how I'd develop one of two workarounds for this:

1. have your nuget-server accept a prefixed name to install choco install appname.environment Your nuget server returns appname@latest, and doesnt look for appname.environment as an actual app

2. A choco package that is just an installer Installs a locally built choco package, with appname.environment

[rismoney]

Any chance for this to get some attention? Not sure if the 5 year backlog gets love... :)

I think there are a lot of good use cases around this idea. The scenario I have is that the zip file contains windows files that run as windows services need to be installed (unzipped) into numbered instances directories.

The usage scenario would be: choco install mypackage-instance1 choco install mypackage-instance2 choco install mypackage-instance3 and go into directories: C:\mypackage-instance1,C:\mypackage-instance2,C:\mypackage-instance3

I would like to cup mypackage-instance2 and leave 1,3 current Then maybe cuninst 3. etc.

Oh and hello old buddy :)

[IljaAndrejevic]

+1 on this feature.

Have a similar requirement to solve some testing tasks. Is there any chance to get this? Or did somebody found a good workaround?

[vexx32]

Just to confirm, the --allow-multiple doesn't enable this functionality? I've not tried it with multiple instances of the same version, but it might do what you need here?

[rismoney]

@vexx32 : I think it works only works with unique versions.

An example use case- Team City agent (and many other apps) support running multiple agent services on a node. But they must be installed to discrete directories (a limitation on how windows manages services)

This is of course an edge case for most packages out there, and it's generally an antipattern to allow a host to have 2 of the same packages. But in a well formed package, supporting the OP goals are a valid and highly useful pattern (both in open source and private packaging needs). It is silly to create multiple packages/use version numbers to support this. Allowing the ability to uninstall an 'instance' or upgrading one is key to making the lifecycle complete.

Currently the only solution to this, are deploying a single reference package, and then copying it to multiple directories (that are then outside the package scope)

[vexx32]

Fair enough, appreciate the clarification!

There's a sort of open question here that would arise if we built this support in -- what happens with choco upgrade? Are all instances of that package upgraded? How would we target specific instances of the package for upgrade/uninstall?

What would a good UX look like for that, from your perspective? I'm not sure I agree with the original suggestion in the issue post where it becomes part of the package parameters, that feels too likely to clobber the package's own parameters. After all, Chocolatey itself needs to be aware of the additional package instances, so I think that more or less rules out passing this info in package parameters.

[rismoney]

not sure...maybe... From a UX I would think if a multi instance package was specified at install time, it would somehow inform choco that it's not a singleton. Then a choco upgrade for these would require specifying an instance, or a --all to upgrade all instances.

Not sure if a helper file could be used in lib, or an element used in nuspec.

[vexx32]

Hmm, fair enough. My thoughts were going along somewhat similar lines, I was wondering if we can simply reuse the --allow-multiple switch we have, or whether since we're going to be requiring an additional parameter anyway, we can simply treat --allow-multiple as sort of implied? Something like this:

choco install packagename -y --instance first
choco install packagename -y --instance second

And then we can have --instance as a parameter for upgrade/uninstall/pin as well. There's also the question of whether packages would need to explicitly declare support for this -- like you said, in the nuspec somehow, perhaps. Or maybe we assume that any package labelled .portable should be compatible, or a combination of the two.

If we have something like this, I think it would effectively render --allow-multiple a bit obsolete, because it would allow for more fine-grained control over which packages you're installing/uninstalling/upgrading/etc. I think ultimately that's a good thing, users have more control, and --allow-multiple tends to run into similar issues that we're talking about anyway, so this would be a fairly elegant solution to those problems.

[IljaAndrejevic]

Just to confirm, the --allow-multiple doesn't enable this functionality? I've not tried it with multiple instances of the same version, but it might do what you need here?

I checked the --allow-multiple option. Unfortunately it doesn't solve my requirements. In my case I would like to install the same version of the application several times, as also requested by the people before me. Of course I could create different packages, but this is kind of inconvenient.

In my use case the suggested --instance option would do the best job. If there is a chance to bring this into Chocolatey I would highly appreciate it.

[rismoney]

what do we need to do to get this out of the perma backlog? For the last number of years, I have been working around this through config management tooling, to install the package in 1 temp location, and then having the tool make n number of copies, but it is super kludgy to maintain.

[pauby]

@rismoney This isn't something that we are currently looking at and isn't on the roadmap in the near future.

[andrew-sumner]

Hit this as well, in my case I'm attempting to install multiple Azure Devops agents on the same server. Looks like I'm going to have to abandon chocolatey and use the raw installer to achieve this :-(

[andrew-sumner]

My work around is to delete 'C:\ProgramData\chocolatey\lib\azure-pipelines-agent.{{ az_devops_agent_version }}' on target server before deploying next package. Dirty but works.

[rismoney]

very dirty... :(

I hope @pauby reconsiders adding this to the roadmap, given how helpful this would be to many use cases and how long this hasn't been addressed. I can't imagine it being super complicated to retrofit instances into the package handlers routines.