-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[proposal] Switch from tox to Nox for running continuous integration environments #16412
Comments
One moderately nonsensical follow-up point: I'd say that nox is more astrophysically relevant than tox because |
Any ideas in particular ?
My understanding of tox is that is already allows defining sessions by composition, which could be argued is the only kind of dynamism that we need. I'm personally worried that introducing more dynamism would inflate the maintenance burden, not reduce it.
This seems like a very important point. I don't think we want to alienate the ecosystem that bloomed from astropy, and there's been a consistent effort to keep workflows as similar as possible between repos. Moving astropy away from tox would likely mean that we'd need to help coordinated and affiliated packages do the same, and it sounds like a sizable effort. |
I'm against this for a couple of reasons 👎
|
That's also what I meant in my first point, and I fully agree with your reasoning. Thanks for articulating it more clearly than I did 😄 |
Thank you for the replies — they are very helpful and insightful, and definitely aspects we need to consider!
For PlasmaPy, I'm considering dynamically creating nox sessions that run the tests for each subpackage. For example, doing I'm currently switching over to a nox session that regenerates pinned requirements files used in CI. It's really helpful to be able to use a I've previously considered dynamically extracting the minimum requirements from
I suspect that the amount that this effect would increase the maintenance burden would be more than offset by the reduction in maintenance burden by switching from an INI format to a Python API. I'm curious how the maintenance burden was impacted in other projects that have made the switch from tox → nox.
Agreed; to me this is the most compelling of the reasons not to switch. As with everything in software engineering, there are tradeoffs! ⚖️ It's difficult to find a balance between consistency & stability of package infrastructure, and adoption of new tools that can improve developer experience. Thank you again! |
There is a high enough probability that Astral releases something in the near future that we might want to use instead of |
FYI this currently works with tox by doing e.g.
which will run all tests in astropy.io.fits.
I would say our maintenance burden for using tox.ini is very little right now - I haven't seen any real complaints about it in the last couple of years or things we have spent significant time to work around, but I might be wrong. Tox has also got a lot better with tox 4 as |
Were there any hint specifically in that direction ? |
|
I'm also on the nox bandwagon. I switched recently when I started using https://github.com/scientific-python/cookie to set up my projects. We don't bake a cookie ourselves anymore, and I think this is the one we do / should recommend people use. Anyway, https://github.com/scientific-python/cookie uses |
Just to check, does anyone here have concrete examples of issues with the current tox set-up that would actually be solved by switching to nox? How often do people even have to delve into the current tox config? |
Astropy uses tox to run the environments for its continuous integration checks. While tox is in most ways a fantastic tool, its main drawback is that the configuration file (
tox.ini
) is an INI file. I personally findtox.ini
files to be quite difficult to understand, modify, and maintain.Nox is a project that is similar to tox, except that the configuration file is written in Python. 🐍 I'm in the process of switching PlasmaPy's tox environments to Nox sessions. I've been finding it significantly easier to set up and understand sessions in
noxfile.py
compared totox.ini
. I propose that Astropy switches its test runner from tox to Nox.For some background, I highly recommend Hynek Schlawack's blog post on "Why I Like Nox", and trying out Nox for new or personal projects.
Example
noxfile.py
This file defines the
tests
session, which can be run withnox -s tests
. (Vocabulary difference: a tox environment corresponds to a Nox session.)Tradeoffs ⚖️
Here are some of the pros and cons of making the switch.
✅ Reasons to switch to Nox
.ini
files. ✨❌ Reasons to keep using tox
tox.ini
. 😐Suggested process for switching
I recommend taking an incremental process rather than doing a monolithic PR:
There is a tool called
tox-to-nox
that can help convert tox environments to Nox sessions, though I haven't tried it yet.The text was updated successfully, but these errors were encountered: