<@U0N6C2Q9F> you think Go is "beta" rather than "a...
# development
h
@fast-nail-55400 you think Go is "beta" rather than "alpha"? I think your third-party requirements improvement in 2.10 might mean yes. No change to the backend, only the language we use in docs.
f
I’d like to say yes but I’d first like to see a few non-trivial users using it without issue.
👍 1
of course the conundrum is that we may not get more non-trivial users if those users are risk-averse to testing “alpha” software
h
Yeah true. I think we're at least beta quality..the main existential issue I see is how to handle multiple go.mods do you think vendoring might make major changes to current functionality? As long as it's a new feature and not API change, that doesn't hurt stability
K I'll keep it for now. FYI @loud-laptop-17949 2.10.0rc0 was release recently and Tom redesigned third-party handling so that now you should be able to run
go mod download all && go mod tidy
and Pants will be happy. None of those
go list '...'
shenanigans. Thanks again for helping us to figure that out!
👍 2
c
I have a (albeit rather trivial) go project I could try to Pantsify
🙌 2
h
That'd be great! Should be fairly trivial to set up: https://www.pantsbuild.org/v2.10/docs/go
👍 1
f
do you think vendoring might make major changes to current functionality? As long as it’s a new feature and not API change, that doesn’t hurt stability
I don’t believe so. My initial thought there was to have
go_mod
generate a new
go_vendored_package
target type for vendored targets that references the in-tree vendored sources. (Name to be biked shedded.) Target generation would read the
vendor/modules.txt
under a
go.mod
to decide if a package was vendored or not.
👍 1