Fix the use of go-use (Go Workspaces) when using dependencies that include replace <dep> => <relative path in the go.mod file

[atandrewlee]

Hello. I'm a 1st time contributor & I will have a ton of question & not know a lot. I hope to learn & help contribute to the project.

The Problem

Currently, if you want to use a submodule as a dependency in Go, you would import the source (from the root module) and then using source-subdir point to the submodule. However, there is a problem. In the go.mod files for these modules, there sometimes are replace statements that point to relative paths (within its own repository structure)

Example: go.opentelemetry.io/otel (Root Module) -> go.opentelemetry.io/otel/metric (Submodule = metric)

# go.mod file for go.opentelemetry.io/otel/metric
replace go.opentelemetry.io/otel => ../
replace go.opentelemetry.io/otel/trace => ../trace

# parts.yaml
parts:
  otel-trace: # can be any name
    plugin: go-use
    source: <otel-monorepo>
    source-subdir: trace

When Go tries to resolve these dependencies, the replace statements look to a relative path, but because of the parts structure ($CRAFT_BACKSTAGE/go-use/), when the Go plugin does a go work use <> on this path, the directory structure has changed, and therefore Go will error, saying that it can't find a dependency.

In order to solve this, we have removed the replace statements directly from the dependency's go.mod file. However, this shouldn't be the case as then it cannot be built from scratch (without a craft tool).

The Solution

The source of the issue is that the paths that go work use calls is a symlink. If we resolve the symlink to the absolute link, this solves the problem & we do not have to remove the replace statements from the go.mod file.

Additional Issues

• When running make test-fast, there is a test that fails (test_get_build_commands_go_use_with_go_dependency in tests/unit/plugins/test_go_plugin). However, because of the solution, the expected behavior that this test tests for has changed.

• Some of the integration tests fail, but they were failing before I made my change.

• There's no issue for this. If this problem statement should be moved into an issue let's create that (I just didn't feel comfortable if I didn't do something according to protocol)

• (Future Fix) Want to add a feature for go-use, but I think that's another PR

From The Template

…work use

• Have you followed the guidelines for contributing?
• Have you signed the CLA?
• Have you successfully run make lint && make test?
• Have you added an entry to the changelog (docs/reference/changelog.rst)?

---

[bepri]

Hey @atandrewlee - thanks for the contribution. In the future, keep in mind that there's no reason to hesitate on opening an issue :)

Since this is a very particular behavior being fixed, could you add an integration test that models the scenario you described and ensures that this test correctly packages something using go use?

[bepri]

This isn't working because the string inside of realpath() is no longer being templated, so that's a string literal instead of containing the contents of those two Python variables. Some tests may begin passing again if that is fixed

[tigarmo]

hi @atandrewlee do you have time to work on this in the near future? We'd like to include this fix in the craft tools this pulse