link: error when multiple packages have same package path #1374
Comments
jayconrod
changed the title
Yannic
added a commit
to Yannic/rules_go
that referenced
this issue
May 13, 2020
…path This change adds a flag to the link-tool to error if a go-package is provided by more than one library. Works towards bazel-contrib#1374
Yannic
added a commit
to Yannic/rules_go
that referenced
this issue
May 13, 2020
…path This change adds a flag to the link-tool to error if a go-package is provided by more than one library. Works towards bazel-contrib#1374
Yannic
added a commit
to Yannic/rules_go
that referenced
this issue
May 13, 2020
…path This change adds a flag to the link-tool to error if a go-package is provided by more than one library. Works towards bazel-contrib#1374
|
@Yannic has started working on this, and it's probably time to take steps toward making this a hard error. In v0.24, this should be an opt-in setting. I think it should be activated using a new flag, In v0.25, the flag may be removed, and this will always be an error. |
jayconrod
pushed a commit
to jayconrod/rules_go
that referenced
this issue
Jul 1, 2020
In general, packages should be compiled with the same dependencies they're linked against. We haven't been too strict about this in the past, and there are two common situations where this might not happen: 1) go_proto_library and go_library targets are linked for the same package, 2) an external test imports a library that imports the package being tested. Analysis will now detect both problems and will pass a descriptive message to the GoLink action. Making this a hard error would be an incompatible change, so for now, it will be reported if the incompatible_package_conflict_is_error setting is enabled (bazel-contrib#1374) or if the linker fails. Fixes bazel-contrib#1877 Updates bazel-contrib#1374 Updates bazel-contrib#2535
jayconrod
pushed a commit
that referenced
this issue
Jul 6, 2020
…2553) In general, packages should be compiled with the same dependencies they're linked against. We haven't been too strict about this in the past, and there are two common situations where this might not happen: 1) go_proto_library and go_library targets are linked for the same package, 2) an external test imports a library that imports the package being tested. Analysis will now detect both problems and will pass a descriptive message to the GoLink action. Making this a hard error would be an incompatible change, so for now, it will be reported if the incompatible_package_conflict_is_error setting is enabled (#1374) or if the linker fails. Fixes #1877 Updates #1374 Updates #2535
jayconrod
pushed a commit
that referenced
this issue
Jul 8, 2020
…2553) In general, packages should be compiled with the same dependencies they're linked against. We haven't been too strict about this in the past, and there are two common situations where this might not happen: 1) go_proto_library and go_library targets are linked for the same package, 2) an external test imports a library that imports the package being tested. Analysis will now detect both problems and will pass a descriptive message to the GoLink action. Making this a hard error would be an incompatible change, so for now, it will be reported if the incompatible_package_conflict_is_error setting is enabled (#1374) or if the linker fails. Fixes #1877 Updates #1374 Updates #2535
jayconrod
pushed a commit
that referenced
this issue
Jul 8, 2020
…2553) In general, packages should be compiled with the same dependencies they're linked against. We haven't been too strict about this in the past, and there are two common situations where this might not happen: 1) go_proto_library and go_library targets are linked for the same package, 2) an external test imports a library that imports the package being tested. Analysis will now detect both problems and will pass a descriptive message to the GoLink action. Making this a hard error would be an incompatible change, so for now, it will be reported if the incompatible_package_conflict_is_error setting is enabled (#1374) or if the linker fails. Fixes #1877 Updates #1374 Updates #2535
|
Moving to v0.25 milestone since the v0.24 work is done. In v0.25, we should flip the flag to be on by default. |
jayconrod
pushed a commit
to jayconrod/rules_go
that referenced
this issue
Nov 19, 2020
We've promised to do this for more than two years, and the time has finally come. If more than one copy of a package with the same package path is provided to the linker, the GoLink action now reports an error. Distinct packages (for example, from multiple vendor directories) may be disambiguated with the importmap attribute. Fixes bazel-contrib#1374
jayconrod
pushed a commit
that referenced
this issue
Nov 19, 2020
We've promised to do this for more than two years, and the time has finally come. If more than one copy of a package with the same package path is provided to the linker, the GoLink action now reports an error. Distinct packages (for example, from multiple vendor directories) may be disambiguated with the importmap attribute. Fixes #1374
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a binary includes multiple packages with the same package path (set with
importmap), rules_go should report an error.Gazelle automatically sets
importmapin vendoredgo_libraryrules, which should eliminate most of these problems. rules_go 0.11 should print a warning when this happens. 0.12 should make it an error.The text was updated successfully, but these errors were encountered: