Skip to content
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

config: don't call homedir on init() #2161

Merged
merged 1 commit into from
May 7, 2020

Conversation

thaJeztah
Copy link
Member

The homedir.Get() function can call out to external applications to get user information.

This patch changes the package to lazily obtain the user's home-directory on first use, instead of when initializing the package.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

@thaJeztah
Copy link
Member Author

@kolyshkin
Copy link
Contributor

kolyshkin commented Oct 24, 2019

The homedir.Get() function can call out to external applications to get user information.

Can you elaborate on this?

My $0.02: since golang 1.8 or so 1.9 user.Current() result is cached. Source: golang/go@2ca5d10

@thaJeztah
Copy link
Member Author

Can you elaborate on this?

arg; you're right; I was thinking the package was still using the runc / libcontainer stuff, but that was removed in moby/moby@a8608b5#diff-1b2f13bed97df1999bf7f922eb2f0909

Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Member Author

@kolyshkin let me know what you think; I think it still makes sense to get this info lazily, but happy to close otherwise

@thaJeztah
Copy link
Member Author

Actually; let me make one small change, and don't attempt to set the dir if it's non-empty (which could be if a user of this package calls SetDir() before Dir()

@kolyshkin
Copy link
Contributor

Actually; let me make one small change, and don't attempt to set the dir if it's non-empty (which could be if a user of this package calls SetDir() before Dir()

I don't like this change -- now you have two "run once" guards, and they are scattered.

Maybe it's better to rewrite Dir() to encapsulate setConfigDir(), i.e. the same way that user.Current is written (except there's no need to do a copy a string being returned)?

https://github.com/golang/go/blob/46e0d724b3f14fd0d350123bbf101e815b493791/src/os/user/lookup.go#L9-L28

@thaJeztah
Copy link
Member Author

thaJeztah commented Oct 25, 2019

@kolyshkin it's a bit problematic; tbh I think this package is way too complex

Dir() (and thus configDir) is quite ambiguous; it's neither the "default" location, nor the location of the current config.

It's a global / package level variable that can be set to a default, but also overwritten by a "setter".

eg, someone could set the directory;

func SetDir(dir string) {

In which case we don't want to overwrite it with the default

Someone could load the config, and specify the configDir

cli/cli/config/config.go

Lines 82 to 85 in 7a279af

func Load(configDir string) (*configfile.ConfigFile, error) {
if configDir == "" {
configDir = Dir()
}

In which case Dir() is not changed, and thus doesn't reflect the current config's location. But if no path is specified, it is used as the default, and thus the config's location

And worst case; if the specified location couldn't be found, in which case the current config location is neither the one specified, nor the default one, but a completely different path:

cli/cli/config/config.go

Lines 108 to 112 in 7a279af

// Can't find latest config file so check for the old one
homedir, err := os.UserHomeDir()
if err != nil {
return configFile, errors.Wrap(err, oldConfigfile)
}

@jonjohnsonjr
Copy link
Contributor

This tripped us up, so I had to land a workaround: google/go-containerregistry#568

I'm in favor of this change :)

@thaJeztah
Copy link
Member Author

@kolyshkin PTAL

This patch changes the package to lazily obtain the user's home-
directory on first use, instead of when initializing the package.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Copy link
Collaborator

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants