-
Notifications
You must be signed in to change notification settings - Fork 905
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Chocolatey to Install an already extracted .nupkg #903
Comments
Right now this is a limitation of the NuGet framework more than it is Chocolatey. Chocolatey can point to a nuspec for install, but it will compile it into a nupkg and then install it. This is probably a different flow than what you want to do from what I am gathering. |
I think that would be ok, right @DarwinJS? You would end up with a duplicate in terms of extracted nuget packages, one in the Octopus working folder, and another in the programdata folder for Chocolatey, but the end result would be the same. |
So the compile happens in the background? I think that would work. As a side point this app has 18000 asp files and nuget pack is our biggest hitter in CI - so the compress, decompress and extra .nupkg are all overhead. However, at least in this case this is happening on the end node, not in CI. It will directly impact the speed to deploy in production. I think if there is a "Roadmap for using choco in CI" - this might be a nice thing to add to it. |
Depending on how things end up with the install process after NuGet is upgraded (#508), this may be possible to do. It would be a separate code path that just copied the files to the install directory, and then continued on with the rest of the installation. |
Given that support for installing from a |
I'm going to go ahead and close this, but we can reopen it if necessary. |
My use case:
Background: below I am discussing the use of standard .nupkgs by deployment orchestration / automation systems (e.g. Octopus) - these types of packages use .nupkg as a way to deploy in-house assemblies to many end-points in a scaled .NET installation. We are starting to use chocolatey for this to reduce our dependence on given deployment orchestration / automation systems.
Octopus (and other .NET code deployment orchestrationsolutions) create dynamic transforms for NuGet packages from the data held within their database. For instance, octopus parameters can vary by the "environments" you setup within it.
WIth a regular .nupkg Octopus decompresses the package to a temporary location and applies transforms it creates from data in it's database (IMPORTANT: the transforms are not static files and cannot be), it then moves the files to a final location (final location can be customized).
A simple way to have my cake (allow octopus to accomplish these transforms) and eat it too (have chocolatey do the final install) would seem to be to allow chocolatey to install from a package source that is already decompressed.
This way Octopus could handle my choco package as a standard .nupkg and apply transforms and drop the final result in a known custom location. Then, in a custom post-deploy step, I could tell chocolatey to install from the transformed custom location.
I would guess this approach would also open up the possibility of better integration with other deployment orchestration systems that dynamically insert their customizations into the "normal nupkg deployment stream" without further effort and without building specific chocolatey adapters or plug-ins for each target orchestration system.
The text was updated successfully, but these errors were encountered: