DOTNET_CLI_HOME usage

[tmds]

DOTNET_CLI_HOME is used in this repo and it is showing up in a number of other repos.

Based on the usage, I wonder if the variable could be eliminated and be replaced with Environment.GetFolderPath(SpecialFolder.xxx, SpecialFolderOption.Create).

[tmds]

CC @wli3

[wli3]

This is a supported way to change the dotnet profile directory. So you could store .dotnet folder to other place instead of your home directory.

[wli3]

As for why we don't use this API to get home directory and use $HOME instead, @livarcocc do you have any context?

[livarcocc]

I don't remember why. Maybe the API was not available when we started, but that's just a wild guess. Do you want to keep this bug open to update the API usage?

@tmds we will keep DOTNET_CLI_HOME around.

[tmds]

@livarcocc looking for the origin of DOTNET_CLI_HOME, this seems to be the most relevant comment:

The problem with using SpecialFolder.UserProfile and SpecialFolder.LocalApplicationData (or any SpecialFolder value that uses HOME as the basis) is that if HOME is not set, CoreFx will use Path.GetTempPath instead. While it will allow the dotnet command to "work", the data is now shared between all users without HOME set (for example, dotnet will use /tmp/.dotnet for its data). If CI is the most common scenario where HOME is not set, then I don't think this would be acceptable behavior for that scenario.

This isn't correct. When HOME is not set, GetFolderPath still returns the home folder of the user (from /etc/passwd).

[tmds]

@livarcocc looking for the origin of DOTNET_CLI_HOME, this seems to be the most relevant comment:

The problem with using SpecialFolder.UserProfile and SpecialFolder.LocalApplicationData (or any SpecialFolder value that uses HOME as the basis) is that if HOME is not set, CoreFx will use Path.GetTempPath instead. While it will allow the dotnet command to "work", the data is now shared between all users without HOME set (for example, dotnet will use /tmp/.dotnet for its data). If CI is the most common scenario where HOME is not set, then I don't think this would be acceptable behavior for that scenario.

This isn't correct. When HOME is not set, GetFolderPath still returns the home folder of the user (from /etc/passwd).

[tmds]

Sorry for the multiple posts. GitHub was saying it couldn't post, while it did post.

[livarcocc]

@peterhuene to comment here, since the comment you quoted above was made by him.

[peterhuene]

@tmds That's a good point, although it would still silently fall back to a temporary directory in some cases, such as in a container running as a user that isn't in the image's /etc/passwd.

The intent of the variable was to give users control over where dotnet (and friends) write their various files without impacting other applications.

I think the explicit check of HOME can definitely be replaced with Environment.GetFolderPath so that we do get the getpwuid lookup behavior when not set, but I'd still like users to have explicit control in some fashion (if not this variable, then through some other mechanism).

What are your thoughts on this?

[tmds]

As a user, I don't need to be able to change dotnet's HOME specifically. I can't and don't need to do this for other tools either.
So I would like to eliminate the variable.
But maybe due to backwards compatibility reasons, it has to stay anyway.

I think the explicit check of HOME can definitely be replaced with Environment.GetFolderPath

👍

[wli3]

one thing i find Environment.GetFolderPath is it will no longer honor custom %USERPROFILE%. We could break user who sets that. Although it is not that common in Windows. And another good news is unix impl still do https://github.com/dotnet/corefx/blob/a10890f4ffe0fadf090c922578ba0e606ebdd16c/src/Common/src/System/IO/PersistedFiles.Unix.cs#L87