Conversation
| {name = 'MDAnalysis Core Developers', email = 'mdanalysis@numfocus.org'} | ||
| ] | ||
| requires-python = ">=3.7" | ||
| dependencies = [ |
There was a problem hiding this comment.
I wasn't too sure how to deal with the optional deps here.
Tests -> should I just add MDAnalysisTests as the dep? How do you dynamically set the version number in pyproject.toml?
Extra deps ->
- Not sure what the keyword should be here (it's unclear if you can just say "extra").
- How do we deal with conda only deps? Does it matter?
There was a problem hiding this comment.
conda only deps seems like a bad idea in general, not sure you can do much about them here..
As for dependencies, I think it should just be the mandatory runtime dependencies, and then [project.optional-dependencies] can contain sections for test, doc, and dev tools (I'd suggest just looking at i.e., the SciPy example pyproject.toml and adapting for our purposes, if you aren't already doing that).
There was a problem hiding this comment.
Sounds good, for now let's just skip [project.optional-dependencies] since most are conda based, I'll raise an issue on merge of this PR with all the things that can be added at a later date to augment the pyproject.toml.
Codecov ReportBase: 94.41% // Head: 94.44% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #3528 +/- ##
===========================================
+ Coverage 94.41% 94.44% +0.03%
===========================================
Files 195 195
Lines 25423 25423
Branches 3526 3526
===========================================
+ Hits 24003 24012 +9
+ Misses 1376 1367 -9
Partials 44 44
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
Hello @IAlibay! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2022-03-27 23:35:25 UTC |
testsuite/pyproject.toml
Outdated
| ] | ||
| requires-python = ">=3.7" | ||
| dependencies = [ | ||
| 'MDAnalysis==2.1.0-dev0', |
There was a problem hiding this comment.
I'm not super into the idea of having yet-another point where we need to update the version numbers. Is there a way around this?
There was a problem hiding this comment.
Hmm, it is indeed pretty ugly from a design standpoint now to have separate main and test packages.
Is there as much of a rush to add a pyproject.toml for the test suite?
It would probably be nice to have the version dynamically set to match the same version of the main package. Not sure how to do that.
There was a problem hiding this comment.
A bit out of scope, but what other major Python projects package their test suite entirely separately from the main project? That might be a good reference point for "how should we handle this?"
If we were to start from scratch, I'd almost certainly vote against having separate packages, and instead use one of the popular "lazy loading/lazy download" packages to pull in test assets if there's an internet connection, otherwise skipping and doing a minimal suite only.
There was a problem hiding this comment.
For 3.0, getting rid of MDAnalysisTests would be a good aim. One thing to solve would be to keep the correct versions of test files in sync with the tests. Maybe download from the correct tag or commit in the repo? That might get a bit more tricky when you want to add/change test files in a branch... anyway, that would be something to think about and to learn from other packages that presumably already do this.
Which lazy-loading packages do you have in mind?
Do you have an example of a package that pulls in test files when needed?
|
@tylerjereddy a lot of this is based on my likely poor understanding of PEP 621 and 631. Any advice / corrections would be greatly appreciated. |
package/pyproject.toml
Outdated
|
|
||
| [project] | ||
| name = "MDAnalysis" | ||
| version = "2.1.0-dev0" |
There was a problem hiding this comment.
Can just do dynamic = ['version'] I think, to avoid having to update this.
| {name = 'MDAnalysis Core Developers', email = 'mdanalysis@numfocus.org'} | ||
| ] | ||
| requires-python = ">=3.7" | ||
| dependencies = [ |
There was a problem hiding this comment.
conda only deps seems like a bad idea in general, not sure you can do much about them here..
As for dependencies, I think it should just be the mandatory runtime dependencies, and then [project.optional-dependencies] can contain sections for test, doc, and dev tools (I'd suggest just looking at i.e., the SciPy example pyproject.toml and adapting for our purposes, if you aren't already doing that).
testsuite/pyproject.toml
Outdated
|
|
||
| [project] | ||
| name = "MDAnalysisTests" | ||
| version = "2.1.0-dev0" |
There was a problem hiding this comment.
I think we can avoid updating this by using dynamic = ['version', 'description'], or similar, based on me cheating and looking at other projects.
testsuite/pyproject.toml
Outdated
| ] | ||
| requires-python = ">=3.7" | ||
| dependencies = [ | ||
| 'MDAnalysis==2.1.0-dev0', |
There was a problem hiding this comment.
Hmm, it is indeed pretty ugly from a design standpoint now to have separate main and test packages.
Is there as much of a rush to add a pyproject.toml for the test suite?
It would probably be nice to have the version dynamically set to match the same version of the main package. Not sure how to do that.
testsuite/pyproject.toml
Outdated
| ] | ||
| requires-python = ">=3.7" | ||
| dependencies = [ | ||
| 'MDAnalysis==2.1.0-dev0', |
There was a problem hiding this comment.
A bit out of scope, but what other major Python projects package their test suite entirely separately from the main project? That might be a good reference point for "how should we handle this?"
If we were to start from scratch, I'd almost certainly vote against having separate packages, and instead use one of the popular "lazy loading/lazy download" packages to pull in test assets if there's an internet connection, otherwise skipping and doing a minimal suite only.
|
So long story short, it seems that the latest release of setuptools is essentially enforcing a ton of things related to pyproject.toml which it didn't use to. To speed things up I'm ditching the addition of a pyproject.toml for testsuite for now. Let's try to get the main package one up to scratch first, then we address testsuite later. |
package/pyproject.toml
Outdated
|
|
||
| [project] | ||
| name = "MDAnalysis" | ||
| dynamic = ['version', 'readme'] |
There was a problem hiding this comment.
@tylerjereddy can I pick your brains on this?
Essentially adding a direct readme entry in the pyproject.toml is complicated because it accesses the README.rst which exists outside of the package directory. So I'm thinking we can possibly just leave it as dynamic since setup.py has set logic for gathering long-description, does that make sense to do?
edit: adding to dynamic still caused issues... not sure what the best solution here is at this point.
orbeckst
left a comment
There was a problem hiding this comment.
The license update to "GPL v2 or later" is perfect. ✅
|
I'm adding this to the 2.4.0 milestone, with the way that things are going we should attempt to be fully pep621 compliant by end of year. TODOs here are mostly updating things. |
| "scikit-learn", | ||
| "tidynamics>=1.0.0", | ||
| ] | ||
| doc = [ |
There was a problem hiding this comment.
missing test entry because passing in a dynamic version for MDAnalysisTests doesn't really work...
|
@MDAnalysis/coredevs this is good to go as needed for 2.4.0, I recommend using scipy's pyproject.toml as a template to check against during review: https://github.com/scipy/scipy/blob/main/pyproject.toml |
|
@MDAnalysis/coredevs can I get a review here please? This is stalling the 2.4.0 release |
|
Ta, two PRs to go. |
Fixes #3526
Changes made in this Pull Request:
TODO:
PR Checklist