go install, replace directive any ongoing discussions?

[James Lawrence]

I missed the conversation originally. however go install has been left in a unfortunate state where it bewilderingly errors out when the main module contains a replace directive. I'm primarily wondering where I should be going to contribute to that conversation and if there is someone on the go team I can just file a few experience reports with around package tooling over the past few release. as the go tools have seemingly become less user friendly over the past few releases. its mainly a bunch of varied issues.

[Axel Wagner]

On Sun, Mar 7, 2021 at 3:45 AM James Lawrence <jlja...@gmail.com> wrote:

I missed the conversation originally. however go install has been left in a unfortunate state where it bewilderingly errors out when the main module contains a replace directive.

This sounds like a bug. I would file an issue with an easy reproduction case.

 

I'm primarily wondering where I should be going to contribute to that conversation and if there is someone on the go team I can just file a few experience reports with around package tooling over the past few release. as the go tools have seemingly become less user friendly over the past few releases. its mainly a bunch of varied issues.

You can post them here - either by posting them on a blog or something and linking, or writing them here verbatim. Many people on the Go team are reading this list.

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c421a1a9-5215-45f9-9a95-ef7b19485e25n%40googlegroups.com.

[Paul Jolly]

>> I missed the conversation originally. however go install has been left in a unfortunate state where it bewilderingly errors out when the main module contains a replace directive.
>
> This sounds like a bug. I would file an issue with an easy reproduction case.

Erroring on replace directives is an intentional decision for now:
https://github.com/golang/go/issues/40276#issue-659471259

But might be relaxed in the future:

> Parts of this proposal are more strict than is technically necessary (for
> example, requiring one module, forbidding replace directives). We could relax
> these restrictions without breaking compatibility in the future if it seems
> expedient. It would be much harder to add restrictions later.

If you think this is a valid case for requiring non-directory replace
directives to be applied, then I suggest raising an issue with some
details.

[Axel Wagner]

I wasn't aware that this restriction is intentional. I wasn't part of that discussion and it seems too long for me to read after the fact, so I probably shouldn't comment on it. I'm admittedly a bit befuddled by the design decisions, though (as I understand them).

[James Lawrence]

I read through those issues Paul, I found them less than convincing for the global go install use case. regardless I'll file an issue. I didn't want to file an issue because of how long and pointless most of the conversation around the global install replace directive usage seemed.

I'll file other issues around the random set of related irritations the ongoing module work has caused.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/10AJZaH9OFU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGwcwp3if-zgQYN3HL5c%2BPedafuS6uz%2BtPBymHasFSzyw%40mail.gmail.com.

--

James Lawrence

[James Lawrence]

well an issue was filed, and promptly closed.

--

James Lawrence

[Dan Kortschak]

On Sun, 2021-03-07 at 07:57 +0000, Paul Jolly wrote:
> Erroring on replace directives is an intentional decision for now:
> https://github.com/golang/go/issues/40276#issue-659471259
>
> But might be relaxed in the future:
>
> > Parts of this proposal are more strict than is technically
> > necessary (for
> > example, requiring one module, forbidding replace directives). We
> > could relax
> > these restrictions without breaking compatibility in the future if
> > it seems
> > expedient. It would be much harder to add restrictions later.
>
> If you think this is a valid case for requiring non-directory replace
> directives to be applied, then I suggest raising an issue with some
> details.

At the very least the documentation explaining the error in
https://golang.org/cmd/go could be improved; the rationale for the
error on that page is very opaque (and contradictory).

[James Lawrence]

I'm actually making the argument that the error is in fact incorrect as the replace directive has always been about compilation

and therefore they should always apply when installing a module's main package whether its remoting fetching the module via go install or when compiling a module directly.

however when managing dependencies the directive has never applied. and likely any module which has dependencies with a replace directive are likely broken

and that the error should be detected when modifying go.mod with a new or existing dependency.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/10AJZaH9OFU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/45def257cd9d0c7c345e8ad0a4bf1c8444bcf531.camel%40kortschak.io.

--

James Lawrence