-
Notifications
You must be signed in to change notification settings - Fork 252
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
It's not obvious how to construct a set of compatible tags for a system #333
Comments
You've gotta do what pip does -- call the relevant sub-functions with the corresponding optional arguments "populated": Any arguments that are not specified take a "reasonable default" (like IMO pip's code is not that complicated -- everything above line 140 is "process a value (or default) to respect pip's CLI-design-and-legacy-behavior" and everything beyond that is "call the relevant packaging.tags functions with 100% overrides". |
FWIW, once you start passing in the platform to any of the |
Note that pip's defaults give a different value than I am inclined to think that the docs could do with some extra work, though, to clarify that this is the intended use of the lower level parts. I'm happy to work up a documentation patch, and then we can debate whether it's "too complicated" and would benefit from some helper functions 😉. To be honest, though, I don't really see any point in exposing the lower-level functions except to implement something like pip's behaviour. Is there a good reason why we don't include (an equivalent of) pip's |
Those are all questions that @brettcannon is in a much better position to answer than me. :) |
There's a couple of things to unpack here. One, "can we document how to build tags with the current API?" No, because the API is specifically limited to not allow for that. 😉 The initial reason was no one asked for that level of granularity, so in the spirit of "it's easier to add than remove", it was left out. But it also isn't all there because constructing the tags appropriately to be compatible across tools based on the priority order of tags is really convoluted. There's weird historical things and such which make explaining it a right pain and easy to get wrong (hence why Two, "why do we have some functions in the API?" Because those using Three, "why is |
Thanks for the reply @brettcannon. I'll take the points in reverse order, because that gets the easier one out of the way first 🙂 With regard to (3), arguably pip should remove it as well. I'll take that up over there. It looks like pip calls Regarding (1) and (2), that's a fair point. I'd happily only use I'd suggest maybe clarifying in the docs that |
|
|
I just submitted #334 |
... and now that's merged. 😄 Was there something else you wanted to discuss in this issue, @pfmoore , or should we close this issue? |
Everything else is covered, thanks. The point about |
The
packaging.tags
module exposes a number of functions, but it's not particularly obvious how to construct a list of supported tags for a given system from them (other than the current interpreter).Pip uses a complicated algorithm (see here) to build the tags. The default result doesn't seem to always match
packaging.tags.sys_tags()
- on my system (Windows 10 64-bit, Python 3.8)pip debug -v
includescp38-none-any
, butsys_tags()
does not. And the process for building tags for a different system seems very complex, and there's no indication in thepackaging.tags
documentation that it's the intended or correct approach.I understand that in some situations (notably manylinux) it's not possible to determine the correct supported tags from "outside" the system. But as things stand it's not at all clear how to correctly use any of the functions exposed here apart from
parse_tag()
andsys_tags()
.(Background: I'm trying to implement a module that replicates pip's "package finder" logic, and that needs to allow the user to specify the platform, etc, to find packages for).
The text was updated successfully, but these errors were encountered: