fix: Use Bazel's built-in zstd support in _python_repository_impl.

[jiawen]

Bazel has built-in support for zstd since 5.1. This simplifies the logic and makes python_repository work on systems where building from source fails.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jiawen]

Thanks @f0rmiga! I'll obviously make CI pass before asking to merge.

[rickeylev]

Can you please sync to head and resolve the merge conflicts?

CI also reports there are failures, something relating to setting file permissions for a directory that doesn't exist? They failed even after retrying, so they're likely legit.

[chrislovecnm]

@jiawen im going to mark this as a draft. When you have this passing CI please take it out of draft.

[jiawen]

My apologies - my day job got in the way. Draft sounds good - looks like I have some fun chmod issues to resolve.

[jiawen]

Argh, this PR uncovered some grungy indygreg packaging details. The existing code works because:

• The .tar.gz files are all -install_only, so the contents are ["python/bin", "python/include", "python/lib", and "python/share"].
• But the zst versions are "full". The contents are:
  • ["python/build/lib", "python/build/Modules", ...] (a couple of others)
  • ["python/install/bin", "python/install/include", "python/install/lib", and "python/install/share"]
  • (A few other files and dirs)

So the existing code happens to work because:

• It uses rctx.download_and_extract in the .tar.gz case, which unpacks python/lib into the right place.
• The zstd path uses tar --strip-components=2, which also unpacks the contents two levels deep into the right place. But interestingly, it relies on tar's behavior to merge the two lib directories together. It's obviously possible to do this with rctx.execute(["cp -R ...", ]) but this is somewhat irritating.

@rickeylev Any suggestions?

[aignas]

FYI, the .tar.gz files were created due to astral-sh/python-build-standalone#79 if I remember correctly.

[rickeylev]

Perhaps the strip_prefix arg or rename_files arg of downloaded_and_extract? I don't really have ideas otherwise.

If a separate command has to be run after download_and_extract to merge the two directories, I'm not sure it'll be a net win. Maybe cp --link?

This ... makes python_repository work on systems where building from source fails.

I don't follow -- how does this PR fix building from source? This PR basically removes the need to have the zstd and tar tools locally available. What does that have to do with building from source?

[github-actions]

This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!

[github-actions]

This PR was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"