Seeing a failure locally when running make test:

--- FAIL: TestWriteToolHelp (0.15s)
    --- FAIL: TestWriteToolHelp/when_plugin_implements_all_help_callbacks (0.00s)
        help_test.go:60:
                Error Trace:    /home/trevor/devel/asdf/internal/help/help_test.go:60
                Error:          Not equal:
                                expected: "Dummy plugin documentation\n\nDummy plugin is a plugin only used for unit tests\n\nDetails specific for version 1.23.4\n"
                                actual  : "Dummy plugin documentation\n\nDummy plugin is a plugin only used for unit tests\n"

                                Diff:
                                --- Expected
                                +++ Actual
                                @@ -4,3 +4 @@

                                -Details specific for version 1.23.4
                                -
                Test:           TestWriteToolHelp/when_plugin_implements_all_help_callbacks

That is from the dummy plugin installed for the test, but version 1.23.4 is actually my asdf Go version set in the repo's .tool-versions file! So it's not properly unsetting ASDF_INSTALL_VERSION and ASDF_INSTALL_TYPE as it should. We don't want the shims (in this case go test) version getting propagated to plugin callbacks for a different plugin. There may be other manifestations of this issue. We need to make sure that asdf env variable as either set to a proper value, or unset so as to not cause issues with shims that invoke other shims.

Seeing a failure locally when running make test:

--- FAIL: TestWriteToolHelp (0.15s)
    --- FAIL: TestWriteToolHelp/when_plugin_implements_all_help_callbacks (0.00s)
        help_test.go:60:
                Error Trace:    /home/trevor/devel/asdf/internal/help/help_test.go:60
                Error:          Not equal:
                                expected: "Dummy plugin documentation\n\nDummy plugin is a plugin only used for unit tests\n\nDetails specific for version 1.23.4\n"
                                actual  : "Dummy plugin documentation\n\nDummy plugin is a plugin only used for unit tests\n"

                                Diff:
                                --- Expected
                                +++ Actual
                                @@ -4,3 +4 @@

                                -Details specific for version 1.23.4
                                -
                Test:           TestWriteToolHelp/when_plugin_implements_all_help_callbacks

That is from the dummy plugin installed for the test, but version 1.23.4 is actually my asdf Go version set in the repo's .tool-versions file! So it's not properly unsetting ASDF_INSTALL_VERSION and ASDF_INSTALL_TYPE as it should. We don't want the shims (in this case go test) version getting propagated to plugin callbacks for a different plugin. There may be other manifestations of this issue. We need to make sure that asdf env variable as either set to a proper value, or unset so as to not cause issues with shims that invoke other shims.

I'll have a closer look tonight. Do you have a sense of how much of an issue this is in practice? This seems like an issue specific to us using asdf to invoke go to test asdf. In that case, it does seem appropriate that go test does have ASDF_INSTALL_VERSION and ASDF_INSTALL_TYPE set (since we're effectively calling asdf exec go test).

I need to trace through the test code in a bit more detail, but my hunch right now is we should be unsetting any ASDF env variables across the board before invoking the test suite. Or setting a default empty value for ASDF_INSTALL_VERSION here:

Open to other thoughts. :)

hrmm thinking about this more.. I suppose there's a practical risk that we've got one asdf managed application that calls into another (eg. pip -> python). Alright, I'll look for a solution for this.

@andrecloutier-pd yes it manifests in this instance because I'm using asdf-managed go to run go tests for asdf (definitely an unusual case) but it's pretty common for us to have a shim from one plugin that invokes another shim from a different plugin (nodejs calling python) or perhaps even more than one shim per plugin (nodejs calling pip calling python possibly).

I've not tested this well enough to say how severe of a problem this is, but something we'll have to get resolved before the next release.