Let me know if you are interested adding something like that.
If not, I can create it as external package. I am going to write little wrapper over tox either way (I need some abstraction for other project anyway).
As we are on this one, I've came to conclusion that this whole devenv thing would also be possible if tox would allow user for two more things:
Allow to configure environment directory path
Allow user to instrument tox not to build source distribution. This actually has even one more advantage: it would allow external tools to run tox in parallel more easily (without having to dig deeper into Session codes than runcommand method.
Then we don't have to introduce another switch-like-subcommand (except of course more general --nosdist as described in point 2). This alternative has benefit of being much simpler and is more generic... And this part of documentation would be mostly valid too.
Well, writing documentation was indeed very good idea.
Thanks for the draft, Lukasz! And sorry for taking a while.
It basically looks good, but let's try to re-use as many existing concepts as possible (hence the [testenv:...]).
As to 1): right, we need envdir=... in [testenv*] sections. Affects code in tox/_config.py only i think.
As to 2): yes, maybe a new option --envonly?
Addendum to 2): Maybe a generic -a|--activities option defining e.g. env,sdist,install,test by default and allowing to do less like -a env would cover the case we are discussing. But let's keep this out of this PR i guess.
Are you up for refining the docs (see also inline comments) and coding what is needed?
Ok, envdir was easy - actually, it was already there ;-) So I've only added tests and documented it.
With --envonly switch however, I have a little problem, as we want user to be able to use existing commands config, so it's not only venv creation. I would drop switch for now and would work on --activities you've mentioned in another PR. Am also dropping note from draft - it's better documented at config.txt now.
ah right, so you simply don't want any package build/install step in this devenv. Would it make sense to configure this with the [testenv:devenv] section or is this really something specific to the invocation?
Well, eventually I would like to be able to omit package related steps, that's why I would work on --activities in future. For now, however, it's ok not to omit anything. It's actually cool envdir is there already - this whole devenv example is possible without any changes to tox right now. It just would feel more clean without build/install steps. Moreover, if we would be able to omit package related steps tox can be used to test non-packages (i.e. most Django based projects I'm aware of are not packages and doesn't have setup.py file and yet are easily testable).
k, maybe a "--nopkg omit package build and install steps" options would be good as an immediate measure. You didn't answer my question, however: would it make sense for you to specify something like "nopkg=True" with the [testenv:devenv] section itself?
Oh, sorry. Yeah, being able to add this configuration under testenv section would be better in my view - it's pretty specific to that particular environment.
Am not sure about nopkg, though. I prefer positive bools for doing something, negative for not doing, i.e. simply package should suffice (more readable in my view as there are two logical negations less ;-)). It's your call, though, going to add this, just let me know which name you prefer.