-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
MNT: fix CI and fix install on Linux #161
Conversation
It won't run here until after this PR is merged, so we'll have to trust the run from your fork. 🤞 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I love the +302 −1,662
clean-up. Thanks!
I guess you don't want to be bothered with tox here? Just wondering if you are aware of https://github.com/OpenAstronomy/github-actions-workflows and would like to use that to further simplify your CI or not. If you don't want to do that now, we can always defer too.
Hard to tell if RTD would build or not until after merge.
If I am reading the diff correctly, you completely gutted pyregion/conftest.py
, is that intentional?
Why remove pyregion/tests/__init__.py
?
`wcsaxes <https://github.com/astrofrog/wcsaxes>`__ | ||
|
||
To work with the development version, you'll need Cython and a C compiler, | ||
To work with the development version, you'll need a C compiler, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You removed Cython from the text here but I see it in pyproject.toml
build requirements, why the inconsistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One doesn't actually need Cython installed anymore to build the package. It gets pulled automatically to do the build now because it is PEP517-compliant, and is listed in pyproject.toml. Best not to confuse people. Just tell them how to install the package and leave out the underlying details of what happens under the hood.
# Affiliated packages may add whatever they like to this file, but | ||
# should keep this content at the top. | ||
# ---------------------------------------------------------------------------- | ||
from ._astropy_init import * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you don't need the test runner from _astropy_init
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, just normal pytest for testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, you removed a user's ability to test the installed package by running import pyregion; pyregion.test()
. Is that intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, intentional. Is there a reason to support this very non-standard way of running tests?
If there is, I can put it back, but I think it's very much a legacy piece of infrastructure that is not common or recommended in python outside of astropy
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do find it nice that user can run tests on their installed copy. I still call that myself when I publish though I guess I don't have to but it is just so convenient.
Here, you are actually removing a feature, so should get okay from @larrybradley or @keflavich first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Running tests on installed copies is very easy:
pip install pyregion[test]
pytest --pyargs pyregion
And is the recommend way. I even updated the docs to show this is the standard way. Doing it this way ensures test dependencies are installed, and it works generally for python packages.
One can also run tests on the installed version if you are in the git repo checkout doing development:
pip install .[test]
pytest --pyargs pyregion --import-mode=importlib
Which will install the package in site-packages and then run the tests from in there as well, ensuring not to add .
to sys.path, i.e. accidentally import the code from the local checkout. --import-mode=append
would also work if there a bunch of test helpers in the test dirs, which there are not in this package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, so pytest --pyargs pyregion
can detect the installed copy even if you didn't check out the source or not in the site-packages dir? I didn't know that. pytest sure has come a long way since that time the whole thing was in one file that astropy bundles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you just have to use --import-mode
set to anything other than the default, which is prepend
. This can also be set in setup.cfg if needed, but it's nice to allow flexibility I think.
bde434c
to
7e77559
Compare
7e77559
to
55cb7cf
Compare
runs-on: ${{ matrix.os }} | ||
strategy: | ||
matrix: | ||
python-version: ["3.7", "3.8", "3.9", "3.10", "3.11"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we drop 3.7?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can! Though it is still officially supported by python.org, though that will change in mid-2023.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think most packages in the python scientific stack have adopted NEP 29 (https://numpy.org/neps/nep-0029-deprecation_policy.html).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. Given that I have no plans to add features or anything to this package, only to fix the build/install and verify it via CI, then I'm happy to have a wider allowed version schedule. Especially given that whatever code still uses it is probably also old. Of course if it stops working on Python 3.7 or Numpy 1.19 next year, happy to immediately drop support. I just didn't want to artificially bump allowed versions of dependencies without having a good reason for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think dropping Python 3.7 can be a separate PR if needed, especially given it is still green here.
python-version: ["3.8", "3.9", "3.10", "3.11"] | ||
os: [ubuntu-latest, macos-latest, windows-latest] | ||
include: | ||
- python-version: "3.7" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I'm just building the oldest dependencies listed in install_requires
on python 3.7, and it was to figure out what minimum version to specify, as there was none specified before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jdavies-st.
Just curious - what features do you need from this package?
Yes, I figured the minimal "getting CI working" would be what I have here. Happy to implement
It does! Though I don't know how the rtd builds are triggered on this repo. Maybe they're not? It seems the current docs are a bit behind the current release, and there was no rtd yml file in here before. A mystery. I did make sure that every page is identical to what is currently there.
Yes, though I realize I can include
Not necessary, as |
grizli depends on it. And that is the workhorse package for all science being done with JWST grism data right now. The official I figured fixing up the installation for |
Well, the admin from https://readthedocs.org/projects/pyregion/ (@astrofrog) would need to enable https://docs.readthedocs.io/en/stable/pull-requests.html for RTD to build for PRs. Otherwise, we'll find out when this is merged...
You will have to add that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM if you really don't think you need pyregion.test()
anymore. And we can always fix up any remaining small things as follow-up PRs.
I'll approve but let the maintainers merge (@larrybradley or @keflavich).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @jdavies-st.
I note that this partially duplicates the work in #157 which was opened two months ago and was never reviewed. |
We apologize for the oversight, @smaret ! This package is minimally maintained. For future contributions, please contact other Astropy Project maintainers if you do not hear back. We have a several places for communication: https://www.astropy.org/help.html |
I knew this was just a matter of time. Pyregion is part of many packages due to its age. Perhaps we can create easy porting guidelines for people wanting to port their code to Regions 🤔? |
Great idea, @prajwel ! I opened astropy/regions#488 |
This PR does 2 things:
I tested it on my own fork against
main
, and you can see the Github actions CI running there and the build and test works. jdavies-st#1Running the workflows on this PR will need to be enabled by a maintainer. @pllim ?
These 2 simple things above involve
astropy-helpers
, which means modifying the build system and sphinx config to work without it.build
,setuptools-scm
, etc. This project uses Cython and numpy as build dependencies, so of course these modern tools make everything just work.Resolves #121
Resolves #139
Resolves #140
Resolves #147
Resolves #148
Resolves #150
Resolves #151
Resolves #156
Resolves #158
Resolves #160
Closes #144
Closes #149
Closes #155
Closes #157