Skip to content
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

Switch versioning to setuptools_scm from versioneer #1160

Merged
merged 13 commits into from Sep 21, 2019

Conversation

zbruick
Copy link
Contributor

@zbruick zbruick commented Sep 13, 2019

Description Of Changes

Followed PRs from other projects that have done this, namely black. Documentation for setup tools_scm is here. I probably missed removing metpy/_version.py in some places - TBH not sure where that should be removed and where it shouldn't be, since it will be generated by scm now.

Checklist

@zbruick
Copy link
Contributor Author

zbruick commented Sep 13, 2019

How do we exclude the testing of setuptools_scm that's causing the python3 Travis coverage versions to fail? Also looks like there's a problem with 2.7, although setuptools_scm is compatible with 2.7.

@dopplershift dopplershift added Area: Infrastructure Pertains to project infrastructure (e.g. CI, linting) Type: Maintenance Updates and clean ups (but not wrong) labels Sep 17, 2019
@dopplershift dopplershift added this to the 0.11 milestone Sep 17, 2019
Copy link
Member

@dopplershift dopplershift left a comment

Choose a reason for hiding this comment

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

A good start. I'm going to dig in some more on this too and see if we can fix some of these things by moving to more setup.cfg and pyproject.toml.

setup.py Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
@zbruick
Copy link
Contributor Author

zbruick commented Sep 19, 2019

Thanks for digging in on this and cleaning up my initial attempt. This looks good to me. CI failures are due to the xarray update.

@dopplershift
Copy link
Member

Not quite. We've got Travis failures to find the manifest for the test data (even though I've verified it's fine locally). AppVeyor is also failing for...unknown reasons.

@dopplershift
Copy link
Member

Ok, one problem down. What a cluster. I couldn't figure out why it worked (and always worked) on my mac, worked to run tests on Travis, but failed docs on Travis:

  1. Building sdist/wheel first lays out the directory structure in build/. This is where options like include_package_data take effect. Future runs only ever use this no matter what options are set. This is why my mac always worked (originally run with include_package_data=True).
  2. Tests on Travis were building a wheel with the default, include_package_data=False. However, because we run pytest out the repository root, the tests were not using the installed copy. See File layout #1171 .
  3. Building docs runs out of docs/, and so actually used the installed copy

I hate everything.

@zbruick
Copy link
Contributor Author

zbruick commented Sep 19, 2019

Does this count as successful nerd sniping if it also causes an existential crisis at the same time?

There's gotta be an XKCD comic for this...

@dopplershift
Copy link
Member

Probably bonus points: you didn't kill me, I just feel dead inside. 😉

Actually, I prefer to think of it as grinding to raise my character stats. I now have an extra +5 defense against build systems.

@dopplershift
Copy link
Member

Ok, now we're only failing from the xarray changes.

zbruick and others added 10 commits September 20, 2019 22:01
Use pyproject.toml so we can specify our dependence on setuptools_scm
and appropriate version of setuptools.
We can now put this in setup.cfg instead of setup.py, which greatly
simplifies code in setup.py.

Also update a lot of the metadata while we're at it.
Now that we use setuptools_scm, it handles including anything under
source control, so we only need to remove a few items, like the static
test data.
Put code in _version to work on both static and dev releases.
Trying to consolidate more of our tool configs.
We haven't used this in forever, and it does not seem to be around any
more.
We control it now, so we shouldn't be excluding it any more.
setuptools, wheel, and setuptools_scm are dependencies of the build
system and not metpy, so they're not handled otherwise when we do the
rest of the build dance. Therefore, we need to download them to the
package cache explicitly.
This causes us to run through setuptools without pip, meaning setuptools
thinks it should download eggs for setuptools_scm. O_o It's not really
something most projects use, and at any rate it's actually shorter to
use pytest directly. Getting rid of that means we don't need anything
for pytest-runner or the alias in setup.cfg.
It's more reliable than just running the utility.
Use the new VS2019 image to get more recent installs and eliminate
CygWin. For some reason cygwin's git was breaking setuptools_scm. Also
add a config to make Python 3.7 use the preinstalled Python 3.7
miniconda.
@dopplershift
Copy link
Member

I'm not sure what codecov's deal is now. Merging...

@dopplershift dopplershift merged commit b6cd88f into Unidata:master Sep 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Infrastructure Pertains to project infrastructure (e.g. CI, linting) Type: Maintenance Updates and clean ups (but not wrong)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Investigate setuptools-scm
2 participants