Get-BinRoot should really be C:\ProgramData\chocolatey\bin by default.
Redsandro opened this issue · 16 comments
What was that command to get C:\ProgramData\chocolatey\bin? A lot of packages do it manually, and to get it, semantics and intuition suggest you would do Get-BinRoot to get it. However, Get-BinRoot points to the arbitrary C:\Tools by default.
When I originally made Get-BinRoot, it was when Chocolatey still installed in C:\chocolatey\ and binaries installed to C:\chocolatey\bin\ unless env:chocolatey_bin_root was set to an alternative binary root which was later renamed to env:chocolateyBinRoot which some packages ignored and others even had a hardcoded $binRoot. Get-BinRoot fixed all problems and phased out the deprecated environment variable.
See the original stub from #217 (comment):
if($env:chocolatey_bin_root -eq $null) {
$binRoot = "$env:ChocolateyInstall\bin"
}
However, there were some bugs and during fixes Get-BinRoot was set do default to C:\Tools. This is someone's preference, and in my opinion it is wrong. According to the packaging guidelines, personal preferences (including mine to use C:\Common\bin) are or should be irrelevant for packages, and I think that should apply to where they are installed by default too.
It makes sense to keep everything clean by default and use the chocolatey bin folder that is used to install shims anyway. It is already in the path.
If c:\tools is your personal favorite, you should manually edit the chocolateyBinRoot environmental variable. Otherwise, the default should be $env:ChocolateyInstall\bin.
Apart from that, we need to encourage packages to use Get-BinRoot instead of manually grabbing join-path %ProgramData% "bin" $PackageId.
Similarly, we should replace that 4 line code you see in many packages to create and use a temporary folder by a helper function.
That's the problem. Get-ToolsRoot is really the name of this. It's horrrrrribly named.
Is this in your comment referring to C:\ProgramData\chocolatey\bin or C:\Tools?
I am assuming the latter, but with the confusion and all, I'm not sure.
The problem is that the terminology of the command is so bad, you and many others have identified it as essentially the same location as c:\programdata\chocolatey\bin when in fact it represents something else entirely.
Can you try and explain it to me?
There is a concept of a place where you can install tools due to two reasons -
- current POSH choco putting version numbers on folders and
- folks want a place on the system out of the choco folders where they can put tools.
This is basically a location that a user can specify as ToolsRoot.
Now muddy that up and call it BinRoot instead.
Perhaps we should have a binRoot and a toolsRoot
Do we need a bin root? Or is it that choco is not doing a sufficient job in some cases?
Do we need a bin root? Or is it that choco is not doing a sufficient job in some cases?
With the changes that are coming in vNext, or at least, how I understand them, the need to Get-BinRoot should become non-existent, but that does raise the question about deprecating and updating the use of it.
Do we need a bin root? Or is it that choco is not doing a sufficient job in some cases?
I don't know. I prefer a non-shimmed binRoot for command line tools, and for everything else a subdirectory of chocolatey (like lib and bin already are). If anyone prefers something arbitrary like C:\Tools they should manually make it so.
With players and browsers and libraries - not just tools but plain software - installing to Get-BinRoot ATM AKA Tools, I think software or programs or bin is a more intuitive and canonical name. It makes sense to put this inside chocolatey unless manually changed to something that has personal preference.
the need to Get-BinRoot should become non-existent
What did I miss/forget?
I don't know. I prefer a non-shimmed binRoot for command line tools
This is what I'm curious about. Is it the older shims that were batch files? Is it performance? What hesitations do you have? Brutal honesty is fine here.
Brutal honesty, nitpicking, lack of knowledge and a touch of ocd combined:
I like to (re-)use my 'own' bin folder and be able to specify it as $binRoot for chocolatey. I like this bin directory to be copyable to USB sticks and between VMs. I like to pipe stuff between 'exe' files within batch files, being able to assume that the .exe files are in the same folders (relatively named). And I like, when some complicated piped script doesn't work, not to have to wonder if it's the shimming that causes a pipe to break.
@ferventcoder Could you please clarify what "tools" are in this context? Does this refer to tools used by the chocolatey install/uninstall process? If so, would it not make sense to install these to a /tools folder under whatever ChocolateyPath currently is?
On the other hand, if this refers to a location where the artifacts constituting the actual software are to be installed (which is what a lot of packages rightly or wrongly use it as), would it not make sense to return a location under /lib based on the package name?
Tools (or portables) in this context refers to the actual software that does not come with a native installer, which is like git for windows portable zip compared to git for windows install. If software is offered as an archive of some sort in addition to or instead of through an installer - that is what is meant by "tools." We actually have a pretty extensive definition of portables vs install in the context of chocolatey in the faq on the wiki.
Will all *.install packages create a symlink in %ALLUSERSPROFILE%/chocolatey/bin?
@CMCDragonkai Shim, not symlink. And no, only executables found in the package directory will be shimmed automatically. Anything else that one wants to shim, they would need to use Install-BinFile.
References:
This is fixed in choco with chocolatey/choco#631