Conversation
jandubois
force-pushed
the
yqlib-without-hcl
branch
3 times, most recently
from
50cfa9a to
6952eb4
Compare
Bumps [github.com/mikefarah/yq/v4](https://github.com/mikefarah/yq) from 4.49.2 to 4.50.1. - [Release notes](https://github.com/mikefarah/yq/releases) - [Changelog](https://github.com/mikefarah/yq/blob/master/release_notes.txt) - [Commits](mikefarah/yq@v4.49.2...v4.50.1) Signed-off-by: Jan Dubois <jan.dubois@suse.com> --- updated-dependencies: - dependency-name: github.com/mikefarah/yq/v4 dependency-version: 4.50.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
jandubois
force-pushed
the
yqlib-without-hcl
branch
6 times, most recently
from
42be709 to
2353736
Compare
The latest version of yqlib depends on the hashicorp/hcl module, which in turn depends on apparentlymart/go-textseg. That one has a custom license and is therefore not approved for use by CNCF projects. yqlib already supports the `yq_nohcl` tag to build without HCL support. Unfortunately the go build system is not tag-aware and always includes all indirect dependencies in go.mod/go.sum. This commit stubs out the HCL dependencies, so they will not be fetched, and unconditionally adds the `yq_nohcl` build tag. Any downstream project will have to do the same, as the `replace` directives in go.mod only apply to this repo and are not inherited via the Go build system. Signed-off-by: Jan Dubois <jan.dubois@suse.com>
jandubois
force-pushed
the
yqlib-without-hcl
branch
from
2353736 to
7aa1896
Compare
|
The BATS test fails because of mikefarah/yq#2572. I have not checked why the other integration tests failed. |
I have not tested this, but we probably should move the stubs from |
|
|
||
| // Avoid pulling in the real HCL module, which depends on github.com/apparentlymart/go-textseg/v15 | ||
| // which uses a nonstandard license and therefore cannot be used by CNCF projects. | ||
| replace github.com/hashicorp/hcl/v2 => ./internal/hclstub |
There was a problem hiding this comment.
Thanks, but not a fan of this complication.
Can we just ask CNCF to permit using HCL? That will help other CNCF projects too.
There was a problem hiding this comment.
Can we just ask CNCF to permit using HCL? That will help other CNCF projects too.
Maybe, but I'm not optimistic. The problem is not HCL but github.com/apparentlymart/go-textseg, which has 3 different licenses for different pieces, none of which have been approved.
Can you open a ticket with CNCF about that?
Thanks, but not a fan of this complication.
Me neither, but what is the alternative (assuming we don't get CNCF to approve the license)? Vendoring all of yqlib and manually removing the HCL dependency? That seems even worse that creating the stubs because we will no longer get dependabot notifications for updates, and there will be manual effort every time we bump yqlib.
This is really the best I can think of.
There was a problem hiding this comment.
an alternative would be to just execute yq binary
There was a problem hiding this comment.
You want to make an external installation of yq a requirement for each --yq option? And then bundle it in CIDATA for use by the guestagent? That is so much more complex than adding a few stub modules to work around a limitation of the Go dependency resolution.
There was a problem hiding this comment.
Can you open a ticket with CNCF about that?
You want to make an external installation of yq a requirement for each --yq option? And then bundle it in CIDATA for use by the guestagent?
Not ideal. Let's see how CNCF handles the request.
There was a problem hiding this comment.
One of the reasons I hesitate to accept replace() is that my gosocialcheck linter (not integrated to CI yet) does not support replace() yet:
There might be other tools that do not work well with replace() too.
There was a problem hiding this comment.
go-licenses doesn't work with it either. The workaround was to run go mod vendor and then run GOFLAGS="-mod=vendor" go-licenses check ... (see the change in this PR).
Would that work for gosocialcheck too?
On closer inspection this does not look like a bug in I've created #4539 to adjust our BATS test to the new behaviour.
I believe they are just flaky CI. There is no point in re-running because we are still waiting for a license exception for hcl/v2 from CNCF. |
2 participants
The latest version of
yqlibdepends on thehashicorp/hclmodule, which in turn depends onapparentlymart/go-textseg. That one has a custom license and is therefore not approved for use by CNCF projects.yqlibalready supports theyq_nohcltag to build without HCL support. Unfortunately the go build system is not tag-aware and always includes all indirect dependencies ingo.mod/go.sum.This commit stubs out the HCL dependencies, so they will not be fetched, and unconditionally adds the
yq_nohclbuild tag.Any downstream project will have to do the same, as the
replacedirectives ingo.modonly apply to this repo and are not inherited via the Go build system.This PR addresses the concerns in #4460 (review).