Skip to content

feat(pypi): actually start using env_marker_setting #2873

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

Merged
merged 7 commits into from
May 13, 2025

Conversation

aignas
Copy link
Collaborator

@aignas aignas commented May 11, 2025

Summary:

  • pep508_deps is now much simpler, because the hard work is done in
    analysis phase
  • whl_library BUILD.bazel tests now also have a test for the legacy
    flow.

One thing that I noticed is that now we have an implicit dependency on
the python toolchain when getting all of the whl target tree. This is
a filegroup target that includes dependent wheels. However, we fallback
to the flag values if we don't have the toolchain, so we should be good
in general.

Overall I like how this is turning out because we don't need to pipe the
target_platforms anymore when we enable PIPSTAR feature. This means
that we can start creating fewer whl_library instances - e.g. a
py3-none-any wheel can be fetched once instead of once per python
interpreter version. I'll leave this optimization for a later time.

Work towards #260

Summary:
- `pep508_deps` is now much simpler, because the hard work is done in
  analysis phase
- `whl_library` BUILD.bazel tests now also have a test for the legacy
  flow.

One thing that I noticed is that now we have an implicit dependency on
the python toolchain when getting all of the `whl` target tree. This is
a filegroup target that includes dependent wheels. However, we fallback
to the flag values if we don't have the toolchain, so we should be good
in general.

Overall I like how this is turning out because we don't need to pipe the
`target_platforms` anymore when we enable `PIPSTAR` feature. This means
that we can start creating fewer whl_library instances - e.g. a
`py3-none-any` wheel can be fetched once instead of once per python
interpreter version. I'll leave this optimization for a later time.

Work towards bazel-contrib#260
@aignas aignas requested review from rickeylev and groodt as code owners May 11, 2025 07:54
name = "",
target = "requirements.bzl",
),
"all_whl_requirements_by_package",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: check if this will contain all of the packages or only the ones that are present on all platforms.

We may need to re-include the config.bzl.tmpl.bzlmod and put the list of all packages there.

@aignas aignas marked this pull request as draft May 12, 2025 00:33
@aignas
Copy link
Collaborator Author

aignas commented May 12, 2025

Marking as draft due to the TODO note.

Extra notes:

  • Having a parameter for enable_pipstar in the pip.parse would be preferable. An env var makes it harder to test.
  • I have tested this with the env var enabled and it worked on my machine to build the sphinx docs, so the code is somewhat functional already.

@aignas
Copy link
Collaborator Author

aignas commented May 12, 2025

I'll do the enable_pipstar param instead of env var at a later PR.

@aignas aignas marked this pull request as ready for review May 12, 2025 10:57
Comment on lines +363 to +364
rules.env_marker_setting(
name = "include_{}".format(dep),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was expecting to a list of extras passed in. But I guess the extras are being handled earlier?

The case I had in mind was a more complicated boolean expression e.g. (extra == foo and python_version ~= 3.10) or (extra = bar and python_version ~= 3.9); something that requires the target config to be evaluated.

That seems rare, though? And can probably be ignored?

Copy link
Collaborator Author

@aignas aignas May 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could split the handling of the requires_dist and create one target for each requested extra:

  • We create a no extras target named pkg__ then for each requested extra pkg__{extra} and then we make the pkg target depend on ["pkg__"] + ["pkg_{}".format(x) for x in extras].
  • Then we can split the deps and the marker targets to be more correct.

I think this may be win-win and in the future we could also expose the extra targets, what do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Realized that this should be still fine as is, at least for your example. Leaving the comment unresolved in case something comes along.

@aignas aignas added this pull request to the merge queue May 13, 2025
Merged via the queue into bazel-contrib:main with commit a13fcd7 May 13, 2025
3 checks passed
@aignas aignas deleted the feat/220/use-marker-setting branch May 13, 2025 23:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants