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.

Sign up for GitHub

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

Jump to bottom

Injecting a python version when building source distributions #407

Closed
konstin opened this issue Nov 13, 2023 · 3 comments · Fixed by #532
Closed

Injecting a python version when building source distributions #407

konstin opened this issue Nov 13, 2023 · 3 comments · Fixed by #532
Assignees
@charliermarsh
Labels
bug Something isn't working
Milestone
Initial feature c...

Comments

@konstin
Copy link
Member

konstin commented Nov 13, 2023

When resolving packages, we allow setting a python version that is not the one in the current venv when resolving, e.g. target/debug/puffin pip-compile --python-version py39. We will select everything as if we were on that python version. This however doesn't really work anymore when building source distribution because a PEP 517 (and setup.py too) need a sys.executable that will necessarily be the local version.

Possible options:

  • Build the source distribution with the real python version, pick the wheel with the local python version tag (even if it mismatches the faked environment), assume that wheels built for different python versions have the same metadata (this is a somewhat necessary assumption anyway, without it a sane reusable resolution becomes all but impossible). We would keep two environments around, the main fake one and the secondary real one.
  • Provision the fake python from python-build-standalone for builds, making it a real python.
  • Ban source distribution builds when --python-version is set.
@konstin konstin mentioned this issue Nov 13, 2023
Merged
@charliermarsh
Copy link
Member

I think I want Option (1).

@charliermarsh charliermarsh added the bug Something isn't working label Nov 13, 2023
@charliermarsh charliermarsh added this to the Feature complete milestone Nov 13, 2023
@charliermarsh
Copy link
Member

But I can't tell if what's implemented in #398 is Option (1).

@konstin
Copy link
Member Author

konstin commented Nov 13, 2023

I think it's broken on both main and #398 atm, this is a separate task to implement

@charliermarsh charliermarsh self-assigned this Nov 29, 2023
@charliermarsh charliermarsh mentioned this issue Dec 4, 2023
Merged
konstin pushed a commit that referenced this issue Dec 4, 2023
@charliermarsh
Enforce target and interpreter requires-python versions (#532)
0ac4254 
## Summary

This PR modifies the behavior of our `--python-version` override in two
ways:

1. First, we always use the "real" interpreter in the source
distribution builder. I think this is correct. We don't need to use the
fake markers for recursive builds, because all we care about is the
top-level resolution, and we already assume that a single source
distribution will always return the same metadata regardless of its
build environment.
2. Second, we require that source distributions are compatible with
_both_ the "real" interpreter version and the marker environment. This
ensures that we don't try to build source distributions that are
compatible with our interpreter, but incompatible with the target
version.

Closes #407.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@charliermarsh charliermarsh

Labels
bug Something isn't working
Projects
None yet
Milestone
Initial feature complete
Development

Successfully merging a pull request may close this issue.

Enforce target and interpreter requires-python versions astral-sh/uv
2 participants
@charliermarsh @konstin