Local package store for the current user

[majkinetor]

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:

• The local lib location could be ~.choco .
• Test the machine lib and if not accessible by the user use the local lib.
• Use admin tag to determine where to put the package, perhaps in combinatin with the above rule.
• Portable packages could all go to the local lib by default. However, I may want them to be available to all users too via shimgen mechanism in which case there needs to be an option to force location, for example --allusers or opposite --current-user. The problem with portables and tags is that those are not consistent.
• listing local packages must include local lib and should probably have an option to list only selected location clist -l --allusers|--current-user|--everything (default). Also, admin would probably need to know packages for all users in some way (clist --user dummy and clist --user all! where 'all!' is a keyword for all local users in the system).
• There should be some extended documentation or some guidelines related to this option in mainstream installers (install for all and none) and how to prametrize this, perhaps some new choco templates that already start with custom parameter for this.

[ferventcoder]

Let's talk a bit about the design of Chocolatey and then we can see how this may fit in:

• Chocolatey by default will install to a location that is locked down to Administrators. This is by design, not something that we'll change due to security reasons. Most users are personally administrators on their machines. In organizations, this level of security is required.
• Chocolatey can be installed to a different location, where users are responsible for securing their own installation. https://chocolatey.org/install#non-administrative-install

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.

It is true that the default installation is locked down, so C:\ProgramData\chocolatey\lib requires administrative permissions to write to. However a user can install Chocolatey to a custom location and it will not lock down the folder (warning the user they are responsible for securing their installation). That means while C:\ProgramData\chocolatey\lib is locked down, $env:ChocolateyInstall\lib is not necessarily locked down.

This is clearly suboptimal, choco should work without elevation as much as it can.

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 in

This 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.

[ferventcoder]

Some of the other concerns here

• This introduces quite a bit of complexity. Now instead of one location for packages, there are two.
• How does dependency resolution work for current user that has local packages? How does it work for a user that doesn't?
• How should Chocolatey resolve differences in that case when you suddenly have the same package installed (perhaps different versions for a local user and an administrator)?
• What happens if a user had a package that an updated version of the package is installed in the machine store? Should the local package be removed?
• Which one of the two packages (local or machine) should get preference on PATH?

[majkinetor]

Most users are personally administrators on their machines.

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.

Chocolatey can be installed to a different location, where users are responsible for securing their own installation.

Many users wouldn't know how to do this and its totally impractical compared to the proposed feature.

This introduces quite a bit of complexity. Now instead of one location for packages, there are two.

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.

How does dependency resolution work for current user that has local packages? How does it work for a user that doesn't?

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.

How should Chocolatey resolve differences in that case when you suddenly have the same package installed (perhaps different versions for a local user and an administrator)?

In this case user uses its own version if its newer. Other users wont see the local package anyway.

What happens if a user had a package that an updated version of the package is installed in the machine store? Should the local package be removed?

Choco could scan all local stores and link older packages to the machine one.

Which one of the two packages (local or machine) should get preference on PATH?

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.

[majkinetor]

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.

[dukechem]

"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."

Not so sure windows puts user path in front of machine path. On my win7-64 box it did not. For example, if choco is installed as admin first, and then a 2nd non-admin install of choco is done, The local PATH env variable has only one item: ;C:\ProgramData\chocoportable\bin;

But SET in CMD shows path ends in: C:\WINDOWS\system32;C:\WINDOWS;(...);C:\ProgramData\chocolatey\bin;;C:\ProgramData\chocoportable\bin;

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