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: relative imports work when specify .go files directly #51125

Closed
ronaldpetty opened this issue Feb 10, 2022 · 4 comments
Closed

cmd/go: relative imports work when specify .go files directly #51125

ronaldpetty opened this issue Feb 10, 2022 · 4 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.18

Comments

@ronaldpetty
Copy link

I am using golang:1.18beta2.

It seems 1.18 allows relative packages (import "./mypkg"), this is with or without go.mod and any setting (or not) of GO111MODULE.

Maybe this is expected, I just can't infer that from release notes. Largely just looking for guidance around using 'replace' versus 'relative'.

Here is my test layout (and it runs and prints hello).

% tree .
.
├── driver.go
├── mypkg
 │   └── code.go
└── noGo.sh

cat driver.go 
package main

import "fmt"
import "./mypkg"

func main() {
	mypkg.Myfunc()
}

cat ./mypkg/code.go
package mypkg

import "fmt"

func Myfunc() {
	fmt.Println("Hello World")
}

Here was my test script:

% cat noGo.sh 
#!/bin/bash -x

versions=(1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18beta2)
versions=(1.18beta2)

for v in ${versions[@]}; do
	printf "checking $v\n"
	docker image pull -q golang:$v
	docker container run -w /code -v $(pwd):/code --rm -d --name testbed  golang:$v tail -f /dev/null

	docker container exec testbed sh -c "go version"

	docker container exec testbed sh -c "go env | grep 111"
	docker container exec testbed sh -c "go help env | grep 111"
	docker container exec testbed sh -c "go help environment | grep 111"

	docker container exec testbed sh -c "go run driver.go ; echo $?"
	docker container exec testbed sh -c "GO111MODULE=off go run driver.go ; echo $?"
	docker container exec testbed sh -c "GO111MODULE=on go run driver.go ; echo $?"
	docker container exec testbed sh -c "GO111MODULE=auto go run driver.go ; echo $?"

	docker container stop testbed
	printf "=========================================================================================================\n"
done

Run it without go.mod, then again with go.mod, both work for 1.18beta2.
@seankhliao seankhliao changed the title affected/package: "go run" allows relative packages without go.mod replace cmd/go: relative imports work when specify .go files directly Feb 10, 2022
@seankhliao seankhliao added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Feb 10, 2022
@seankhliao
Copy link
Member

cc @bcmills @matloob

@bcmills bcmills self-assigned this Feb 11, 2022
@bcmills bcmills added this to the Backlog milestone Feb 11, 2022
@bcmills bcmills modified the milestones: Backlog, Go1.19, Go1.18 Feb 14, 2022
@bcmills
Copy link
Contributor

bcmills commented Feb 14, 2022

This does appear to be a regression in Go 1.18. I'm in the process of tracking it down, but given the failure mode (a package that compiles when it shouldn't) I don't think it's severe enough to hold up the release.

(If nothing else, we can fix it in a backport in 1.18.1.)

@bcmills
Copy link
Contributor

bcmills commented Feb 15, 2022

Bisected:

d397fc1169aa2491bc807812105371819366deb8 is the first bad commit
commit d397fc1169aa2491bc807812105371819366deb8
Author: Michael Matloob <matloob@golang.org>
Date:   Mon Aug 2 15:54:51 2021 -0400

    [dev.cmdgo] don't give command-line-arguments a module

    Don't associate command-line-arguments with a module. Even though the
    sources in the command-line-arguments package may exist within the
    module's packages, the command-line-arguments package is distinct from
    the package in the module. It has its own identity, and further, even if
    all the same sources are listed, build tag filtering is not applied for
    command-line-arguments.

    For #45713

    Change-Id: I555752021d58ea25e65699b4959f787ea5fa2cda
    Reviewed-on: https://go-review.googlesource.com/c/go/+/339170
    Trust: Michael Matloob <matloob@golang.org>
    Trust: Bryan C. Mills <bcmills@google.com>
    Run-TryBot: Michael Matloob <matloob@golang.org>
    TryBot-Result: Go Bot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>

 src/cmd/go/internal/modload/build.go               | 40 ++++------------------
 .../script/mod_list_command_line_arguments.txt     | 35 +++++++++++++++++++
 src/cmd/go/testdata/script/mod_outside.txt         |  2 +-
 src/cmd/go/testdata/script/version.txt             |  7 ++++
 src/cmd/go/testdata/script/work.txt                | 16 ++++++++-
 5 files changed, 65 insertions(+), 35 deletions(-)
 create mode 100644 src/cmd/go/testdata/script/mod_list_command_line_arguments.txt

That's a strong clue to run with. I'll work on a fix.

@gopherbot
Copy link

Change https://go.dev/cl/386176 mentions this issue: cmd/go/internal/modload: set errors for packages with invalid import paths

@bcmills bcmills mentioned this issue Feb 16, 2022
Open
@rsc rsc unassigned bcmills Jun 22, 2022
@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@ronaldpetty @bcmills @gopherbot @seankhliao