Ubiquitous Install Directory Switch

[iMingLei]

Is there a global option for overriding default install directory for all packages at installation phase?
At least, from GUI, almost all of software installers provide this possibility for users to change or setup the default installation directory. However, currently it is quite easy for users (at least for me) to "clutter up system partition with installed applications" (quote from your wiki page).

Even though I quite agree with Gary Ewan Park at supperuser as below:

This is a side effect of the Windows Eco-System, where there are multiple ways to do the same thing. Chocolatey is trying to bring some sort of order to this by providing a mechanism to at least find all the packages that you want in one place, but there is only so much Chocolatey can do.

leaving the right to package itself is not wrong. But if chocolatey could provide the global option for overriding the default install directory, this would be more convenient and flexible for end users.

[ferventcoder]

There is an existing ticket to track this, but it may not have been moved over yet. In short, it's a v2 kind of thing

[iMingLei]

Do you mean chocolatey would take this into consideration in the second version?

And Thanks very much for your quick reply.

[ferventcoder]

chocolatey-archive/chocolatey#32

[ferventcoder]

That's the original issue that still needs to be ported over. We've started the first steps of this. It may come earlier than v2 but it is a package opt-in thing as well.

[alexchandel]

@Tim-Lei There are any number of packages that openly flaunt the chocolatey way of doing things. It will take consistent, unrelenting pressure on the part of chocolatey users to persuade those developers to release packages that are compatible with self-contained, msi-free installation into C:\ProgramData\chocolatey\lib\, relying on chocolatey to create shims in C:\ProgramData\chocolatey\bin\.

It's sad, because many packages use a file layout highly compatible with chocolatey, e.g. Git, which installs to C:\Program Files (x86)\Git\:

Git Bash.vbs
ReleaseNotes.rtf
bin/
cmd/
doc/
etc/
lib/
libexec/
share/
ssl/
unins000.dat
unins000.exe

There's really no need for Git to care where it installs itself. With chocolatey it doesn't even need an installer, since a zipfile would meet its needs, and chocolatey would take care of the 3 necessary shims for cmd/. But that's the way the binaries are currently published.

[rismoney]

In an attempt to standardize 100 install methods a new standard is created. Now 101 methods exist.

Not sure I follow these ideas @alexchandel but it sounds like nuget.

The issue for me with self contained packages, is that they would need to be auto assembled from a version controlled manifest of sorts. Like a dockerfile...

[alexchandel]

@rismoney installing packages from self-contained archives and letting the package manager assemble binaries into /bin has been around since the 80's in unix. This isn't a new idea: it's as old as dirt. In fact, it's one of the first. This is also how package managers on every other system work. Modern package managers like Homebrew, Nix, and Butch literally extract packages to isolated directories, e.g. /opt/gcc/gcc-4.9.1-msp430/ and symlink them into /bin. And historically, even though other, less well-designed package managers like apt and pacman extracted packages directly into /bin/wherever, they still extracted self-contained package archives.

Moreover, even releasing zip archives for Windows binaries isn't remotely novel. So many people already do this that I don't even.

And this has the effect that only one folder in the PATH need contain any user-installed binaries, especially command-line binaries. Ever compare the PATH on a unix developer machine to one on a Windows dev machine? Windows' is obscenely long, but simply by installing archives, Chocolatey could prune dozens of entries off.

they would need to be auto assembled from a version controlled manifest of sorts. Like a dockerfile...

They would not; a simple .zip/.7z/.tar.gz archive suffices. Chocolatey already has the ability to create shims, and already does create shims for innumerable packages. For example, C:/ProgramData/chocolatey/bin/psc.exe, which links to C:/ProgramData/chocolatey/lib/purescript/tools/bin/psc.exe, is automatically created when the purescript package is installed simply because that binary exists.

Chocolatey is a package manager for Windows, a role nothing has ever filled (blame MS's stewardship of the OS). By necessity, something new is required. But this is the antithesis of a standard, the lack of any installation standard, be it InstallShield, msi, nuget, WinStore apps, or other. And unsurprisingly it yields simple, maintainable behavior. Everyone has enjoyed xkcd, but the analogy simply doesn't hold here.

[ferventcoder]

@alexchandel perhaps we should talk this out more. So the packages being self-contained archives is a great idea. I'm all for that. In fact quite a few packages already do this. But first I need to help you get your head around the word "developers". I am going change that to "software owners/maintainers". Now we have software owners, and we have package maintainers, who are not always the same people. In fact, the biggest percentage of packages out there are maintained by folks who really enjoy the software that someone else puts out and are providing a service for that software owner. This happens not just with Chocolatey, but across all package managers (go look at curl to understand what I mean).

For a second, let's consider where the installer / archives come from. Many times it comes from the software owner, who also owns the distribution rights. This means the package maintainer can't include the contents of the software in the package itself without permission from the software owner. That also means the package maintainers are not the ones in control of the contents, the software maintainers/owners are. Now consider there are over 50,000 applications for Windows out there (because there are, probably quite a bit more). Quite a few of those software owners will either need to start packaging with Chocolatey themselves, or allow distribution rights so a package maintainer can make the package self-contained.

Let's take a second to review human psychology. This is not meant to be negative, but to share a realistic assessment. Most folks don't use anything that is less than 3 years old in FOSS, because they are waiting to see if it will stick around. That's not everyone, but it usually goes for the folks maintaining a long term software project. Because there is risk involved and they may need to switch gears later. Because folks are generally slow to adopt new things. Because folks don't like change. Because they may need to release their software in a new way and folks may not be on board with that. "You want me to do additional work? What's the benefit? Why is it important?"

Understanding human psychology and folks seeing Chocolatey as still young and waiting to see if it sticks around and has lots of packages before jumping on board (if ever), you can start to see the chicken and the egg problem. So we have almost 3,000 packages now, we are barely scratching the surface of all the Windows software available. Chocolatey is not the first package manager for Windows, but it is the first that took a sensible approach to looking at the existing Windows ecosystem and understanding that you can't force everyone to change overnight. That flexibility is what has earned Chocolatey as much popularity as it currently has.

In the Windows ecosystem you've let on that there may be a stewardship issue, but also one that is over 20 years old. That means you are not going to change behavior overnight. Creating a standard comes after you get the late majority on board and we are just into the early majority phase now (maybe).

[ferventcoder]

That said, I think we will see more of a rise of the .portable packages and be able to switch the main packages from metapackages to virtuals based on configuration folks can select which they want.

[alexchandel]

@ferventcoder Absolutely. I never meant to suggest this could happen without software owners' support, or that it should happen immediately, or that they should be required to do so. I was merely responding to the notion that archive releases were some "new" standard, purportedly not to be pursued, when there are already quite a few popular packages that do this, as you mentioned.

But personally, I wouldn't shy away from asking software owners to release archives, if it involves little work for them. In terms of psychology, this early phase may be the best time to effect some upstream changes, before current methods become the "expected" means of installing those packages through chocolatey.

Take the Rust project, which is actually in the process of refactoring their Windows build system to drop exe installers altogether. They currently produce tarballs for Windows of all the separate components, and it wouldn't be a stretch to release a tarball or zip. (Although I believe they do release one for stable versions)

[ferventcoder]

@alexchandel the most interesting thing here is that most installers are just archives themselves. With the right tools we could remove the installation part of those. We already do it with webpi - https://chocolatey.org/packages/webpicmd#files

NSIS packages are simple archives. Once we have packages reporting what the installer type is, we can move forward more with making them installable by non-admins (and make them available for folks to install as portables), plus the option to prefer .portable packages.

[alexchandel]

The specific feature requested in this issue would be cleaner than relying on random environment variables (I've seen at least ChocolateyBinRoot and chocolatey_bin_root, but I suspect there are others).

[caleyg]

Where are we on this issue? Has this been pushed into master?

I would also like to be able to easily change package install locations. I'm wondering if this will be an issue in the end for our use case. Eventually we will be using NuGet to build out custom packages and pulling from our internal feed. So I suspect we will be able to define this location in the xml file for the pkg. However I haven't made it that far quite yet.

[ferventcoder]

@caleyg This is definitely going to be available as a preview in 0.9.10.

Package files (the actual Chocolatey package files) are not changeable. I'd like to understand your use case for wanting to change the location of those. You can change the entire Chocolatey install, but Chocolatey does not allow changing from $env:ChocolateyInstall\lib and likely won't in the near future.

[ferventcoder]

@caleyg you can change the install locations now provided you know the underlying installer you are using when building packages - and then passing the appropriate additional args during install as --installArgs - see https://github.com/chocolatey/choco/wiki/GettingStarted#overriding-default-install-directory-or-other-advanced-install-concepts

[caleyg]

@ferventcoder Thanks for the seriously prompt response!

I'm mostly interested in the custom location of packages installed /by/ choco, not the actual choco binary. I'm aware that an environment variable is needed to change the location of where choco finally ends up on the disks, if nothing is specified it goes in C:\ProgramData.

I'm also aware that currently we need to look at the installer mechanism ( the thing that does the silent installs for various .msi's and other installer apps) to see what switch is used to to change the default installdir of that app. I was under the impression this feature (issue-258) was to create a switch for that.

More to your point, my use case is this. We have plans on building in house packages, (think rpms but for windows) that will install various things, some small others bigger. A rough example would be a windows service that contains a jar and some things that need to be registered in the services.msc snapin. I've already have the install process built out with powershell, its just a matter of making that powershell pattern into a nupkg format, so that choco can ingest and deploy on the server.

I said that to say this, I'm banking on the theory that while creating that nupkg spec file (this is the xml file correct?) for the custom package I want to install, I should be able to specify an install destination there yes?

I apologize if this sounds a little noobish, I've been digesting the wealth of documentation here on this github project, in tandem while reading up NuGet and integrating it with our in house jFrog Artifactory Pro infra.

Thanks for any input you can provide here :)

[ferventcoder]

So packages, package files, software and native installers are some concepts you will find in the documentation. Pay attention to the bits where native installers install software to program files and the package files may just be the nuspec, automation scripts and embedded package binaries like the native installer.

[ferventcoder]

I said that to say this, I'm banking on the theory that while creating that nupkg spec file (this is the xml file correct?) for the custom package I want to install, I should be able to specify an install destination there yes?

Unfortunately this is not the the case. Nuspecs are metadata or information about the package and underlying software, they are not directives on how to install. There are some plans to determine whether to make the nuspec more of a directive and remove the necessity of the install/uninstall scripts (make them optional), but this isn't one we've discussed. It seems more akin to something you do with actual native installers.