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

The ability to use x in place of * in wildcard specifications, undocumented feature or a bug? #5990

Closed
2 tasks done
pavera opened this issue Jul 11, 2022 · 5 comments · Fixed by python-poetry/poetry-core#770
Milestone

Comments

@pavera
Copy link

pavera commented Jul 11, 2022

I've noticed that I can use the letter x in place of * in wildcard version specifications. Is this expected? If it is expected, should it be documented clearly?

  • I have searched the issues of this repo and believe that this is not a duplicate.
  • I have searched the documentation and believe that my question is not covered.

Issue

I've been playing around with version contraints and via copy/paste ended up with a requests = "2.x" specification in my pyproject.toml file. I was surprised to see this work, and even more surprised that it appears to be case insensitive and function just like * though using x or X is not documented in the wildcard section of https://python-poetry.org/docs/dependency-specification/

I believe this "support" comes from the regex X_CONSTRAINT in https://github.com/python-poetry/poetry-core/blob/main/src/poetry/core/semver/patterns.py but I haven't fully traced where this behavior comes from. Basically I just want to know if this is actually a supported feature that needs documentation, or if its a "happy accident" somehow?

@dimbleby
Copy link
Contributor

This was clearly deliberate, I'd agree that it's a weird choice.

Hard to remove such things once they're released because who knows what's relying on it. If this bothers you enough to submit an MR removing it, then that would be a sensible way to kick off the discussion.

@pavera
Copy link
Author

pavera commented Jul 12, 2022

Doesn't bother me one way or the other, I would rather open an MR adding at least a mention of this to the docs if its intended behavior. Unless the team is trying to deprecate/remove the behavior quietly? Totally understand the difficulty in removing features though...

@dimbleby
Copy link
Contributor

I've not heard that anyone is thinking about it at all. I'd think that it makes more sense to remove it than to document it.

Anyway I don't see why anyone would choose today to rely on this rather than writing their version constraints the usual way.

@mkniewallner
Copy link
Member

I lack a bit of background about why support for x and X was added, but yeah, IMO this is not something we want to keep (which is also why it's undocumented).

If we do confirm that it's unsupported, entirely removing it in a major/minor release post-1.2 may be a good idea.

Copy link

github-actions bot commented Nov 6, 2024

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants