Go 1.18 workspace support in cobra-cli init

[Colin Jones]

When attempting to use cobra-cli init in a project that uses Go 1.18's new workspace mode, I hit what looks like a JSON unmarshaling error (Error: invalid character '{' after top-level value) and initializing fails.

My apologies in advance if I'm misunderstanding any aspect of workspaces, modules, or cobra-cli here - I'm fairly new to Go, but expecting this might be a new edge case in 1.18 due to workspaces.

Steps to reproduce

mkdir cli-playground && cd cli-playground
go work init
mkdir project1 && cd project1 && go mod init project1 && cd ..
mkdir project2 && cd project2 && go mod init project2 && cd ..
go work use project1 project2
cd project2
cobra-cli init
#=> go: creating new go.mod: module project1
#=> go: creating new go.mod: module project2
#=> Error: invalid character '{' after top-level value

I believe this is because go list -json -m returns a stream of JSON objects with relevant modules, whereas this bit of code expects to consume a single JSON object.

I spiked out a test in investigating this behavior, which exposes the same behavior as above. But I’m guessing that approach only works for Go 1.18+, and cobra-cli probably wants to support earlier versions. As far as a fix (if we agree it's worth addressing), I was thinking that the parseModInfo operations could potentially allow using the current directory (from the output of go list -json -e) to decide which of the JSON objects to use. Thoughts?

Workaround

Removing all projects from the workspace except the one I want to cobra-cli init does let things work, and that's good enough to unblock me.

Additional potential gotcha

In experimenting with removing workspace items, there's another case that has surprising (to me) behavior: if we try running cobra-cli init on a module that's not yet included in the workspace.

mkdir cli-playground && cd cli-playground
go work init
mkdir project1 && cd project1 && go mod init project1 && cd ..
mkdir project2 && cd project2 && go mod init project2 && cd ..
go work use project1
cd project2
cobra-cli init

The above appears to succeed, but the contents of project2/main.go are now:

/*
Copyright © 2022 NAME HERE <EMAIL ADDRESS>

*/
package main

import "project1/tmp/cli-playground/project2/cmd"

func main() {
        cmd.Execute()
}

I'm honestly not sure what behavior I'd expect here, since the module isn't in the workspace. But the import path project1/tmp/cli-playground/project2/cmd looks pretty wrong to me (note both project1 and project2 in that path, despite them being peers). I can totally understand this scenario being unsupported / undefined behavior,

But I thought it could be useful to include it in this report, both because I think the existing behavior is kind of surprising (I might personally prefer an error), and more importantly because I imagine that the choice of which module to pick from the list in go list -json -m could potentially create better behavior here.

[github-actions]

This issue is being marked as stale due to a long period of inactivity

[Angelo RC]

same here

[crosslogic]

Same problem

[github-actions]

This issue is being marked as stale due to a long period of inactivity

[Gianluca Mondini]

Same problem

[Jarvan]

same problem, I have given up on not using go.work

[Kinga Marek]

Same problem

[Quinn Ciccoretti]

If your workspace looks something like:

#workspace
module1/
module2/
cli
go.work

you can do something like

mkdir /tmp/cli && cd /tmp/cli
go mod init cli
cobra-cli init
cp /tmp/cli/ /path/to/workspace/cli
cd /path/to/workspace
go work use cli

and it will get you the boilerplate you want.

[bokunodev]

Solution and temporary fix:
go workspace is controlled by GOWORK env var, you can temporarily disable workspace by setting GOWORK to off.
GOWORK=off cobra-cli init .

[github-actions]

This issue is being marked as stale due to a long period of inactivity

[Peter Magnusson]

@bokunodev , nice workaround.
cobra-cli should perhaps show a better error message describing this workaround.

[github-actions]

This issue is being marked as stale due to a long period of inactivity

[André Baldeweg]

+1