-
-
Notifications
You must be signed in to change notification settings - Fork 646
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
Requesting AllTargets
in a plugin fails if an entry in [python.resolves]
points to a nonexistent file
#18933
Comments
Hrmmm although - it looks like that
I still get the |
This also seems to bite |
kaos
added a commit
to kaos/pants
that referenced
this issue
May 8, 2023
Fixes pantsbuild#18933 (and pantsbuild#18404). Original attempt at fixing this but failed was in pantsbuild#18406 due to an oversight that it was the `_lockfiles` target generator with a `sources` field that was being synthesized, not the `_lockfile` target with a single `source` file only. Either use should work equally well, and now they do.
kaos
added a commit
that referenced
this issue
May 9, 2023
Fixes #18933 (and #18404). Original attempt at fixing this but failed was in #18406 due to an oversight that it was the `_lockfiles` target generator with a `sources` field that was being synthesized, not the `_lockfile` target with a single `source` file only. Either use should work equally well, and now they do.
kaos
added a commit
to kaos/pants
that referenced
this issue
May 9, 2023
Fixes pantsbuild#18933 (and pantsbuild#18404). Original attempt at fixing this but failed was in pantsbuild#18406 due to an oversight that it was the `_lockfiles` target generator with a `sources` field that was being synthesized, not the `_lockfile` target with a single `source` file only. Either use should work equally well, and now they do.
kaos
added a commit
to kaos/pants
that referenced
this issue
May 9, 2023
Fixes pantsbuild#18933 (and pantsbuild#18404). Original attempt at fixing this but failed was in pantsbuild#18406 due to an oversight that it was the `_lockfiles` target generator with a `sources` field that was being synthesized, not the `_lockfile` target with a single `source` file only. Either use should work equally well, and now they do.
kaos
added a commit
that referenced
this issue
May 9, 2023
Fixes #18933 (and #18404). Original attempt at fixing this but failed was in #18406 due to an oversight that it was the `_lockfiles` target generator with a `sources` field that was being synthesized, not the `_lockfile` target with a single `source` file only. Either use should work equally well, and now they do.
kaos
added a commit
that referenced
this issue
May 9, 2023
Fixes #18933 (and #18404). Original attempt at fixing this but failed was in #18406 due to an oversight that it was the `_lockfiles` target generator with a `sources` field that was being synthesized, not the `_lockfile` target with a single `source` file only. Either use should work equally well, and now they do.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
In one of our in-repo plugins, we request:
This typically works fine, but if I add a new
[python.resolves]
entry:Then the goal logic explodes with:
Pants version
PANTS_SHA=06aaef7f21092a7bd76ba157cd221266b8444653
(on the 2.16.x branch)OS
MacOS but would presumably see it on Linux too if I pushed my branch to CI.
Additional info
I believe the error is happening because the rule that provides
AllTargets
here wraps around:RawSpecsWithoutFileOwners
has anunmatched_glob_behavior
field here that defaults toGlobMatchErrorBehavior.error
.The text was updated successfully, but these errors were encountered: