Open bennyrowland opened 2 years ago
Can you at least provide some details about versions and such? A reproducer would be even better.
Fair point. Python 3.8.10 and 3.9.13 are my tox envs tox 3.25.1 tox-wheel HEAD because I am using build to create my wheels (although I have seen the same problem with pep517)
I have experienced this many times but haven't been able to reliably reproduce exactly under what circumstances it happens (I have usually just run tox -r
which works but is very slow, moving to changing install_command
is a new and better fix for me). Running tox -vvv
just now gave me the following output:
py39 inst-nodeps: H:\Python\hqmonitor\.tox\.tmp\package\3\hqmonitor-1.0.0a3.dev7+g127c7ad.d20220916-py3-none-any.whl
setting PATH=H:\Python\hqmonitor\.tox\py39\Scripts;H:\test_venv\Scripts;...
[1784] H:\Python\hqmonitor$ 'H:\Python\hqmonitor\.tox\py39\Scripts\python.EXE' -m pip install --no-deps -U -v 'H:\Python\hqmonitor\.tox\.tmp\package\3\hqmonitor-1.0.0a3.dev7+g127c7ad.d20220916-py3-none-any.whl[dev]'
Using pip 22.2.2 from H:\Python\hqmonitor\.tox\py39\lib\site-packages\pip (python 3.9)
Looking in indexes: https://pypi.org/simple
Processing h:\python\hqmonitor\.tox\.tmp\package\3\hqmonitor-1.0.0a3.dev7+g127c7ad.d20220916-py3-none-any.whl
hqmonitor is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel.
I am not sure why this hasn't been more of an obvious problem before, maybe I am doing something that makes pip have a more stringent comparison of previously installed vs new wheels?
I have experienced the same thing. Some of my libs do it, and some don't. The output of tox doesn't seem indicate any difference.
...
Copying ep_telemetry.egg-info to build/bdist.linux-x86_64/wheel/ep_telemetry-0.1.0-py3.8.egg-info
running install_scripts
creating build/bdist.linux-x86_64/wheel/ep_telemetry-0.1.0.dist-info/WHEEL
creating '.tox/dist/ep_telemetry-0.1.0-cp38-cp38-linux_x86_64.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
adding 'ep_telemetry/__init__.py'
adding 'ep_telemetry/_ep_telemetry.cpython-38-x86_64-linux-gnu.so'
adding 'ep_telemetry-0.1.0.dist-info/METADATA'
adding 'ep_telemetry-0.1.0.dist-info/WHEEL'
adding 'ep_telemetry-0.1.0.dist-info/top_level.txt'
adding 'ep_telemetry-0.1.0.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
...
py3 inst-nodeps: /home/john/src/btp/lib-py-ep-telemetry/.tox/.tmp/package/1/ep_telemetry-0.1.0-cp38-cp38-linux_x86_64.whl
py3 installed: attrs==22.1.0,coverage==6.5.0,distlib==0.3.6,ep-telemetry @ file:///home/john/src/btp/lib-py-ep-telemetry/.tox/.tmp/package/1/ep_telemetry-0.1.0-cp38-cp38-linux_x86_64.whl,filelock==3.8.0,iniconfig==1.1.1,packaging==21.3,platformdirs==2.5.2,pluggy==1.0.0,py==1.11.0,pyparsing==3.0.9,pytest==7.1.3,pytest-cov==4.0.0,six==1.16.0,tomli==2.0.1,tox==3.26.0,virtualenv==20.16.5
...
But, the new ep_telemetry package isn't really updated..
Now that I think about it more I could only document this problem. I can't really mess with the install command since users might want to customize that. Either way... maybe make a request in the tox bug tracker to always use the -I
option?
I have encountered issues where I get a test failure in tox, change the code and re-run, then get the same test failure with the old code. This seems to be because although tox-wheel builds the new wheel with the new code, the install step fails to actually install it, presumably because there is a previously installed copy of the same wheel with the same version. If I manually uninstall the package from the venv, or change tox's
install_command
to use the-I
flag and ignore the installed package then the behaviour goes away, but it would be nice to try and make this automatic so the user doesn't have anything to manually change to use the plugin.Looking at the tox plugin hooks, the only plausible place I can see to put such a mechanism is in the
tox_package()
hook - presumably we can insert some command in there topip uninstall package
, possibly testing first to see if it is installed etc. Happy to receive alternative suggestions or a different solution to the problem, otherwise I will probably have a play-around and see if I can get something working along these lines next week.