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.

Sign up for GitHub

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

Jump to bottom

cmd/go: clarify the meaning of -workfile #51172

Closed
hyangah opened this issue Feb 13, 2022 · 4 comments
Closed

cmd/go: clarify the meaning of -workfile #51172

hyangah opened this issue Feb 13, 2022 · 4 comments
Labels
Documentation FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@hyangah
Copy link
Contributor

hyangah commented Feb 13, 2022 •
edited

What version of Go are you using (go version)?

$ go version
go version devel go1.18-5bd734839d Sun Feb 13 02:11:11 2022 +0000 darwin/amd64

What did you do?

From the original proposal, I thought -workfile would accept a path to other .work file.

If -workfile is set to off, workspace mode will be disabled. If it is auto (the default), workspace mode will be enabled if a file named go.work is found in the current directory (or any of its parent directories), and disabled otherwise. If -workfile names a path to an existing file that ends in .work, workspace mode will be enabled. Any other value is an error.

But with the description of -workfile from go help build, it's unclear to me that is implemented or not.

  • Let's either document it if implemented, or update the proposal if that's not implemented.
$ go help build
    ...
        -workfile file
                in module aware mode, use the given go.work file as a workspace file.
                By default or when -workfile is "auto", the go command searches for a
                file named go.work in the current directory and then containing directories
                until one is found. If a valid go.work file is found, the modules
                specified will collectively be used as the main modules. If -workfile
                is "off", or a go.work file is not found in "auto" mode, workspace
                mode is disabled.

  • If implemented, clarify the workfile should be an absolute path.

  • Consider to mention the -workfile flag in the documentation of go help work. Currently there is no mention of this flag.

cc @matloob
@hyangah
Copy link
Contributor Author

hyangah commented Feb 13, 2022

And, what does go work init do if -workfile flag is provided?
I see that it checks whether the file is an absolute path. But, I don't see it creating the workfile - regardless what value I add, go work init creates a go.work file in the current directory.

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 14, 2022
@dmitshur
Copy link
Contributor

Placing this in Backlog by default, but if someone is planning to resolve this for 1.18, or thinks it must be, please update this issue accordingly.

@dmitshur dmitshur added this to the Backlog milestone Feb 14, 2022
@ainar-g
Copy link
Contributor

ainar-g commented Mar 16, 2022

For those looking for an explanation and coming to this issue from the search results, the flag -workfile has been replaced with the GOWORK environment variable. The corresponding section of the Go Modules Reference simply hasn't been updated yet.

@matloob
Copy link
Contributor

matloob commented Mar 16, 2022

-workfile is gone, so I'll close this issue. I'll update the go modules reference.

@matloob matloob closed this as completed Mar 16, 2022
@golang golang locked and limited conversation to collaborators Mar 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Documentation FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@dmitshur @ainar-g @hyangah @gopherbot @matloob