1. PyPA
  2. Python Packaging Authority Projects
  3. PyPI Metadata Formats
  4. Issues
Issue #31 wontfix

Allow build tags in PEP440

Donald Stufft
created an issue

PEP440 currently has no concept of build tags, however the Wheel format does. It would be better to move this into PEP440 though I think, and would allow a better mapping between PEP440 and semver.

Comments (12)

  1. Nick Coghlan

    Currently tackling this in the next draft by making a distinction between using a local version identifier in source distributions and in binary distributions. That way we have:

    • source label for exactly what the original source code was
    • local version identifier to capture additional patches and build details
  2. Nick Coghlan

    Avoiding unnecessary multiplication of concepts basically. We already have public version identifiers, local version labels and source labels. Do we need build tags as a distinct concept, or are the others already sufficient?

  3. Nick Coghlan

    The main argument in favour of splitting them is that the wishy-washy "yes to local version identifiers on binary distributions, no on source distributions" in the latest draft could go away. Instead it would become:

    • build tags are OK on public index servers
    • local version identifiers are not OK on public index servers

    The question then would be whether we can just kill the "source label" concept and say "use an appropriate build tag on the source distribution instead"

  4. Nick Coghlan

    OK, as I started trying to write up the above approach, I remembered why I don't like the idea of having build tags directly in the main metadata definition and went with the original "source label" option instead: the metadata for a built binary distribution should be identical to that for the corresponding source distribution. If you include the "build tag" directly in the version, that's problematic - you're going to want more details in a binary build tag than you have in a source label.

  5. Nick Coghlan

    So I think I'm happy enough with the compromise in the current text - no build tags for public source distributions (but a relatively free form source label field), and local version identifiers permitted for public binary distributions (which also allows build tags as part of the local version identifier).

    The change then would be for the next version of the wheel spec to take the "build tag" portion and map that to the "local version label".

  6. Nick Coghlan

    Just pushed some tweaked wording. Still not entirely happy with it, since either way, we end up with a situation where the source distribution and associated binary distributions may have different metadata. What we may actually be exposing here is that every built (or installed) distribution should have a "built version" field, leaving the "version" field in the main metadata to always be the "source version".

    Under that view, we would rename "pydist.json" as "pysource.json", and then have a separate "pybuilt.json" for the metadata that may be build specific.

  7. Nick Coghlan

    Actually, I think I'll do just the pydist.json -> pysource.json rename to make it clear that this all source metadata that should be available in the sdist, and preserved in the built binary distributions.

  8. Nick Coghlan

    See issue #34 for the related notion of including pybuilt.json as a separate metadata file only included after "building" the package for a particular environment (whether in advance or during installation).

  9. Nick Coghlan

    I think I'd still like to hold off on this for the time being. It doesn't feel like something that needs to be in the Python level version metadata, and could instead be transported in a "python.build" metadata extension or similar. I'll keep thinking about it, though.

  10. Log in to comment