Skip to content

Internal review of PEP 771 - May 2025 edits #2

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

Closed
wants to merge 13 commits into from

Conversation

astrofrog
Copy link
Owner

@astrofrog astrofrog commented May 2, 2025

This implements changes to PEP 771 based on the discussion at https://discuss.python.org/t/pep-771-default-extras-for-python-software-packages/79706 - I have reviewed the discussion in detail, and I believe the main changes that need to be done are:

  • Change the specification so that package[] does not install default extras, and package[invalid] is equivalent to package
  • Add a section explaining why splitting a package into package-core and a package metapackage is not sufficient - this is likely the biggest one to address. Some points against this are that it either requires 2 repos (which would be a pain to keep in sync version wise and a big maintenance burden), or a single monorepo, for which some tools (which ones?) are not well adapted. Might still require more effort (double the number of releases, needing to be careful about keeping versions in sync, etc.)
  • Mention the case where there might be multiple backends and frontends, and authors might want to have a default backend and a default frontend, currently package[backend1] would disable default front-ends too, see here for a possible documentation-based solution with this PEP, we might want to address whether PEP 771 will make it harder to implement other kinds of solutions for this in future
  • Make it more explicit what exactly authors have to document (original comment here)
  • Remove blas/lapack and FFT examples, maybe find others instead (this was Ralf's comment here)
  • Explicitly state in the specification what happens if A depends on B and B has default extras - is the installer ever allowed to not install the default extras? (this came up in the context of the --no-default-extras flag here)
  • State somewhere that default extras shouldn't be considered more lightweight than hard dependencies, with pytest as an example - if pytest adds a default extra, then thousands of plugin packages would have to explicitly opt out from the default extras, otherwise installing one of the plugins might result in the default extras getting pulled in.

Packages that might find this useful for removing hard dependencies:

  • bokeh (see comment here) - to make tornado optional
  • check-jsonschema (see comment here)
  • scikit-build-core (see comment here)

@DEKHTIARJonathan and @henryiii: does the list above seem complete enough to you? Are there any other items you think we should address?

@henryiii - you mentioned specifically in https://discuss.python.org/t/pep-771-default-extras-for-python-software-packages/79706/53 that you might be interested in suggesting specific wording changes to the PEP. If you would still have time and be willing to do this, you could open a PR against my branch here and I can merge the suggested changes in? (and let me know if you'd like to join as an author!)

More generally, let me know if either of you would like to take a stab at any of the points above! I am not likely to have time to work on this more until the middle of next week.

@astrofrog astrofrog marked this pull request as ready for review May 12, 2025 13:29
@astrofrog
Copy link
Owner Author

I think I've implemented all the comments I wanted to cover

@DEKHTIARJonathan - did you want to review this before I submit a PR with these changes to the peps repo?

@astrofrog
Copy link
Owner Author

@henryiii - did you want to make any tweaks to the PEP before I submit this to the peps repo? (just checking as you said before you may want to)

@astrofrog
Copy link
Owner Author

In the interest of moving forward, I'll go ahead and open a PR to the peps repo, but I will ping you both there in case you would like to make any comments/suggestions

@astrofrog
Copy link
Owner Author

See python#4428

@astrofrog astrofrog closed this May 20, 2025
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