-
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
Ubiquitous Install Directory Switch #258
Comments
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 |
Do you mean chocolatey would take this into consideration in the second version? And Thanks very much for your quick reply. |
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. |
@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, It's sad, because many packages use a file layout highly compatible with chocolatey, e.g. Git, which installs to
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 |
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... |
@rismoney installing packages from self-contained archives and letting the package manager assemble binaries into 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
They would not; a simple 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, |
@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). |
That said, I think we will see more of a rise of the |
@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 |
@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 |
The specific feature requested in this issue would be cleaner than relying on random environment variables (I've seen at least |
Detect the file type based on PE and binary attributes using DIE, a great utility for determining packer identities.
* stable: (maint) remove unneeded imports (GH-258) FileTypeDetectorService
After testing with the c++ dll, it appears the DIE utility is only available as an x86, which makes it difficult to use without bringing in COM. As it is simpler to just use the executable it comes with instead, switch over to using that. Set it up with an ini file to configure it to find the detector database in the proper location as well.
* stable: (GH-460) Amended Template (GH-623) Extract Nuspec on Install (GH-674)(GH-672) Color Overrides / Fix Write-Host (GH-181) log selection to log file only (GH-181)(GH-184) Short prompt/Prompt character (GH-675) Template include LICENSE/VERIFICATION (GH-258) Rename zip to detector.zip (GH-572) Fix: The handle is invalid - Output Redirection (maint) comments (GH-667) Provide How To Add Profile Manually (GH-667) PowerShell Custom Host - Set $Profile (GH-666) pass Write-ChocolateyError message param (GH-673) Ensure Get-BinRoot Warning is Shown (GH-666) setup logs colored write-host w/fallback
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. |
@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 |
@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 |
@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 :) |
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. |
* stable: (chocolateyGH-501) allow shutting off sign when no network (chocolateyGH-448) Add Output Directory for choco new (maint) assume xml file is utf8 (maint) formatting (chocolateyGH-258) Switch for only using silent args provided (chocolateyGH-682) Add summary log file (chocolateyGH-644) Add info command (chocolateyGH-646) Add detail/detailed for search/list (maint) template share location should be appropriate (build) add a run.codesign switch
* stable: (log) Explain how to install licensed extension (chocolateyGH-712) Report required reboots (chocolateyGH-641) Allow more exit codes for install shield (chocolateyGH-715) Report loaded extensions to the user (chocolateyGH-258) Remove unnecessary configuration (chocolateyGH-641) Add BitRock / QT / Squirrel Installers
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. |
Certain package commands will honor the install directory override, but others will not. If those are used, Chocolatey should warn that the directory override will not work.
* stable: (GH-258) Warn when directory overrides won't be honored
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:
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.
The text was updated successfully, but these errors were encountered: