cobra-cli Go 1.18 workspace support in cobra-cli init

Go 1.18 workspace support in cobra-cli init

Open trptcolin opened this issue 2 years ago • 14 comments

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.

Mar 25 '22 23:03 trptcolin

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

May 25 '22 00:05 github-actions[bot]

same here

May 27 '22 22:05 angelorc

Same problem

Jun 15 '22 19:06 crosslogic

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

Sep 27 '22 00:09 github-actions[bot]

Same problem

Oct 11 '22 12:10 zapateo

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

Nov 18 '22 10:11 jarvanstack

Same problem

Dec 05 '22 09:12 Astenna

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.

Jan 03 '23 15:01 QuinnCiccoretti

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 .