I think it's due to the require sections being impure: github.com/mergermarket/go-pkcs7 is a direct dependency but it's placed in the indirect section. Moving sections for it (or just dropping the dependency) results in it getting placed in the expected section.

cc @bcmills @matloob

Interesting. When I

go mod tidy

before the go get, go-pkcs7 is not being moved from the indirect to the direct section. Wondering why it's in the indirect section?

Update

When I

git reset d8a6efc35a6e70be4bb3b086b678a10a5046fe30
go mod tidy

to before go-pkcs7 was added and reset the go.mod before the tidy, go-pkcs7 appears in the direct section.

So question is why go mod tidy doesn't move it from indirect to direct section.

Notice that #52296 has a flow to produce a go.mod with two separate require blocks where the latter contains not only indirect files. Looks like an issue in go mod.

Notice that #52296 has a flow to produce a go.mod with two separate require blocks where the latter contains not only indirect files. Looks like an issue in go mod.

Ah, yes, I noticed that as well; looks like a bug

That seems like a different issue than the one originally reported here

@seankhliao I think that‘s actually the root cause of this issue as it creates the impure section. #52296 is about module graph evaluation but it does accidentally show how to create an impure section which I wasn‘t able to reproduce otherwise (and hence closed the issue). With the repro it should be possible to fix the root cause.

@andig, could you summarize the repro steps here? (But, to set expectations: if they involve go mod edit, that's probably not going to be worth fixing. go get and go mod tidy are the supported ways to edit dependencies with correct direct/indirect markings. 😅)

It is indeed caused by go mod edit:

mkdir foobar && cd foobar

cat > main.go <<EOF
package main

import (
    "github.com/sirupsen/logrus"
)

func main() {
    logrus.Info("Hello foobar")
}
EOF

go mod init foobar

go mod edit -require github.com/sirupsen/logrus@v1.7.0
go mod tidy

cat go.mod

cat > main.go <<EOF
package main

import (
    "github.com/containerd/containerd/pkg/apparmor"
    "github.com/sirupsen/logrus"
)

func main() {
    if apparmor.HostSupports() {
        logrus.Infof("Running Foobar Deluxe, with AppArmor")
    } else {
        logrus.Infof("Running Foobar Basic")
    }
}
EOF

# >>> the next step causes the problem
go mod edit -require github.com/containerd/containerd@v1.6.2
go mod tidy

cat go.mod
module foobar

go 1.18

require github.com/sirupsen/logrus v1.8.1

require (
	github.com/containerd/containerd v1.6.2
	golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)

It is indeed caused by go mod edit:

@bcmills That being said, it would be nice if tidy caught the problem and corrected the indirect block? It wouldn't be tidy otherwise ;)

@andig, we've rewritten the direct-organizing logic at least twice now to try to fix the heuristic. (It intentionally doesn't mess with existing block structure, in case projects have their own block structure they're trying to maintain.)

I think the only viable improvement would be to give up on maintaining existing structure entirely. That would need a full proposal (since it would be a visible change in behavior), but even then there are all kinds of thorny issues around comment handling that I really don't have the bandwidth to address. 😩

No problem. Then let‘s just close this issue? +1 for the „unfortunate“ label :)