Skip to content

Declare optional dependencies in extras_require#8198

Merged
astrofrog merged 13 commits intoastropy:masterfrom
astrofrog:extras-require
Dec 7, 2018
Merged

Declare optional dependencies in extras_require#8198
astrofrog merged 13 commits intoastropy:masterfrom
astrofrog:extras-require

Conversation

@astrofrog
Copy link
Member

@astrofrog astrofrog commented Nov 30, 2018

This does the following:

  • Separate testing and non-testing optional dependencies in the install docs
  • Declare all optional dependencies in an extras_require entry in setup.py - with this, users could get all dependencies by running pip install astropy[all]
  • Declare all testing dependencies in the test entry in extras_require. This would allow all those dependencies to be installed when doing pip install astropy[test]. Note that this is different from tests_require which is the one actually used to temporarily install the bare minimum testing dependencies when running tests.
  • Declare the docs dependencies in the docs entry - and RTD can recognize this
  • Remove the pip requirement files to avoid duplication
  • Update the minimum required version of Matplotlib to 2.0 (this is effectively what we supported but the docs claimed 1.5)
  • Modify one of the Travis builds to pip install dependencies instead of using ci-helpers

At the moment, this has a small performance impact on Travis - the build I modified took 14 min 37 sec in the last successful run before this PR, and 15 min 58 sec now. I think this is because astropy is built twice, once in the pip install command, and the second time from the python setup.py test command, so I need to look into whether we can avoid this. Part of it could also be because we now run 12638 tests in this build instead of 12123, presumably because not all optional dependencies were included in CONDA_ALL_DEPENDENCIES.

As a side goal, I want to see how fast installing dependencies with pip is, as if it is quite fast then we could consider actually using pip to install dependencies in most builds instead of conda, and we could also avoid declaring all dependencies in CI config files (instead relying on the minimal/full configurations available in setup.py - that is, some builds could use the all extras_require`` and some not).

This is an experimental PR that I hope to find time to discuss next week, so do not merge!

@drdavella
Copy link
Contributor

For consistency should tests_require contain the same dependencies as extras_require['test']? Presumably, tests_require is going to be less useful as the community moves away from using setup.py as a tool entry point.

@astrofrog
Copy link
Member Author

@drdavella - I'm not sure yet, because some of the test dependencies are optional, so I don't want to always force people to temporarily install those. Maybe we should have a testall extras_require which has all the optional test dependencies, and then test can match tests_require?

@drdavella
Copy link
Contributor

Ah, makes sense. Maybe at the very least we can just say that extras_require['test'] = tests_require + the_kitchen_sink.

@saimn
Copy link
Contributor

saimn commented Nov 30, 2018

I was thinking about this when playing with tox, but I'm not sure about the 'all' dependencies bundle, which represents a lot of things. It could make sense to have a finer split, maybe by sub-package, 'io', 'table', 'stats', 'viz' ? I think these can be combined in the pip command. But I don't know where to put scipy...

@bsipocz
Copy link
Member

bsipocz commented Nov 30, 2018

But I don't know where to put scipy...

in that framework I suppose on package can be specified in several points. at least scipy should go into multiple ones

@saimn
Copy link
Contributor

saimn commented Nov 30, 2018

in that framework I suppose on package can be specified in several points. at least scipy should go into multiple ones

That may be an option, but I think if if you specify multiple extra to pip then it will complain about the duplicate dependencies. Something to check.

@bsipocz
Copy link
Member

bsipocz commented Nov 30, 2018

Then it's a feature request for them to do a set before complaining for things like this ;)

@astrofrog
Copy link
Member Author

astrofrog commented Nov 30, 2018

It doesn't actually take long to install all though, so I'm not sure if it's really important to split them up. Especially if duplicate dependencies are going to cause a problem. I think regardless of whether we add more fine-grained extras_requires, we do need an 'all' one that just installs everything.

@astrofrog
Copy link
Member Author

So this now also adds a [docs] extras require and uses that for RTD. I've also removed pip requirement files because if we do go down this road we should avoid duplicating information.

@codecov
Copy link

codecov bot commented Dec 2, 2018

Codecov Report

Merging #8198 into master will decrease coverage by <.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8198      +/-   ##
==========================================
- Coverage   86.91%   86.91%   -0.01%     
==========================================
  Files         383      383              
  Lines       57889    57889              
  Branches     1056     1056              
==========================================
- Hits        50313    50312       -1     
- Misses       6962     6963       +1     
  Partials      614      614
Impacted Files Coverage Δ
astropy/utils/data.py 80.7% <0%> (-0.23%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a170a74...007f0b8. Read the comment docs.

Copy link
Member

@eteq eteq left a comment

Choose a reason for hiding this comment

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

I like this change, but a few suggestions (which I'm not necessarily attached to but they might be good ideas):

  1. (related to an inline comment) keep the requirements files and just pull them in in the setup script so people can pip install -r <whatever> but still get all of the goodness here.
  2. Add something about this to the install instructions?
  3. Make sure this works on RTD. I think @astrofrog did this already (in-person discussion), but just making sure.

Also, later on (doesn't have to be in this PR), we should add something that somehow checks if all the optional dependencies are actually in this list. @astrofrog says there's something already in glue that makes that fairly straightofrward to manage (i.e., a thing we can replace our HAS_SCIPY and similar pytest marks with). But we can add an issue after this is merged about this.

setup.py Outdated
extras_require = {}

# All optional dependencies for the tests
extras_require['test'] = ['pytest-astropy', 'pytest-xdist', 'pytest-mpl',
Copy link
Member

Choose a reason for hiding this comment

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

We could keep the existing requirements files and instead do something like:

Suggested change
extras_require['test'] = ['pytest-astropy', 'pytest-xdist', 'pytest-mpl',
with open('pip-requrirements-test') as f:
extras_require['test'] = [line for line in f.read().split('\n') if line.strip()!='']

?

@eteq
Copy link
Member

eteq commented Dec 6, 2018

Some in-person discussion re 1 led to: we should not use requirements files because they aren't for dependencies, rather for environments according to the PyPA (thanks @Cadair for pointing that out). But we can still see have a cleaner representation of the requirements by putting them in setup.cfg, so we should do that.

@pllim pointed out some users are using requirements files though, so we should do something like leaving it there with a comment that says "switch to the the new pip install astropy[all] syntax". I would argue it shouldn't be a comment, rather it should error so that a user has to go and learn the new trick. But opinions in the room varied on that...

@pllim
Copy link
Member

pllim commented Dec 6, 2018

some users are using requirements

Maybe send out a notice to astropy users mailing list to see if there are any objections?

@astrofrog astrofrog added this to the v3.2 milestone Dec 7, 2018
@astrofrog
Copy link
Member Author

I've added mentions of this to the installation docs, and tested that it works on RTD. I've also added a dummy pip-requirements file with instructions for using the new way.

@astrofrog
Copy link
Member Author

Since the CI passed before my minor changelog entry change, and this has been approved, I'll go ahead and merge.

@astrofrog astrofrog merged commit b225a5a into astropy:master Dec 7, 2018
@astrofrog astrofrog mentioned this pull request Dec 7, 2018
4 tasks
py:obj NotImplementedError
py:obj AttributeError
py:obj NotImplementedError
py:obj RendererBase
Copy link
Member

Choose a reason for hiding this comment

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

I need this change in the release. Should I try to backport the whole PR, or rather just cherry pick this single commit?

@pllim
Copy link
Member

pllim commented Jan 19, 2019

So, what is the minversion of setuptools that supports this?

@astrofrog
Copy link
Member Author

I think it's setuptools 30.3.

eerovaher added a commit to eerovaher/astropy that referenced this pull request Feb 9, 2023
This reverts commit 1d9729b.

The way `astropy` declared its dependencies was changed in astropy#8198. The
migration instructions added by the reverted commit are more than 4
years old by now and it is safe to assume they are not needed anymore.
eerovaher added a commit to eerovaher/astropy that referenced this pull request Feb 9, 2023
The way `astropy` declared its dependencies was changed in astropy#8198. The
migration instructions added by the deleted file are more than 4 years
old by now and it is safe to assume they are not needed anymore.
dougbrn pushed a commit to dougbrn/astropy that referenced this pull request Mar 13, 2023
The way `astropy` declared its dependencies was changed in astropy#8198. The
migration instructions added by the deleted file are more than 4 years
old by now and it is safe to assume they are not needed anymore.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants