Skip to content

build: improve opt deps - #16340

Merged
mhvk merged 3 commits into
astropy:mainfrom
nstarman:build-pre-commit-in-test
May 28, 2024
Merged

mhvk merged 3 commits into
astropy:mainfrom
nstarman:build-pre-commit-in-test

Conversation

@nstarman

@nstarman nstarman commented Apr 25, 2024 •

Copy link
Copy Markdown
Member

Small improvements to the specification of optional dependencies. In particular, this improves astropy[all] to actually have everything and installs pre-commit for astropy[test] since our CI consists of 1. pre-commit checks, e.g. yaml verification, and 2. pytest-powered stuff.

  • By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

@github-actions

github-actions Bot commented Apr 25, 2024 •

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

@pllim pllim added Extra CI Run cron CI as part of PR Build all wheels Run all the wheel builds rather than just a selection labels Apr 25, 2024
@pllim

pllim commented Apr 25, 2024

Copy link
Copy Markdown
Member

Looks reasonable but let me run the other jobs, just in case. Thanks!

@astrofrog

astrofrog commented Apr 25, 2024 •

Copy link
Copy Markdown
Member

Should all actually include test_all? I think of it as meaning all runtime dependencies? Not a strong opinion though.

@pllim

pllim commented Apr 25, 2024

Copy link
Copy Markdown
Member

Good point... There is a distinction between what users need and what testers need.

@nstarman

Copy link
Copy Markdown
Member Author

As in I should reverse the relationship and have all be a subset of test_all, not test_all a subset of all ?

all = [...] # doesn't have test_all
test_all = ["astropy[all]", ...]

@pllim

pllim commented Apr 25, 2024

Copy link
Copy Markdown
Member

have all be a subset of test_all

I think this makes more sense. What do you think, @astrofrog ?

@astrofrog

Copy link
Copy Markdown
Member

Yes probably makes more sense

Comment thread pyproject.toml Resolved
@nstarman

nstarman commented Apr 26, 2024 •

Copy link
Copy Markdown
Member Author

It would be nice to have an "absolutely everything" category, which makes getting setting up astropy dev environments super simple. I was making all into that, but it's AOK to keep that as all runtime dependencies. What do people think about a dev category that contains all dependencies -- runtime, static, docs, testing ?

@pllim @eerovaher @astrofrog

@mhvk

mhvk commented Apr 27, 2024

Copy link
Copy Markdown
Contributor

Agreed that I always thought of all as getting meaning I can now run absolutely every astropy function, not that it includes testing or building documentation. Hence, all being part of test_all makes more sense to me, just like astropy[recomended] is part of docs.

I like the idea of a dev dependency that includes all needed to start development, but slightly orthogonal here. E.g., not quite clear that needs all of astropy's optional dependencies (I guess that would be dev_all...)

@nstarman
nstarman requested review from eerovaher and mhvk April 28, 2024 01:24

@mhvk mhvk left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

See my one remaining comment, which mostly means another reason to leave this open for a little longer so others can comment.

But I think this little reorganization makes good sense now!

Comment thread pyproject.toml Resolved
Comment thread pyproject.toml Resolved
Comment thread pyproject.toml Resolved
@nstarman
nstarman force-pushed the build-pre-commit-in-test branch from d94cd6a to 6887bbb Compare May 19, 2024 22:07
@nstarman

nstarman commented May 19, 2024 •

Copy link
Copy Markdown
Member Author

Given the merge conflict I took this opportunity to add code comments and some discussion in the docs. I also added the [ipython] and [jupyter] optional dependency categories to group the newly added dependencies (the source of the merge conflict). Lastly, I put the run-time groups at the top.

@nstarman nstarman closed this May 19, 2024
@nstarman nstarman reopened this May 19, 2024

@neutrinoceros neutrinoceros left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just a couple of extremely minor suggestions

Comment thread pyproject.toml Outdated
"astropy[test]",
# Install all remaining dependencies
"objgraph",
"coverage[toml]",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

shouldn't this line be in [test] ? I also note that it's actually already there in a way (pytest-astropy requires pytest-cov which itself requires coverage[toml])

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Moved!

Comment thread pyproject.toml Outdated
"array-api-strict",
]
typing = [
"typing_extensions>=4.0.0"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
"typing_extensions>=4.0.0"
"typing_extensions>=4.0.0",

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Added.

Comment thread docs/install.rst Resolved

@eerovaher eerovaher left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm not convinced we need separate ipython and jupyter dependency sets.

It does look like it would be a good idea to rewrite the astropy development version installation instructions and the dependency descriptions, but doing that properly is beyond the scope of this pull request.

Comment thread docs/development/codeguide.rst Resolved
Comment thread docs/development/testguide.rst Resolved
Comment on lines +42 to +44
To test the full set of optional dependencies, use the ``test_all`` option::

python -m pip install --editable ".[test_all]"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It would be much better if these descriptions could link to relevant subsections in the description of dependencies, but that would require those subsections to exist. It looks like all the installation instructions (including the installation instructions for building documentation) could benefit from being rewritten, but that's going beyond the scope of this pull request and is best done in a separate pull request instead.

Comment thread docs/install.rst Resolved
Comment thread pyproject.toml
Comment on lines +62 to 66
jupyter = [ # these are optional dependencies for `utils.console`
"astropy[ipython]",
"ipywidgets",
"ipykernel",
]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Does this install jupyter?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't think it does. But I'm also not sure it should: jupyter comes in different shapes (jupyterlab and notebook) and we don't need to impose a choice onto our users (I think ?)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Something seems to be pulling in jupyter stack but it is already that way in main. Hmm!

2024-05-19T22:19:37.9405799Z jupyter_client==8.6.1
2024-05-19T22:19:37.9406161Z jupyter_core==5.7.2
2024-05-19T22:19:37.9406568Z jupyterlab_widgets==3.0.10

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is just moving around the dependencies, not adding any. I titled it jupyter since it's for use when in a Jupyter environment.

@nstarman nstarman May 22, 2024 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is in contrast to the ipython dep, which enables functionality in astropy.utils.console within any ipython environment not just a Jupyter one.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do you expect anyone to ever use the ipython and jupyter dependency sets?

@neutrinoceros neutrinoceros May 23, 2024 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yes. Even if not publicly advertised, these things have a way of finding their users, in my experience.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

For another PR, but I do think we should have a page detailing these install options. Like...

If you're using an IPYthon environment, use astropy[ipython]. This is further improved by astropy[jupyter] when in a Jupyter notebook. astropy[typing] improves static typing compatibility. To get everything do astropy[all].

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It might indeed be the case that documentation could explain what these dependency sets would be good for, but the more dependency sets we have, the more documentation we need to explain them. At some point the more granular dependency sets will not be worth the effort of documenting them.

@mhvk mhvk left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nice! Good to go with the remaining suggested changes from others as far as I'm concerned.

Signed-off-by: nstarman <[email protected]>
@nstarman
nstarman force-pushed the build-pre-commit-in-test branch from 4e54edc to 7b84565 Compare May 22, 2024 02:52
@nstarman
nstarman requested a review from eerovaher May 22, 2024 03:12
@pllim

pllim commented May 22, 2024

Copy link
Copy Markdown
Member

with the remaining suggested changes from others

Does this mean we're still seeking a couple of more approvals?

@eerovaher eerovaher left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm still not convinced we need separate ipython and jupyter dependency sets, but listing the dependencies is definitely done much better in this pull request than on main.

@mhvk

mhvk commented May 22, 2024

Copy link
Copy Markdown
Contributor

with the remaining suggested changes from others

Does this mean we're still seeking a couple of more approvals?

I thought the comments given by others had not yet been all addressed, so was hoping to see those addressed or dismissed.

@mhvk

mhvk commented May 28, 2024

Copy link
Copy Markdown
Contributor

Looking at this again, I think there are actually no outstanding issues - and if there are, these can be dealt with later. So, let's get this in. Thanks, @nstarman, this is substantially nicer!

@mhvk
mhvk merged commit c88f256 into astropy:main May 28, 2024
@pllim

pllim commented May 28, 2024

Copy link
Copy Markdown
Member

tl;dr -- Did you double check that tox.ini and the workflows in .github/workflows not need updating?

Comment thread pyproject.toml
"ipykernel",
"ipython>=7.32",
"ipywidgets",
"pytest>=7.0",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Why has been pytest removed as a dependency here? The test runner uses it, so strictly speaking it's a genuine optional dependency.

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

Labels

Build all wheels Run all the wheel builds rather than just a selection Extra CI Run cron CI as part of PR installation no-changelog-entry-needed

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

7 participants