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.

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

refactor: use exclude directives instead of replace directives for pinning #8056

Merged
merged 1 commit into from Nov 15, 2022

Conversation

bcmills
Copy link
Contributor

@bcmills bcmills commented Nov 8, 2022

Description

The 'replace' directive is very heavy-handed: it replaces nodes in the dependency graph with different source code. That distorts their apparent transitive dependencies, and makes a module that uses 'exclude' directives much more difficult for downstream consumers to use even if they aren't using the parts of the module that depend on the replaced versions.

In contrast, the 'exclude' directive knocks out specific version requirements from the module graph without otherwise affecting the dependencies of any remaining module in the graph.

'exclude' directives also make it clearer why particular pins are necessary: normally only the 'require' directive is needed to select desired versions (since they are not upgraded implicitly), so having 'exclude' blocks for specific conflicting requirements more clearly shows which of the transitive dependencies are believed to be spurious.

(See https://go.dev/ref/mod#go-mod-file-exclude.)

Follow-up Work

In the long term, the code should be updated to work with dependencies selected using only require directives, which respect the requirements of dependencies, rather than pinning versions below those requirements.

Testing

The following is a diff of go list -m all before and after this change.
Note that the former replace targets are now the MVS-selected versions.

One additional module is now visible in the module graph (github.com/docker/spdystream), but it has no effect on the resulting artifacts because it does not provide any transitively-imported package.

~/src/github.com/GoogleContainerTools/skaffold$ diff before.txt after.txt
312a313
> github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96
499c500
< github.com/googleapis/gnostic v0.4.1 => github.com/googleapis/gnostic v0.4.1
---
> github.com/googleapis/gnostic v0.4.1
702c703
< github.com/opencontainers/image-spec v1.0.3-0.20220114050600-8b9d41f48198 => github.com/opencontainers/image-spec v1.0.2-0.20210730191737-8e42a01fb1b7
---
> github.com/opencontainers/image-spec v1.0.2-0.20210730191737-8e42a01fb1b7
842c843
< github.com/tektoncd/pipeline v0.5.1-0.20190731183258-9d7e37e85bf8 => github.com/tektoncd/pipeline v0.5.1-0.20190731183258-9d7e37e85bf8
---
> github.com/tektoncd/pipeline v0.5.1-0.20190731183258-9d7e37e85bf8
1005c1006
< gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b => gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c
---
> gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c
1012c1013
< k8s.io/apimachinery v0.23.5 => k8s.io/apimachinery v0.21.6
---
> k8s.io/apimachinery v0.21.6

…nning

The 'replace' directive is very heavy-handed: it replaces nodes in the
dependency graph with different source code. That distorts their
apparent transitive dependencies, and makes a module that uses
'exclude' directives much more difficult for downstream consumers to
use even if they aren't using the parts of the module that depend on
the replaced versions.

In contrast, the 'exclude' directive knocks out specific version
requirements from the module graph without otherwise affecting the
dependencies of any remaining module in the graph.

'exclude' directives also make it clearer why particular pins are
necessary: normally only the 'require' directive is needed to select
desired versions (since they are not upgraded implicitly), so having
'exclude' blocks for specific conflicting requirements more clearly
shows which of the transitive dependencies are believed to be
spurious.
@codecov
Copy link

codecov bot commented Nov 8, 2022

Codecov Report

Merging #8056 (46a5345) into main (290280e) will decrease coverage by 3.97%.
The diff coverage is 53.46%.

@@            Coverage Diff             @@
##             main    #8056      +/-   ##
==========================================
- Coverage   70.48%   66.51%   -3.98%     
==========================================
  Files         515      597      +82     
  Lines       23150    29146    +5996     
==========================================
+ Hits        16317    19386    +3069     
- Misses       5776     8322    +2546     
- Partials     1057     1438     +381     
Impacted Files Coverage Δ
cmd/skaffold/app/cmd/credits/export.go 0.00% <0.00%> (ø)
cmd/skaffold/app/cmd/deploy.go 40.90% <0.00%> (-12.94%) ⬇️
cmd/skaffold/app/cmd/test.go 44.44% <0.00%> (ø)
cmd/skaffold/app/exitcode.go 100.00% <ø> (+6.66%) ⬆️
cmd/skaffold/skaffold.go 0.00% <0.00%> (ø)
cmd/skaffold/app/cmd/inspect_tests.go 62.50% <14.28%> (-1.14%) ⬇️
cmd/skaffold/app/cmd/render.go 35.48% <18.18%> (-5.90%) ⬇️
cmd/skaffold/app/cmd/lsp.go 28.12% <28.12%> (ø)
cmd/skaffold/app/cmd/run.go 64.28% <33.33%> (-9.63%) ⬇️
cmd/skaffold/app/cmd/fix.go 56.41% <37.50%> (-20.07%) ⬇️
... and 393 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@bcmills
Copy link
Contributor Author

bcmills commented Nov 8, 2022

I think your codecov tool is broken: this PR makes no changes to the actual Go code in use, so the coverage delta should be 0%, not -4% — that seems like an awfully large noise floor. 😅

Copy link
Contributor

@aaron-prindle aaron-prindle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for this, I have created #8094 to track the suggested Follow-up Work. We will be more tactful in how we use excludes + requires going forward.

@aaron-prindle aaron-prindle merged commit 2e314a5 into GoogleContainerTools:main Nov 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants