Skip to content
This repository has been archived by the owner on Feb 19, 2019. It is now read-only.

Get-BinRoot should really be C:\ProgramData\chocolatey\bin by default. #660

Closed
Redsandro opened this issue Jan 12, 2015 · 16 comments
Closed

Comments

@Redsandro
Copy link
Contributor

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.

@ferventcoder
Copy link
Contributor

That's the problem. Get-ToolsRoot is really the name of this. It's horrrrrribly named.

@Redsandro
Copy link
Contributor Author

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.

@ferventcoder
Copy link
Contributor

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.

@Redsandro
Copy link
Contributor Author

Can you try and explain it to me?

@ferventcoder
Copy link
Contributor

There is a concept of a place where you can install tools due to two reasons -

  1. current POSH choco putting version numbers on folders and
  2. 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.

@Redsandro
Copy link
Contributor Author

Perhaps we should have a binRoot and a toolsRoot

@ferventcoder
Copy link
Contributor

Do we need a bin root? Or is it that choco is not doing a sufficient job in some cases?

@gep13
Copy link
Member

gep13 commented Jan 12, 2015

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.

@Redsandro
Copy link
Contributor Author

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?

@ferventcoder
Copy link
Contributor

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.

@Redsandro
Copy link
Contributor Author

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.

@masaeedu
Copy link

@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?

@ferventcoder
Copy link
Contributor

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.

@CMCDragonkai
Copy link

Will all *.install packages create a symlink in %ALLUSERSPROFILE%/chocolatey/bin?

@ferventcoder
Copy link
Contributor

@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:

@ferventcoder
Copy link
Contributor

This is fixed in choco with chocolatey/choco#631

@chocolatey-archive chocolatey-archive locked and limited conversation to collaborators Apr 6, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants