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

Utility functions to compose file distribution names #408

Open
e2thenegpii opened this issue Mar 5, 2021 · 12 comments · May be fixed by #409
Open

Utility functions to compose file distribution names #408

e2thenegpii opened this issue Mar 5, 2021 · 12 comments · May be fixed by #409

Comments

@e2thenegpii
Copy link

Is there interest in a pull request for functions that perform the inverse operation of packaging.utils.parse_wheel_filename and parse_sdist_filename?

It seems like an omission that there is no function such that x == compose_wheel_filename(*parse_wheel_filename(x))

@brettcannon
Copy link
Member

brettcannon commented Mar 5, 2021

Not so much an omission as no one has shown a need yet and we prefer to only add support for things people have demonstrable need for instead of guessing. E.g. f the wheel project told us they could use such a thing, though, we would consider adding it.

@brettcannon brettcannon changed the title composing distribution names compose file distribution names Mar 5, 2021
@brettcannon brettcannon changed the title compose file distribution names Utility functions to compose file distribution names Mar 5, 2021
@uranusjr
Copy link
Member

uranusjr commented Mar 5, 2021

Also other PEP 517 backend authors since they would have need for it.

@MrMino
Copy link
Contributor

MrMino commented Mar 5, 2021

I have somewhat of a need for it in my project, so I can PR this if you're willing to accept it.

@brettcannon
Copy link
Member

@MrMino can I ask why it's only "somewhat"? If you have an actual need then we will totally look at a PR, but I would rather avoid speculative code.

@pradyunsg
Copy link
Member

Isn't it going to be just "-".join(...) + extension?

Does this really need to be a function here?

@MrMino
Copy link
Contributor

MrMino commented Mar 5, 2021

@brettcannon Well, I'm doing it inside wheelfile. It isn't a big deal at all, I just feel like it would be elegant to have it. I haven't utilized parse_wheel_filename there yet, but I'm planning on doing it.

@pradyunsg technically parse_wheel_filename returns Version and a set of tags, so you have to cast it properly, then there's also the kink in handling the build number.

@brettcannon
Copy link
Member

It's a little more complicated than that due to tag sets. If we added a function to construct that part of the wheel file name then you might as well just skip having that as a separate function (since I don't think it would be that useful on its own) and go as far as constructing the wheel file name entirely.

As an example, this is untested code written for Python 3.9:

import operator

def _compress_wheel_tags(tags: AbstractSet[Tag], attr: str) -> str:
    tag_portions = []
    for attr in "interpreter", "abi", "platform":
        parts = map(operator.attrgetter(attr), tags)
        compressed = ".".join(sorted(parts))
        tag_portions.append(compressed)
    return "-".join(tag_portions)


def create_wheel_filename(project: NormalizedName, version: Version, build: BuildTag | None, tags: AbstractSet[Tag]) -> str:
    compressed_tag = _compress_wheel_tags(tags)
    if build:
        parts = project, version, build, compressed_tag
    else:
        parts = project, version, compressed_tag
    return "-".join(map(str, parts)) + ".whl"

@uranusjr
Copy link
Member

uranusjr commented Mar 5, 2021

If I were to ask for such a function (I am not), I would want name and version normalisation, ensuring components don’t contain -, things like that.

@brettcannon
Copy link
Member

brettcannon commented Mar 5, 2021

@MrMino fair enough! If you would use it if we provided it then I'm okay with adding the function.

@uranusjr I would flat-out dictate via typing that stuff had to be normalized. But I'm also okay forcibly normalizing if people would rather do that.

@brettcannon
Copy link
Member

FYI there is a PR for this, but I think we need to resolve PEP 625 first.

@brettcannon
Copy link
Member

FYI https://peps.python.org/pep-0625/ has been accepted!

@e2thenegpii
Copy link
Author

I've resoled the merge conflicts in the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants