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

Make mkVendorEnv generate modules.txt #117

Open
doronbehar opened this issue Apr 12, 2023 · 2 comments · May be fixed by #168
Open

Make mkVendorEnv generate modules.txt #117

doronbehar opened this issue Apr 12, 2023 · 2 comments · May be fixed by #168

Comments

@doronbehar
Copy link
Contributor

So to my understanding, this package emulates go mod vendor. However, in order to use the vendor directory with buildGoModule (see #116), the modules.txt file is required:

go: inconsistent vendoring in /build/source:
    github.com/adrg/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    github.com/alecthomas/chroma/[email protected]: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
 ...
@doronbehar doronbehar changed the title Make mkVendorEnv generate `modules.txt Make mkVendorEnv generate modules.txt Apr 12, 2023
@doronbehar
Copy link
Contributor Author

However, I see that buildGoApplication can replace buildGoModule, and indeed it helps cross compilation.

@diamondburned diamondburned mentioned this issue Feb 11, 2024
Open
@obreitwi
Copy link

Note: modules.txt is now required, effectively causing gomod2nix to be incompatible with go version 1.23.

obreitwi added a commit to obreitwi/gomod2nix that referenced this issue Sep 1, 2024
@obreitwi
fix: build with go 1.23 by tracking modules.txt
9832283 
Fixes: nix-community#117

Since go 1.23, `vendor/modules.txt` is [required](golang/go@38ee0c7#diff-61fb6e44eac25bd4d6a8a64b3f38ee8a41faaefd1ef481170a011ecfc0f7c76bR344).

Hence, this is a first attempt to track `modules.txt` via gomod2nix.

Since, unfortunately, `module.txt` employs a bespoke custom format in
which
[varying](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/cmd/go/internal/modload/vendor.go;l=57)
[numbers](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/cmd/go/internal/modload/vendor.go;l=103)
of `#` hold meaning I deemed it more stable to not reverse engineer it.

Instead, we generate it when running `gomod2nix` by executing `go mod
vendor` and tracking its content in `gomod2nix.toml`.

Not the most elegant solution, but it works and enables us to use
gomod2nix with go v1.23.

Any comments appreached…
@obreitwi obreitwi linked a pull request Sep 1, 2024 that will close this issue
Open
obreitwi added a commit to obreitwi/gomod2nix that referenced this issue Nov 17, 2024
@obreitwi
fix: build with go 1.23 by tracking modules.txt
928f240 
Fixes: nix-community#117

Since go 1.23, `vendor/modules.txt` is [required](golang/go@38ee0c7#diff-61fb6e44eac25bd4d6a8a64b3f38ee8a41faaefd1ef481170a011ecfc0f7c76bR344).

Hence, this is a first attempt to track `modules.txt` via gomod2nix.

Since, unfortunately, `module.txt` employs a bespoke custom format in
which
[varying](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/cmd/go/internal/modload/vendor.go;l=57)
[numbers](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/cmd/go/internal/modload/vendor.go;l=103)
of `#` hold meaning I deemed it more stable to not reverse engineer it.

Instead, we generate it when running `gomod2nix` by executing `go mod
vendor` and tracking its content in `gomod2nix.toml`.

Not the most elegant solution, but it works and enables us to use
gomod2nix with go v1.23.

Any comments appreached…
marcusramberg pushed a commit to obreitwi/gomod2nix that referenced this issue Nov 25, 2024
@obreitwi @marcusramberg
fix: build with go 1.23 by tracking modules.txt
6eb64b0 
Fixes: nix-community#117

Since go 1.23, `vendor/modules.txt` is [required](golang/go@38ee0c7#diff-61fb6e44eac25bd4d6a8a64b3f38ee8a41faaefd1ef481170a011ecfc0f7c76bR344).

Hence, this is a first attempt to track `modules.txt` via gomod2nix.

Since, unfortunately, `module.txt` employs a bespoke custom format in
which
[varying](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/cmd/go/internal/modload/vendor.go;l=57)
[numbers](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/cmd/go/internal/modload/vendor.go;l=103)
of `#` hold meaning I deemed it more stable to not reverse engineer it.

Instead, we generate it when running `gomod2nix` by executing `go mod
vendor` and tracking its content in `gomod2nix.toml`.

Not the most elegant solution, but it works and enables us to use
gomod2nix with go v1.23.

Any comments appreached…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: build with go 1.23 by tracking modules.txt obreitwi/gomod2nix
2 participants
@obreitwi @doronbehar