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.

Sign up for GitHub

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

Jump to bottom

Failure to generate a JVM lockfile if a jvm_artifact uses the jar field #15218

Closed
stuhood opened this issue Apr 21, 2022 · 1 comment · Fixed by #15219
Closed

Failure to generate a JVM lockfile if a jvm_artifact uses the jar field #15218

stuhood opened this issue Apr 21, 2022 · 1 comment · Fixed by #15219
Assignees
@stuhood
Labels
bug
Milestone
2.10.x

Comments

@stuhood
Copy link
Member

stuhood commented Apr 21, 2022

Describe the bug
When a jvm_artifact target has a jar field, we will fail to generate a lockfile for the relevant resolve(s) with:

  File "$HOME/.cache/pants/setup/bootstrap-Darwin-x86_64/2.11.0rc3_py39/lib/python3.9/site-packages/pants/jvm/goals/lockfile.py", line 149, in <genexpr>
    artifacts=ArtifactRequirements(sorted(resolve_to_artifacts.get(resolve, ()))),
  File "<string>", line 4, in __lt__
TypeError: '<' not supported between instances of 'JvmArtifactJarSourceField' and 'JvmArtifactJarSourceField'

Pants version
The stack is for 2.11.0rc3, but this issue also exists in 2.10.0.
@stuhood stuhood added this to the 2.10.x milestone Apr 21, 2022
@stuhood stuhood self-assigned this Apr 21, 2022
@stuhood stuhood mentioned this issue Apr 21, 2022
Merged
@Eric-Arellano
Copy link
Contributor

This might be similar to #15121, which is an issue because ofhttps://github.com//issues/14719. Given that we need to cherry pick, it's probably better to go for the fast win rather than 14719

@stuhood stuhood mentioned this issue Apr 21, 2022
Merged
stuhood added a commit that referenced this issue Apr 22, 2022
@stuhood
Fix lockfile generation for duplicate jvm_artifact targets with `ja…
a858a62 
…r` fields. (#15219)

#15218 demonstrates a fairly obscure issue where a mostly-duplicated `jvm_artifact` target which defined a `jar` field would find that the first few fields in an `ArtifactRequirement` were equal before attempting to compare a `JvmArtifactJarSourceField` field, which would fail.

Rather than sorting `ArtifactRequirement` instances, we can instead ensure that the input targets are sorted.

Fixes #15218.
@stuhood stuhood mentioned this issue Apr 22, 2022
Merged
stuhood added a commit to stuhood/pants that referenced this issue Apr 22, 2022
@stuhood
Fix lockfile generation for duplicate jvm_artifact targets with `ja…
8bf1cf6 
…r` fields. (pantsbuild#15219)

pantsbuild#15218 demonstrates a fairly obscure issue where a mostly-duplicated `jvm_artifact` target which defined a `jar` field would find that the first few fields in an `ArtifactRequirement` were equal before attempting to compare a `JvmArtifactJarSourceField` field, which would fail.

Rather than sorting `ArtifactRequirement` instances, we can instead ensure that the input targets are sorted.

Fixes pantsbuild#15218.
# Rust tests and lints will be skipped. Delete if not intended.
[ci skip-rust]

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
@stuhood stuhood mentioned this issue Apr 22, 2022
Merged
stuhood added a commit to stuhood/pants that referenced this issue Apr 22, 2022
@stuhood
Fix lockfile generation for duplicate jvm_artifact targets with `ja…
1922254 
…r` fields. (pantsbuild#15219)

Rather than sorting `ArtifactRequirement` instances, we can instead ensure that the input targets are sorted.

Fixes pantsbuild#15218.

[ci skip-rust]

[ci skip-build-wheels]
stuhood added a commit that referenced this issue Apr 22, 2022
@stuhood
Fix lockfile generation for duplicate jvm_artifact targets with `ja…
583f23f 
…r` fields. (Cherry-pick of #15219) (#15230)

#15218 demonstrates a fairly obscure issue where a mostly-duplicated `jvm_artifact` target which defined a `jar` field would find that the first few fields in an `ArtifactRequirement` were equal before attempting to compare a `JvmArtifactJarSourceField` field, which would fail.

Rather than sorting `ArtifactRequirement` instances, we can instead ensure that the input targets are sorted.

Fixes #15218.
stuhood added a commit that referenced this issue Apr 22, 2022
@stuhood
Fix lockfile generation for duplicate jvm_artifact targets with `ja…
56636db 
…r` fields. (Cherry-pick of #15219) (#15232)

#15218 demonstrates a fairly obscure issue where a mostly-duplicated `jvm_artifact` target which defined a `jar` field would find that the first few fields in an `ArtifactRequirement` were equal before attempting to compare a `JvmArtifactJarSourceField` field, which would fail.

Rather than sorting `ArtifactRequirement` instances, we can instead ensure that the input targets are sorted.

Fixes #15218.

[ci skip-rust]

[ci skip-build-wheels]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@stuhood stuhood

Labels
bug
Projects
None yet
Milestone
2.10.x
Development

Successfully merging a pull request may close this issue.

Fix lockfile generation for duplicate jvm_artifact targets with jar fields. stuhood/pants
2 participants
@stuhood @Eric-Arellano