Allow customizing generation of tags

[pradyunsg]

Coming from pypa/pip#6908

pip's current get_supported function for generating PEP 425 tags, has the following signature:

def get_supported(
    versions=None,  # type: Optional[List[str]]
    noarch=False,  # type: bool
    platform=None,  # type: Optional[str]
    impl=None,  # type: Optional[str]
    abi=None  # type: Optional[str]
):

It takes details/strings about the specific platform, implementation, ABI and interpreter versions. It also has a flag to avoid generating architecture specific tags.

packaging.tags would need to have feature parity with this interface, to be used within pip.

[brettcannon]

This is mostly as notes for myself, but:

• impl + versions is interpreter
• abi is abi 😄
• I would assume platform is platform
• But what is noarch for? And why isn't it a way to specify the CPU architecture instead of a boolean?

[di]

@brettcannon I started to attempt this to include in #213 but I don't have enough familiarity with either codebase. Did you have a rough plan here? I see you unassigned yourself, are you not able to implement this? Should I just dig in deeper? @pradyunsg maybe this would make more sense to you?

[brettcannon]

I just unassigned in case someone beat me to it is all. It's on my todo list so I will definitely attempt to tackle it soon-ish (I'm trying to get through my 'packaging' stuff ATM and so this should bubble up shortly).

[brettcannon]

It looks like noarch is used to simply skip over any ABI or platforms and only go with the generic none and any, respectively.

[brettcannon]

I'll also mention that this has to land before our next release as warn has been added as an argument to sys_tags() and as long as we support Python 2.7 we can't control API expansion via keyword-only arguments. So we need to stabilize our API for sys_tags() before the public starts to rely on positional arguments.

[brettcannon]

Searching through the pip source code via GitHub only turns up the following call site for a place where arguments are specified:

https://github.com/pypa/pip/blob/e6f69fadd8c84526d933b2650141193595059e72/src/pip/_internal/models/target_python.py#L98-L103

That would suggest that noarch isn't necessary.

[brettcannon]

@pradyunsg @di if sys_tags() grew interpreters, abis, and platforms that all took Iterable[String] to override the system discovery would that be good enough?

The problem I have with get_supported() as-is in pep425tags is it is treating its arguments like hints and then tries to back-fill extra values. That feels brittle to me as it starts to add reliance on the format of what people provide to the code. Plus not everyone may want that back-fill for some reason.

Basically my question is how much must packaging.tags take on in terms of this logic versus having pip manage it for the one place it uses it? If this must be here then I would argue to have separate APIs for attempting to back-fill and keep sys_tags() simple.

[di]

@brettcannon I think that's reasonable, and that's also the conclusion I came to when starting to look at this. The only real hitch there is that pep425tags has impl + versions where we have interpreter here. So if @pypa/pip-committers are willing to accept this as an internal API change (along with warn) then I think that's what we should do.

[pradyunsg]

separate APIs for attempting to back-fill and keep sys_tags() simple.

Sounds fair. I feel that this would be a lot easier to reason about on both sides (packaging.tags and pip).

[pradyunsg]

this has to land before our next release

Hmm... With current master, yes.

I'm OK to add a docstring that says warn should be specified via keyword only and set the expectation that more arguments may be added, especially if this is a blocking concern IMO. Or even to take **kwargs and handle it for these optional arguments (we're not directly using the call-signature via autodoc for Sphinx, so we can use the keyword only notation there).

That said, it seems like we might be going down the path of creating a separate API for pip's "flexible" way of tag generation which makes this suggestion kinda moot. 🙃

[brettcannon]

I think it depends on what we want sys_tags() to be and what overall API we want to provide. Maybe it would be better to expose more of the private functions that generate things like the interpreter, ABI, and platform tags and then allow folks to construct the ordered list themselves? That would leave sys_tags() as a convenience function for those who aren't calculating wheels for a different installation than the one they are on.

And as for the comment from @di , I was thinking about this last night and came to a similar conclusion that python version would probably be necessary as well.

And doing the old **kwargs trick so we don't have to hold up the release or to start with keyword-only for warn is fine by me.