Skip to content

Support pre-release python versions for python-build-standalone toolchains #2837

Description

@rickeylev

Jax (among others) likes to use Python runtimes from python-build-standalone that are pre-release versions to help verify upcoming behavior and try out new Python features. e.g. right now, they carry a patch to map 3.14 to 3.14.0a6.

The underlying versions.bzl file doesn't support pre-release versions, though, so they patch 3.14.0 to point to a 3.14.0a6 URL. This works, but it's a bit misleading. It's also problematic if one wanted to have configuration for two versions at once, differentiated by their pre-release version.

(Using patches isn't ideal, but I think they're using an older version that doesn't yet have the TOOL_VERSIONS arg/override -- regardless, the same issues are present).

While #2081 would also address this, I figured a more specific feature request is warranted (this is more narrowly scoped and well defined than 2081).

In any case, the desired outcome should be:

  • A user can set --python_version=3.14.0.a6 on the command line, and have the appropriate runtime used
  • A user can have more than one pre-release configured in e.g. TOOL_VERSIONS

This should be fairly easy to implement and test:

  • Use py_reconfig_test to set the python_version and customize toolchains
  • Have the test assert sys.version
  • Start fixing the errors and misbehaviors that ensue.

cc @kanglant

Activity

  1. aignas commented on Apr 29, 2025

    @aignas
    Collaborator

    Can we limit this support only to bzlmod or do we need to support WORKSPACE as well?

  2. added theissue type on Apr 29, 2025
  3. rickeylev commented on Apr 29, 2025

    @rickeylev
    CollaboratorAuthor

    It can definitely start with bzlmod.

    After skimming the code, also adding workspace may not be that hard -- when py_freethreaded got added, the TOOL_VERSIONS structs have some extra fields to carry more arbitrary config settings. So there's a least a place to put those right now. Users might actually be able to set those themselves via python_register_toolchains ?

    pypi integration is the other big half. I don't think that handles below minor versions? That part might have to wait until deps-selection is moved to analysis phase. And possibly sdist building is moved to build phase. Not sure.

  4. aignas commented on Apr 29, 2025

    @aignas
    Collaborator

    PyPI integration now handles the full version (X.Y.Z, but supporting rc versions might be doable, we should just get it from the interpreter itself).

  5. aignas commented on May 15, 2025

    @aignas
    Collaborator

    #2874 should help with making our code much more robust at parsing versions the users provide. Attempting to register multiple pre-release versions should be doable as well. If it is not, I am happy to mentor someone to help implementing the remaining of the changes needed for this feature.

  6. added a commit that references this issue on Jun 12, 2025
    9b8f650
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type: toolchainRelated to the toolchains provided by rules_python

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions