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

Consider tox.ini to be frozen? #1123

Closed
obestwalter opened this issue Jan 7, 2019 · 4 comments
Closed

Consider tox.ini to be frozen? #1123

obestwalter opened this issue Jan 7, 2019 · 4 comments
Labels
area:configuration needs:discussion It's not quite clear if and how this should be done

Comments

@obestwalter
Copy link
Member

obestwalter commented Jan 7, 2019

As mentioned in several places already I would like to declare the old tox.ini format as "done" and all future changes should be considered for the upcoming pyproject.toml based format discussed in #999.

The old format as it is should be documented completely (I started collecting the missing parts that were never documented properly at the moment) and then declared feature complete.

Bugs can and should still be fixed with the caveat that it might be hard to decide nowadays what a bug and what a feature is in that format 😆

@obestwalter obestwalter added needs:discussion It's not quite clear if and how this should be done area:configuration labels Jan 7, 2019
@gaborbernat
Copy link
Member

Well I would consider doing this only after we're finished with a feature parity toml configuration format. No need to rush ahead and freeze something before we can point to a better alternative.

@obestwalter
Copy link
Member Author

Well I would consider doing this only after we're finished with a feature parity toml configuration format.

You could also argue from the position that the existing format is "good enough" inependent of an alternative. It might seem strange in the realms of software but things can be just done sometimes and don't need eternal expansion and improvement :)

For the existing tox config I feel that way because there are to many things you can't fix properly anymore anyway, because they grew like they did and people rely on that behaviour (may it be documented or not). See #1121 and #1113 for recent examples.

So we do not necessarily have to have something better to point to, when what we have is good enough for 90% of the users. Deciding not to work on these topics in the old format would also free up time to work on the new one.

@gaborbernat
Copy link
Member

@obestwalter I think the difference is that I'm not convinced what we would come up would be any better. I view that more as an experiment, rather than definitive go-ahead direction. Once the experiment becomes successful we can decide to drop the old one. However, we might conclude that what we have at the moment is still the best, in which case we may just continue on with it. I know the ini is not perfect, but from my experience, the toml also has its drawbacks. I would be reluctant to stop the progress of either of those. Let's instead leave people to decide what they like rather than us enforcing it. Furthermore, if the new format will require us breaking all existing plugins (e.g. #1121 definitely would make it so), I'm personally not a big fan of it. It would basically take us back five year to the time where tox plugins were not a thing until plugin developers migrate (which could be a long time).

@gaborbernat
Copy link
Member

I think until we prove an alternative to be at least as powerful we don't need to consider this, so I'll close it for now.

@tox-dev tox-dev locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area:configuration needs:discussion It's not quite clear if and how this should be done
Projects
None yet
Development

No branches or pull requests

2 participants