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

proposal: path/current: improve ergonomics around getting the current file's path or directory #50367

Closed
matthewmueller opened this issue Dec 27, 2021 · 4 comments

Comments

@matthewmueller
Copy link

matthewmueller commented Dec 27, 2021

I noticed that there's a lot of confusion around how to get the current file's path. I just wrote the most recent answer to try and stem the confusion.

_, filename, _, ok := runtime.Caller(0)
if !ok {
    return nil, errors.New("unable to get the current filename (e.g. __filename)")
}
dirname := filepath.Dir(file)

This is a pretty common use case and I think it'd be nice to add a package in the standard library to improve the ergonomics. Similar to the reason os.Executable() was added.

Perhaps path/current:

package current

import "path/filepath"

// File is the __filename equivalent
func File() string {
    _, filename, _, ok := runtime.Caller(1)
    if !ok {
        panic("unable to get the current filename (ideally, this never happens)")
    }
    return filename
}


// Dir is the __dirname equivalent
func Dir() string {
  return filepath.Dir(File())
}

Usage:

package main

import "path/current"

func main() {
  current.File()
  current.Dir()
}

This is somewhat similar to #37620, but more focused on reducing confusion. Ideally the call would always succeed too so we don't need to check the error.

@gopherbot gopherbot added this to the Proposal milestone Dec 27, 2021
@robpike
Copy link
Contributor

robpike commented Dec 28, 2021

I will do a curmudgeonly pushback and say that you haven't explained why this needs to be easier. Not everything needs to be reduced to a one-liner.

Is the problem really all that common? Outside of logging, most of which is done in existing packages, how often does it arise? I've almost never needed it on the fly, which says to me that it doesn't require special treatment.

For the proposal to succeed, you'd need to explain the actual need, rather than desire.

@matthewmueller
Copy link
Author

matthewmueller commented Dec 28, 2021

I agree that adding features to the standard library should not be taken lightly. I don't necessarily think it needs to be easier, it would be nice if it was easier.

My use case for needing this was generating code that needed to be aware of where it was generated so it could serve assets from the correct location in the filesystem. That's where I ran into the linked StackOverflow post. I'd expect even experienced Go developers have to lookup the signature of this command every time. At least that's the case for me.

The main problem I'd like to solve is when you Google "find current directory Go", the first 11 StackOverflow answers you get are wrong. In terms of upvotes, this question is in the top 50 questions for Go on StackOverflow. It's also been viewed 232k times over 8 years. To me, this points to general confusion for newcomers and some faulty code in the wild.

If it doesn't make sense in the standard library, another solution could be clearing up this answer on StackOverflow. It seems like the Go org has some say with the "Answer recommended by Go Language" showing up on top. Unfortunately, this answer is subtly wrong.

@robpike
Copy link
Contributor

robpike commented Dec 28, 2021

To this ole Unix hand, "find current directory" means os.Getwd. Your use of that term is a much rarer invocation, whatever StackOverflow may argue.

You may be correct that the right thing to do is to correct the example on SO. A bad answer on SO is not on its own a compelling case to change the library.

@matthewmueller
Copy link
Author

matthewmueller commented Dec 28, 2021

Now we get into what "current" means in this context :)

Fair enough, I'll close this proposal. Adjusting the "Answer Recommended by Go Language" doesn't really make sense as a new issue on Github. I'll reach out to the people managing the Go Collective on StackOverflow to try and correct this.

@golang golang locked and limited conversation to collaborators Dec 28, 2022
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

3 participants