nose-devs / nose2

The successor to nose, based on unittest2
https://nose2.io
Other
794 stars 132 forks source link

Consolidating configurations in pyproject.toml #603

Closed JCHacking closed 7 months ago

JCHacking commented 7 months ago

Now in python the central file is pyproject, so it would be a good idea to move the tool configurations that can go there.

In this case they would be:

sirosen commented 7 months ago

Coverage config certainly can and should move into there. I'm fairly sure neither of the other two can.

flake8's maintainer has taken a stance against supporting this (albeit, years ago), and I don't think that's changed.

I use tox pretty extensively and haven't heard of embedding its config. So I'm suspicious, but happy to learn something new if I'm wrong!

JCHacking commented 7 months ago

Upon further investigation there are these possibilities:

Therefore, I think the most reasonable thing to do is to consolidate coverage and tox, since an extra dependence on flake8 without need is something that does not add value.

sirosen commented 7 months ago

:-1: on using the flake8 plugin. I've been aware of it but I don't see that it offers sufficient benefit to justify adding another tool to the set of dependencies to manage and track and worry about.

As for tox, I guess it supports this? I'm surprised, but I guess it's nice for small/trivial projects which want to use tox as their environment manager. I am quite hesitant to move the tox config around. tox configuration is significant in complexity and IMO it justifies having a dedicated config file. I'm super-happy to learn about this being supported (thank you for that!), but I'm not enthused about moving the existing config.

Moving it around strikes me a lot like the PR to use ruff -- which I accepted, and then had a bunch of issues with and had to revert. Turns out, "here's a helpful PR to switch you to ruff" was something that ate up my time and didn't help me maintain the project. I would like to be focused in how I spend time on nose2 because I have too many projects to keep track of. If the change doesn't really help with maintenance, I'm going to be reticent to accept it. (Doubly so having been burned once already on this front.)


Summary:

JCHacking commented 7 months ago

All right, then we leave it at that. If we see that at some point it brings some extra benefit to move tox within pyproject we will go ahead with the consolidation, now just to move coverage I don't think it's worth it.

sirosen commented 7 months ago

:+1: That's about where I land.

I might do coverage config just because it's small and easy, but even then we add a requirement for tomllib on older pythons. It actually (coincidentally) might become more of an easy win if I do the cleanup on that TOML support PR, since we'll have tomllib for our own needs in that case.