-
-
Notifications
You must be signed in to change notification settings - Fork 523
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
Please add a [tox]default_envlist setting #223
Comments
Original comment by @warsaw I've been thinking about this lately and I think I might have an elegant way to define env groups. E.g.:
and so on. Then if you run It borrows the syntax for generated environments, but it seems pretty intuitive. What do you think? |
Original comment by @warsaw Groups is a pretty neat idea actually. I could imagine you'd have an |
Original comment by @hpk42 I sympathize with the idea. Would it make sense to introduce "groups" which you can select with I can imagine others might simply want to specify a factor like "tox --select-factor fast". or "tox --select-factor coverage". maybe your suggestion is sufficient and i am going a bit overboard, not sure ATM. |
As the idea of grouping envs is likely to be a nice solution for this I'll close this in favour of #238. Hope that's alright. |
Maybe I'm missing something obvious, but I think I want a way to both define a bunch of environments, including some generated ones, but I also want tox-with-no-args to only run a few of them by default.
For example:
Now, if I run just
tox
it will run all these tests. But I want to make it easy for my users and CI system to only run a few of those environments by default. So I'd like fortox
with no arguments to e.g., only run fast-py27 and fast-py34.Then, if they say something like
tox --all
it would run all environments. One thought would be to add something like:and that would be the no-arg set of environments that get run.
--all
would ignore default_envlist.I guess this can work with an explicit -e option and the current default to run all environments, but it's a little less convenient because the set of all environments could change and then I'd have to retool my CI or update my README, etc.
Or is this a dumb idea? ;)
The text was updated successfully, but these errors were encountered: