From issues-reply at bitbucket.org Thu Jul 7 15:16:34 2016 From: issues-reply at bitbucket.org (enok123) Date: Thu, 07 Jul 2016 19:16:34 -0000 Subject: [Pytest-commit] Issue #342: pyYaml install fails on Windows 10 (hpk42/tox) Message-ID: <20160707191634.71042.19595@celery-worker-102.ash1.bb-inf.net> New issue 342: pyYaml install fails on Windows 10 https://bitbucket.org/hpk42/tox/issues/342/pyyaml-install-fails-on-windows-10 enok123: My tox.ini file looks like this on windows ``` #!python [tox] envlist = cpy27,dpy27 skip_missing_interpreters = True [testenv] basepython = cpy27: C:\Python27\python.exe dpy27: D:\Python27\python.exe deps = pytest commands = py.test tests ``` But when I do "tox" from command prompt, I'm seeing this error. Why is this? I don't see any error, if I run [ python setup.py install](Link URL) [Installing collected packages: coverage, pytest-cov, requests, psutil, pytz, enum, argh, pathtools, PyYAML, watchdog, monit Running setup.py install for PyYAML: started Running setup.py install for PyYAML: finished with status 'error' Complete output from command d:\repos\wevedata\datapipeline\monit\.tox\dpy27\scripts\python.exe -u -c "import setuptools, tokenize;__file__='c:\\users\\vikone\\appdata\\local\\temp\\pip-build-bbx8kz\\PyYAML\\setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record c:\users\vikone\appdata\local\temp\pip-zyvbbh-record\install-record.txt --single-version-externally-managed --compile --install-headers d:\repos\wevedata\datapipeline\monit\.tox\dpy27\include\site\python2.7\PyYAML: running install running build running build_py creating build creating build\lib.win-amd64-2.7 creating build\lib.win-amd64-2.7\yaml copying lib\yaml\composer.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\constructor.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\cyaml.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\dumper.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\emitter.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\error.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\events.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\loader.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\nodes.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\parser.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\reader.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\representer.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\resolver.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\scanner.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\serializer.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\tokens.py -> build\lib.win-amd64-2.7\yaml copying lib\yaml\__init__.py -> build\lib.win-amd64-2.7\yaml running build_ext creating build\temp.win-amd64-2.7 creating build\temp.win-amd64-2.7\Release checking if libyaml is compilable error: [Error 2] The system cannot find the file specified ----------------------------------------](Link URL) From issues-reply at bitbucket.org Mon Jul 11 23:55:21 2016 From: issues-reply at bitbucket.org (Amber Brown) Date: Tue, 12 Jul 2016 03:55:21 -0000 Subject: [Pytest-commit] Issue #343: Tox will not force installation of the package under test on initial virtualenv creation (hpk42/tox) Message-ID: <20160712035521.26202.72142@celery-worker-103.ash1.bb-inf.net> New issue 343: Tox will not force installation of the package under test on initial virtualenv creation https://bitbucket.org/hpk42/tox/issues/343/tox-will-not-force-installation-of-the Amber Brown: Twisted includes some tests that operate PyDoctor, and PyDoctor depends on Twisted. So, if I put "pydoctor" under deps, and then do `tox -r -e myenv`, it will install Twisted from PyPI. This is fine, but it won't install the Twisted under test (which, right now, has the same version number), meaning that I'm actually testing the released 16.3.0, not my 16.3.0+some commits. If I subsequently run `tox -e myenv`, it will correctly install the Twisted under test into the environment. From issues-reply at bitbucket.org Tue Jul 12 13:15:23 2016 From: issues-reply at bitbucket.org (=?utf-8?q?=C5=81ukasz_Rogalski?=) Date: Tue, 12 Jul 2016 17:15:23 -0000 Subject: [Pytest-commit] Issue #344: Consider normalizing path separators in setenv for PATH variables (hpk42/tox) Message-ID: <20160712171523.21914.33738@celery-worker-101.ash1.bb-inf.net> New issue 344: Consider normalizing path separators in setenv for PATH variables https://bitbucket.org/hpk42/tox/issues/344/consider-normalizing-path-separators-in ?ukasz Rogalski: Consider following extract from tox.ini: ``` #!ini [testenv] setenv = PYTHONPATH={toxinidir}/a/;{toxinidir}/b/ ``` Path separator used for PYTHONPATH (and PATH variables) is platform specific - so invocation above would work on Windows but would not on POSIX system. While usually it's solved via testing matrix, I'm not sure if that's a correct approach here. User intention is to add multiple paths to environment variable, and copy-pasting same path list and changing only their separator is a clear violation of DRY. I was thinking about few strategies: - always normalizing separators in PATH and PYTHONPATH variables (from colon or semicolon to `os.pathsep`). I'm not sure if it's smart to maintain any kind of whitelist in docs. Also, explicit is better than implicit, and here conversion would be performed implicitly. - export `{os.pathsep}` as possible substitute - explicit, easy, but results in kind of ugly looking tox.ini - add optional field in tox.ini `env_path_vars = PATH,PYTHONPATH` - normalization would be performed only for explicitly selected environment variables. It looks clean, but adds additional config parameter. I'd be happy to implement any of these (if proposal will be accepted) - the question is, which proposal do you like the most? Regards, Lukasz From issues-reply at bitbucket.org Wed Jul 13 10:10:31 2016 From: issues-reply at bitbucket.org (John Vandenberg) Date: Wed, 13 Jul 2016 14:10:31 -0000 Subject: [Pytest-commit] Issue #345: PyPy3 5.2 (hpk42/tox) Message-ID: <20160713141031.33512.56056@celery-worker-101.ash1.bb-inf.net> New issue 345: PyPy3 5.2 https://bitbucket.org/hpk42/tox/issues/345/pypy3-52 John Vandenberg: PyPy3 5.2 is in alpha releases now, targeting Python 3.3.5 compatibility http://doc.pypy.org/en/latest/release-pypy3.3-v5.2-alpha1.html It installs a `pypy3.3` binary with a `pypy3` symlink. It seems that vendors may be happy to replace their 'pypy3' package that is PyPy 2.4 https://packages.gentoo.org/packages/virtual/pypy3 https://bugzilla.redhat.com/show_bug.cgi?id=1353595 In which case, there is a strong argument that the `tox.config.default_factors` entry for `pypy3` should continue to point to executable `pypy3`, which could be either PyPy 2.4 or PyPy 5.2 depending on which is in the `PATH` first. However that means that `pypy3` factor maps to either Python lang 3.2 or 3.3, which are two very different beasts. There will be many packages that can support the new PyPy3 5.2 , but do not intend to support the old `pypy3`, and they would normally describe that in `tox.ini` `envlist` by listing a default factor for each supported version. And then what happens when PyPy releases a Python lang 3.4 compatible version. Is it also `pypy3`? One alternative is to add `pypy3x` default factors, pointing at executables `pypy3.x`, which PyPy3 installs by default (and pypy2.7 for that matter). Another is to detect PyPy language compatibility and map them to both factor `py3x` and factor `pypy3`, so that e.g. env `py32-pypy3` and `py33-pypy3` can be used if someone needs to distinguish between the two, and they will also fall back to a `pypy3` env if it exists, or py32 or py33 if those factors are used in an env name. From builds at drone.io Wed Jul 13 11:53:39 2016 From: builds at drone.io (Drone.io Build) Date: Wed, 13 Jul 2016 15:53:39 +0000 Subject: [Pytest-commit] [FAIL] py - # 26 Message-ID: <20160713155339.24729.94348.F4ECA3B4@drone.io> Build Failed Build : https://drone.io/bitbucket.org/pytest-dev/py/26 Project : https://drone.io/bitbucket.org/pytest-dev/py Repository : https://bitbucket.org/pytest-dev/py Version : 2315:2adcf5aae1dd Author : Floris Bruynooghe Branch : default Message: Merged in lvtstx/py/issue80 (pull request #38) -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at drone.io Wed Jul 13 12:05:14 2016 From: builds at drone.io (Drone.io Build) Date: Wed, 13 Jul 2016 16:05:14 +0000 Subject: [Pytest-commit] [FAIL] py - # 25 Message-ID: <20160713155253.14751.88901.210A0805@drone.io> Build Failed Build : https://drone.io/bitbucket.org/pytest-dev/py/25 Project : https://drone.io/bitbucket.org/pytest-dev/py Repository : https://bitbucket.org/pytest-dev/py Version : 2315:2adcf5aae1dd Author : Floris Bruynooghe Branch : default Message: Merged in lvtstx/py/issue80 (pull request #38) -------------- next part -------------- An HTML attachment was scrubbed... URL: From issues-reply at bitbucket.org Thu Jul 14 17:40:36 2016 From: issues-reply at bitbucket.org (Severen Redwood) Date: Thu, 14 Jul 2016 21:40:36 -0000 Subject: [Pytest-commit] Issue #346: Tox should adhere to the XDG BaseDir standard on Linux and possibly OS X (hpk42/tox) Message-ID: <20160714214036.17892.90760@celery-worker-101.ash1.bb-inf.net> New issue 346: Tox should adhere to the XDG BaseDir standard on Linux and possibly OS X https://bitbucket.org/hpk42/tox/issues/346/tox-should-adhere-to-the-xdg-basedir Severen Redwood: You can find the specification [here](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). This [blog post](https://ploum.net/207-modify-your-application-to-use-xdg-folders/) lists the advantages of using the XDG Base Directory Specification as follows: - `$HOME` is a lot less cluttered. - Backups are a lot more safer and easier (you know that creating a backup of your `$XDG_DATA_HOME` along with your files is enough). - A lot easier to reset a default configuration if you want/need it (and without any risk of losing information). - Avoid some strange bugs that happen because you had a old version of some configuration file. - It is a lot more flexible and portable because no paths are hard-coded. You can use the XDG library that does the job for you _or_, if you don?t want the dependency, implementing the XDG specification is only a few lines of code. For example, what is currently `~/.tox/distshare` would be `~/.cache/tox/distshare` or something similar. From issues-reply at bitbucket.org Tue Jul 19 15:54:50 2016 From: issues-reply at bitbucket.org (Tobias McNulty) Date: Tue, 19 Jul 2016 19:54:50 -0000 Subject: [Pytest-commit] Issue #347: Default environment list does not include py35 (hpk42/tox) Message-ID: <20160719195450.2951.49863@celery-worker-104.ash1.bb-inf.net> New issue 347: Default environment list does not include py35 https://bitbucket.org/hpk42/tox/issues/347/default-environment-list-does-not-include Tobias McNulty: This list does not appear to be up to date, although Tox does support Python 3.5: https://testrun.org/tox/latest/example/basic.html From issues-reply at bitbucket.org Tue Jul 19 16:12:41 2016 From: issues-reply at bitbucket.org (Tobias McNulty) Date: Tue, 19 Jul 2016 20:12:41 -0000 Subject: [Pytest-commit] Issue #348: Consider supporting 'py2' and 'py3' default environments (hpk42/tox) Message-ID: <20160719201241.5516.24842@celery-worker-103.ash1.bb-inf.net> New issue 348: Consider supporting 'py2' and 'py3' default environments https://bitbucket.org/hpk42/tox/issues/348/consider-supporting-py2-and-py3-default Tobias McNulty: For packages where I want to test *some* version of python3 but I don't really care which one, support for ``py2` and `py3` environments would be nice, e.g.: [testenv:py2] basepython = python2 [testenv:py3] basepython = python3 I can create these easily enough myself, but thought I'd submit this issue in case anyone else would find it useful. From issues-reply at bitbucket.org Tue Jul 19 23:40:32 2016 From: issues-reply at bitbucket.org (Martin Pelikan) Date: Wed, 20 Jul 2016 03:40:32 -0000 Subject: [Pytest-commit] Issue #349: Cross-section value substitution does not work for passenv. (hpk42/tox) Message-ID: <20160720034032.37683.80824@celery-worker-102.ash1.bb-inf.net> New issue 349: Cross-section value substitution does not work for passenv. https://bitbucket.org/hpk42/tox/issues/349/cross-section-value-substitution-does-not Martin Pelikan: This is a minimal snippet from a tox.ini, but should be sufficient to reproduce the issue. ``` #!config [jenkins] passenv = BUILD_URL [testenv:my-jenkins-job] passenv = {[jenkins]passenv} ``` ``` #!sh tox --showconfig | grep passenv ``` You would expect *BUILD_URL* to show up in the *passenv* value of that *testenv* section, but it does not. Doing the same thing with *deps* works. From issues-reply at bitbucket.org Sat Jul 23 10:29:06 2016 From: issues-reply at bitbucket.org (James Tocknell) Date: Sat, 23 Jul 2016 14:29:06 -0000 Subject: [Pytest-commit] Issue #350: Support installing deps before setup.py sdist (hpk42/tox) Message-ID: <20160723142906.25067.83689@celery-worker-102.ash1.bb-inf.net> New issue 350: Support installing deps before setup.py sdist https://bitbucket.org/hpk42/tox/issues/350/support-installing-deps-before-setuppy James Tocknell: Some projects require dependencies to be installed before calling setup.py, it'd be nice to be able to do this (rather than trying to work around this by not building the sdist). From issues-reply at bitbucket.org Sat Jul 23 13:07:31 2016 From: issues-reply at bitbucket.org (John Vandenberg) Date: Sat, 23 Jul 2016 17:07:31 -0000 Subject: [Pytest-commit] Issue #351: deps = {posargs} (hpk42/tox) Message-ID: <20160723170731.31228.5400@celery-worker-102.ash1.bb-inf.net> New issue 351: deps = {posargs} https://bitbucket.org/hpk42/tox/issues/351/deps-posargs John Vandenberg: Sometimes it is useful to install a set of packages to alter the behaviour of a test run. Two cases where I have thought this was useful was with `flake8-putty`, where I install sets of plugins to check my plugin with. https://github.com/jayvdb/flake8-putty/blob/bac9533cc7fc7854c14657b35d8e07da99d5757f/tox.ini (obviously I would need to change things a little, adding a new testenv for using {posargs} as requirements instead of as filenames. The current case is `pyflakes`, where I want to install packages into the venv and then check their syntax. For `deps = {posargs}`, each positional argument would need to be a complete requirement with environment marker, i.e. any spaces wrapped in `".. "`, and they would need to be added to the `deps` as a separate line for each argument. `deps = {posargs}` currently crashes on `tox.ConfigError: ConfigError: substitution key 'posargs' not found` From issues-reply at bitbucket.org Tue Jul 26 22:50:59 2016 From: issues-reply at bitbucket.org (Andrew Tipton) Date: Wed, 27 Jul 2016 02:50:59 -0000 Subject: [Pytest-commit] Issue #352: TOX DELETED ALL OF MY CODE (hpk42/tox) Message-ID: <20160727025059.16867.35407@celery-worker-103.ash1.bb-inf.net> New issue 352: TOX DELETED ALL OF MY CODE https://bitbucket.org/hpk42/tox/issues/352/tox-deleted-all-of-my-code Andrew Tipton: TL;DR: due to a (slightly) wrong `tox` invocation... tox punished me by deleting all of the files in my project. Transcript of my shell session: ``` $ pwd /home/andrew/tmp/dataplanet $ ls -l total 44 4 -rw-r--r-- 1 andrew andrew 311 Jul 27 10:47 bitbucket-pipelines.yml 4 drwxr-xr-x 2 andrew andrew 4096 Jul 27 10:47 docs 4 -rw-r--r-- 1 andrew andrew 167 Jul 27 10:47 MANIFEST.in 8 -rw-r--r-- 1 andrew andrew 4308 Jul 27 10:47 README 4 -rw-r--r-- 1 andrew andrew 1021 Jul 27 10:47 setup.cfg 4 -rw-r--r-- 1 andrew andrew 1564 Jul 27 10:47 setup.py 4 drwxr-xr-x 4 andrew andrew 4096 Jul 27 10:47 src 4 drwxr-xr-x 2 andrew andrew 4096 Jul 27 10:47 tests 4 -rw-r--r-- 1 andrew andrew 998 Jul 27 10:47 TODO 4 -rw-r--r-- 1 andrew andrew 1147 Jul 27 10:47 tox.ini $ tox -e tests GLOB sdist-make: /home/andrew/tmp/dataplanet/setup.py tests create: /home/andrew/tmp/dataplanet ERROR: invocation failed (exit code 1), logfile: /home/andrew/tmp/dataplanet/log/tests-0.log ERROR: actionid: tests msg: getenv cmdargs: ['/usr/bin/python3', '-m', 'virtualenv', '--python', '/usr/bin/python3', 'dataplanet'] ERROR: InvocationError: /usr/bin/python3 -m virtualenv --python /usr/bin/python3 dataplanet (see /home/andrew/tmp/dataplanet/log/tests-0.log) env: {... environment variables omitted ...} Traceback (most recent call last): File "/home/andrew/.local/lib/python3.4/site-packages/virtualenv.py", line 840, in install_wheel from urlparse import urljoin ImportError: No module named 'urlparse' _________________________________________________________________ summary __________________________________________________________________ ERROR: tests: InvocationError: /usr/bin/python3 -m virtualenv --python /usr/bin/python3 dataplanet (see /home/andrew/tmp/dataplanet/log/tests-0.log) andrew at ip-10-0-20-167:~/tmp/dataplanet> total 0 $ pwd /home/andrew/tmp/dataplanet $ cd ../dataplanet $ ls -l total 16 4 drwxr-xr-x 2 andrew andrew 4096 Jul 27 10:39 bin 4 drwxr-xr-x 2 andrew andrew 4096 Jul 27 10:39 include 4 drwxr-xr-x 3 andrew andrew 4096 Jul 27 10:39 lib 4 drwxr-xr-x 2 andrew andrew 4096 Jul 27 10:39 log $ pwd /home/andrew/tmp/dataplanet ``` Here's a minimal `tox.ini` that will reproduce the problem: ``` [tox] envlist = check, py34-tests [testenv] envdir= check: {toxworkdir}/py py34: {toxworkdir}/py34 skip_install= check: true tests: false deps= check: flake8 tests: pytest commands= check: flake8 --show-source {toxinidir}/src tests: py.test --strict --doctest-modules {toxinidir}/tests ``` Did you see what happened there? I *meant* to run `tox -e py34-tests`, but instead ran `tox -e tests`. This somehow resulted in `{toxworkdir}` getting set to `{toxinidir}` (!!!) and as a result tox helpfully deleted my project's code and replaced it with a tox working directory.... *THIS IS NOT ACCEPTABLE BEHAVIOUR.* In case you're wondering "why configure things in this particular manner?", my full configuration has additional environments e.g. `py27-tests`, `py34-docs`, `py34-build`, etc. and I want to speed things up by sharing the working directory between these different targets. (That is, I want exactly one `toxworkdir` per Python version.)