-
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
Local package store for the current user #912
Comments
Let's talk a bit about the design of Chocolatey and then we can see how this may fit in:
It is true that the default installation is locked down, so
And it does, just not by default. Again, as mentioned previously, a user can choose a non-administrative install. Thoughts on where this may fit inThis is sounding a bit like multiple users running installs to the same machine, which leads me to believe this is more of an organizational use of Chocolatey. This feature doesn't make much sense in the FOSS version, but it does make quite a bit of sense in the Business version. Perhaps I'm missing some possible use cases outside of organizational use where this would make sense though. |
Some of the other concerns here
|
This is not that relevant because of UAC. You still need to open elevated prompt. For example my team never works in elevated one and in 95% of the cases choco install fails, then everybody remembers "yeah, admin". So its way inconvenient to do so and fully disabling UAC isn't recommended. Perhaps if choco automatically elevate like normal installers do this feature wouldn't be needed !!! In that sense, its not only relevant for buisnis.
Many users wouldn't know how to do this and its totally impractical compared to the proposed feature.
I don't know, never looked the choco code in detail. You are the one to determine benefit vs cost ratio. However, keep in mind that this behavior is something people would expect.
That depends on the dependency I guess - If all dependencies are non local and non existent then it should fail. If all deps can be local or some of them are preinstalled at machine level it should pass etc.
In this case user uses its own version if its newer. Other users wont see the local package anyway.
Choco could scan all local stores and link older packages to the machine one.
Windows AFAIK always puts User PATH in front of machine one so this will not be a problem. Local packages should update local PATH if they do so. |
In short, I really think ideally this would be totally solvable with auto elevation all the time. Then this feature could either dropped or reserved for commercial variant. |
Not so sure windows puts user path in front of machine path. On my win7-64 box it did not. But SET in CMD shows path ends in: If you wanted to prepend the chocoportable\bin then googling suggests you have to mess with the registry: http://stackoverflow.com/questions/40009677/batch-how-to-prepend-the-path-environment-variable |
Choco should have a local store for the user because now even non-admin packages must be downloaded to
C:\ProgramData\chocolatey\lib
which is not accessible without elevation (I call it machine lib in advance). This means that tools that dont require elevation during runtime must be at least installed by admins.As an example au package downloads the zip file using helper functions which unpacks it in the machines
lib
directory [here I get an error]. Afterwards it installs the module for the local user only so the elevation is needed only during installation. Now, au installer can be changed so not to use$toolsPath
but that is beside the point. Majority of packages use$toolsPath
for this as it is in the template like that.This is clearly suboptimal, choco should work without elevation as much as it can. What I currently do not know is if this work is beneficial enough to get implementation time due to the specific target group that is actually using chocolatey ( do we want this group extended ? ) but it indeed sounds as natural request for this domain.
Some thoughts:
~.choco
.admin
tag to determine where to put the package, perhaps in combinatin with the above rule.--allusers
or opposite--current-user
. The problem with portables and tags is that those are not consistent.clist -l --allusers|--current-user|--everything (default)
. Also, admin would probably need to know packages for all users in some way (clist --user dummy
andclist --user all!
where 'all!' is a keyword for all local users in the system).The text was updated successfully, but these errors were encountered: