Implement --devenv #1326
Implement --devenv #1326
Conversation
There was a problem hiding this comment.
Why is this better than tox -e py37 --develop --notest, it's much more expressive and gives the user the choice of python interpreter to use? If you want to create the env at root level rather than in .tox I would much prefer to expose the envdir via a CLI option. So maybe do then tox -e py37 --develop --notest --envdir=venv, which could be aliased in the user shell for a quick go.
|
My initial goal was to replace this (incorrect) copypasta in all of my projects: https://github.com/pre-commit/pre-commit/blob/0b6a39768aa1eeee937b5146d35eb69edbc4715b/tox.ini#L17-L19 (it should have But then I realized I could make it much easier to use and support all of the various toxenvs. I also wanted a command that would be easy to type (without needing to remember three options). I settled on The main reason not to use
$ tox --devenv venv37 -e py37
py37 create: /tmp/tox/venv37
py37 installdeps: pip == 19.1.1
py37 develop-inst: /tmp/tox
py37 installed: apipkg==1.5,atomicwrites==1.3.0,attrs==19.1.0,coverage==4.5.3,execnet==1.6.0,filelock==3.0.12,flaky==3.5.3,freezegun==0.3.11,importlib-metadata==0.15,more-itertools==7.0.0,packaging==19.0,pathlib2==2.3.3,pluggy==0.12.0,psutil==5.6.2,py==1.8.0,pyparsing==2.4.0,pytest==4.5.0,pytest-cov==2.7.1,pytest-forked==1.0.2,pytest-mock==1.10.4,pytest-randomly==1.2.3,pytest-xdist==1.28.0,python-dateutil==2.8.0,six==1.12.0,toml==0.10.0,-e git+git@github.com:tox-dev/tox@2a7f94068afeaef90ea6a00f980dc04b012c21a6#egg=tox,virtualenv==16.6.0,wcwidth==0.1.7,zipp==0.5.1
___________________________________ summary ____________________________________
py37: skipped tests
congratulations :)
$ ./venv37/bin/python --version
Python 3.7.3
$ tox --devenv venv35 -e py35
py35 create: /tmp/tox/venv35
py35 installdeps: pip == 19.1.1
py35 develop-inst: /tmp/tox
py35 installed: apipkg==1.5,atomicwrites==1.3.0,attrs==19.1.0,coverage==4.5.3,execnet==1.6.0,filelock==3.0.12,flaky==3.5.3,freezegun==0.3.11,importlib-metadata==0.15,more-itertools==7.0.0,packaging==19.0,pathlib2==2.3.3,pluggy==0.12.0,psutil==5.6.2,py==1.8.0,pyparsing==2.4.0,pytest==4.5.0,pytest-cov==2.7.1,pytest-forked==1.0.2,pytest-mock==1.10.4,pytest-randomly==1.2.3,pytest-xdist==1.28.0,python-dateutil==2.8.0,six==1.12.0,toml==0.10.0,-e git+git@github.com:tox-dev/tox@2a7f94068afeaef90ea6a00f980dc04b012c21a6#egg=tox,virtualenv==16.6.0,wcwidth==0.1.7,zipp==0.5.1
___________________________________ summary ____________________________________
py35: skipped tests
congratulations :)
$ ./venv35/bin/python --version
Python 3.5.7
|
|
I'm worried a bit the
|
|
yeah happy to fill out the docs on this -- wanted some feedback before I poured work into that though 😆 👍 |
|
Just my two cents, but my initial reaction is -0. tox is fundamentally a test/CI tool and isn't really intended to manage the development environment. My main concern is that this feels like scope creep and will add unexpected complexity in how various features/options interact. I'd argue that this should exist as a plugin. But again, -0 so not strongly opinionated on this. |
|
@asottile is this still on? 😄 |
|
Yeah this week has been Hella busy, going to work on this on the weekend |
|
|
|
I really like the idea except for having any tox created environments outside of
I understand that, but I think this is a matter of communicating what the So how about completely taking away the freedom of naming the devenv and placing it in One of the above examples would look something like that then: |
|
putting it in .tox defeats my goals. I want it to replace the current directions of |
|
I'm fine in the end with Anthonys proposal. Both Visual Studio code and Pycharm doesn't handle well .tox folder, but do great with a venv folder. So let's go with this 👌 ahead |
FWIW that's exactly what I routinely use tox for. It is also recommended in the docs. So the scope has already crept :) You have a point though in questioning if we really need a different way of doing this, or if the existing explicit, project specific approach is good enough. Speaking for myself: for most projects I am involved in, the way it is documented is good enough and also more explicit as the Maybe it might also be worth considering #634 if more of these kinds of scenarios pop up?
[...]
Like I said: I really feel like I am still missing something. Everything in So what is the advantage of having a tox generated environment outside of |
|
I know @ambv uses a wrapper script to achieve similar effect, I'm fine with offering it out of box, especially as requires little maintainence, and I feel will make easier to use tox for many people (we could also fight it with documentation, but why bother if this makes it easier to use and understand). |
|
The hidden But that's all fine, I could accomplish that today, however it would require an absolute ton of boilerplate. Consider the following tox.ini which is ~basically the standard one I use everywhere -- I've reduced it to almost no boilerplate for discussion: [tox]
envlist = py27,py36,py37,py38,pypy,pypy3,pre-commit
[testenv]
deps = -rrequirements-dev.txt
commands =
coverage erase
coverage run -m pytest {posargs:tests}
coverage report --fail-under 100
pre-commit install
[testenv:pre-commit]
skip_install = true
deps = pre-commit
commands = pre-commit run --all-files --show-diff-on-failureNow let's say I wanted an easy way to make those environments into devenvs, I would need to make 7 additional environments, each with [testenv:devenv-py27]
basepython=python2.7
envdir=venv-py27
usedevelop=true
commands=That's an absolute boatload of error prone duplication and boilerplate (assuming I separate each by a newline that adds 42 lines to my 14 line tox.ini (!!!). Most of which I wouldn't even use! Whereas with technically with |
|
I still don't agree with the idea that anything tox related should be created outside of If the default of Let's enter the mind of a hypothetical developer that is mildly experienced in the use of tox and has built up a set of (reasonable - I might add) assumptions about how the tool works: megacalc dev: So I see that new switch popping up with the new release of tox. When I type
megacalc dev: Sounds interesting. "based on the tox configuration" ... whatever that means ... I guess that means I just give it some name and then it creates a development environment for me and if I don't say anything extra it will use the first environment in my envlist? Shall I have a look at the documentation? Nah I'll just try it. What can go wrong? From my experience with tox I know that the environment will be placed in the megacalc dev: So I type ...
megacalc dev: Where are my I don't think the potential for damage is worth the extra convenience of not having to explicitly request the creation outside of its managed folder. Next thing that might surprise a mildly experienced tox user:
legacy dev: I guess that means that all my default factors and such works like I am used to by now, so I can create a development environment based on python2.7 by typing
legacy dev: ok the name is "py27" but if I use it I get syntax errors regarding my print statements ... I guess I am understanding something wrong. That's why I still prefer describing the development environment(s) explicitly in the There are also project where development environments as such make no sense at all, but now it's an option for all projects. |
|
sounds like an easy docs fix, to be fair the |
|
The difference is: one is default and one is explicitly configured, so it's not a docs fix - it's a real risk in the default usage, so I am really strongly -1 on shipping this like that. We neutered envdir to not be able to delete the whole project due to #352 btw. I also hope that before someone sets |
|
I added a test to ensure that doesn't happen: #1333 (it currently was ignoring |
|
I don't share your worries Oliver on this to be honest and by talking to some users I feel this will make people worry less about using .tox hidden folder. Yes we can try to document it but people reading it is unlikely, as opposed to doing a --help. Making it easier to use for newcomers is something that is going to help us with adoption. |
That is where we differ. I think setting the default rootdir for I think sensible defaults are very important. If we are talking about making it easy for newcomers we should care about consistent behaviour to provide a clear mental model about the tool. So again: if you can say: "every virtual environment that tox creates ends up in |
|
While this may seem an extra layer of complication for total newcomers, I
think it will help a lot with intermediate people who already are used to
virtualennvs. As much as we would like to think people learn python with
tox, chances are they'll learn first virtualenvs. You don't have to
introduce new users to the devenv straight away, and if you do want if you
first teach them basic virtualenv interface, they should be fine IMHO.
…On Sun, Jun 2, 2019, 07:51 Oliver Bestwalter ***@***.***> wrote:
Making it easier to use for newcomers is something that is going to help
us with adoption.
That is where we differ. I think setting the default rootdir for --devenv
to {toxinidir} instead of the "natural" {toxworkdir} does not help
newcomers. I understand where it's coming from, but I still think that in
the long run we're better off. At the moment it's simple: all environments
that tox creates end up in {toxworkdir} by default. That's why it's called
toxworkdir after all.
I think sensible defaults are *very* important. ~/.virtualenvs is also a
very common place to put venvs but I would also not recommend that as a
sensible default for tox generated venvs just like I wouldn't recommend
{toxinidir} as sensible default.
If we are talking about making it easy for newcomers we should care about
consistent behaviour to provide a clear mental model about the tool. So
again: if you can say: "every virtual environment that tox creates ends up
in .tox by default" that is easy to explain to newcomers. As opposed to:
"some virtual environments that tox creates end up in .tox by default
some don't - it's complicated".
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#1326?email_source=notifications&email_token=AAFIQPUUA73OG3R4JQVTOOTPYNUY5A5CNFSM4HP7PYHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWXPGXY#issuecomment-498004831>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAFIQPQXYKWQDWKXMRLV6PLPYNUY5ANCNFSM4HP7PYHA>
.
|
|
Well, it's all a guessing game anyway. We all see different slices of the user base and we don't really know who's using what, why and how. Let's just see how this plays out then 👍 |
|
So, a year late to the party, but I just want to say AWESOME! 💃 Thanks for adding this. |
This implements an option which makes it very easy to set up development virtualenvs based on the existing
[testenv]configurations.Contribution checklist:
(also see CONTRIBUTING.rst for details)
in message body
<issue number>.<type>.rstfor example (588.bugfix.rst)<type>is must be one ofbugfix,feature,deprecation,breaking,doc,misc<your username>"superuser."CONTRIBUTORS(preserving alphabetical order)