Tox: virtualenv is not recreated when deps change if '-r' is used

[pytoxbot]

• Bitbucket: https://bitbucket.org/hpk42/tox/issue/149
• Originally reported by: @gavrie
• Originally created at: 2014-01-28T15:36:07.365

In my tox.ini, I have the following deps:

deps = -rpackaging/requirements.txt

Normally, when deps change, the virtualenv is recreated by tox.
However, when the contents of requirements.txt change, tox does not notice this and the environment is reused.

A workaround would be to list the deps directly in tox.ini, but that would require duplicating the contents of the existing requirements.txt that is used by other tools.

[pytoxbot]

Original comment by wbyoung

@wmyll6 thanks for the plugin. Hopefully some of that work can make its way into the core!

[pytoxbot]

Original comment by @signalpillar

Hello guys, I've created an experimental project that supports venv recreation on requirements file update.
Maybe it will be useful for you in some way: https://github.com/signalpillar/tox-battery

Implemented using plugin system that was added recently to the tox.

[pytoxbot]

Original comment by hexadite-maxk

This is rather philosophical question: if we want tox to be smart or stupid.
IF we want it stupid - adding new smart features is out of the question.

[pytoxbot]

Original comment by @Merwok

This also happens if dependencies in setup.py (install_requires) change.

[pytoxbot]

Original comment by @hpk42

Within tox-1.9.1 (superseded quickly by 1.9.2) we had some code that parsed requirement files but it was buggy and caused problems.

I am all for adding proper support for dealing with requirement files in deps.

I think that tox will need to support pip==1.5.6 at least if not older versions.

[pytoxbot]

Original comment by @hpk42

If somebody can submit a PR helping with working better with "-r" lines, please do. Note that i just released tox-1.9.1 which contains some code in relation to "--force-deps" which parses requirements.

[pytoxbot]

Original comment by @bukzor

That's only slightly better. Requirement files can and do contain '-r
more.txt' lines to pull in further requirements.

To the dependency concern: tox already has a hard dependency on virtualenv,
which contains a vendored copy of pip. We can make use of this if necessary.

--phone is hard.

[pytoxbot]

Original comment by mhirota

What about recognizing the special case of deps = -r<something> and calculating the md5 based on the file contents? This would trigger recreate if _anything_ in the requirements.txt changed... but I think that might be better than duplicating what is in pip or introducing a hard dependency on pip in tox.

[pytoxbot]

Original comment by @hashar

A way to reproduce:

$ cat tox.ini
[tox]
skipsdist = True

[testenv:venv]
deps = -rrequirements.txt

$ echo -n > requirements.txt
$ tox
...
$ cat .tox/venv/.tox-config1 
00000000000000000000000000000000 /usr/local/opt/python/bin/python2.7
1.8.1 0 0 0
00000000000000000000000000000000 -rrequirements.txt
$

Then add a new requirement and rerun tox:

$ echo pep8 > requirements.txt
$ tox -vvv
$ tox -vvv
  removing /private/tmp/toxdeps/.tox/log
using tox.ini: /private/tmp/toxdeps/tox.ini
using tox-1.8.1 from /usr/local/lib/python2.7/site-packages/tox/__init__.pyc
skipping sdist step
venv start: getenv /private/tmp/toxdeps/.tox/Venn
venv reusing: /private/tmp/toxdeps/.tox/venv
     ^^^^^^^
venv finish: getenv after 0.02 seconds
venv start: finishvenv 
venv finish: finishvenv after 0.00 seconds
...

.tox-config1 remains identical.

VirtualEnv._getresolvedeps() should be made to understand the '-rsomefile.txt' and parse its content, or even better delegate the dependencies resolution to pip itself. pip.req.parse_requirements() has all the logic :-}

[pytoxbot]

Original comment by @asottile

For what it's worth, here's a hacky workaround with a Makefile: http://stackoverflow.com/questions/23032580/reinstall-virtualenv-with-tox-when-requirements-txt-or-setup-py-changes/23039826#23039826

[dimaqq]

Any chance of porting tox-battery here?

[RonnyPfannschmidt]

@dimaqq it already is on github - @signalpillar is the maintainer/owner

[obestwalter]

Are there opinions about how we should deal with this?

I would tend to close this and recommend using tox-battery for now.

[The-Compiler]

I'll have to disagree - this is an issue I hear from various people, and it's quite unexpected. I view it as "tox does caching without invalidating the cache correctly" essentially. The core does caching, so I think it really should do this correctly.

[obestwalter]

o.k. - I stand corrected then :)

[hpk42]

we once had better support for requirements parsing but we had to revert it ... i admit i never extensively used -r requyirements.txt myself and the docs still mark that feature as experimental http://tox.readthedocs.io/en/latest/example/basic.html?highlight=requirements#depending-on-requirements-txt -- someone needs to step up to go for it more properly ... meanwhile recommending to manually use "tox -r" for recreating an env is a kludge to get around tox's ignorance.

[merwok]

FWIW, in my latest project I avoid the issue by using pip-tools. I never recreate virtualenvs, but dependencies (in one or more requirements files, e.g. run.txt and test.txt) are always synchronized, so I get fast failures before commit and CI if I forget to update requirements.

[obestwalter]

@merwok that sounds interesting, but I have no idea what you are talking about - could you link to some documentation/blog/howto/whatever with more details about this approach? Thanks!

[asottile]

@obestwalter one approach (that we're using internally, and will have a better solution for once 2.7.0 ships with my plugin changes :D) is to use https://github.com/Yelp/venv-update -- pip-faster has a --prune which will uninstall extraneous dependencies (and ensure the installed state is exactly what was on the cli)

[ulope]

@obestwalter pip-tools can be used to keep a virtualenv exactly in sync with the requirements.

It's really a great idea to use it in tox. Should have thought of that myself.

[merwok]

It is indeed https://github.com/jazzband/pip-tools

tox.ini:

[testenv]
deps =
    pip-tools == 1.8.1rc3
commands =
    pip-sync requirements.txt requirements-test.txt
    pyflakes project
    pytest {posargs}

pip-sync makes sure new dependencies or updated versions are installed in the virtualenv and removes old dependencies. I don’t duplicate dependencies in tox.ini, I never have to recreate the testenvs, my co-workers never have failures because requirements.txt changed. My deployment also uses pip-sync.

Article from the original developer of pip-tools: http://nvie.com/posts/better-package-management/

pip-tools very recently gained the ability to generate requirements.txt with pinned versions from dependencies in setup.py, so you can have a lib with loose requirements in setup.py and exact pinned versions in requirements-test.txt for your tox testing.

[obestwalter]

Very nice. Thanks for the info. I had build my self built version (something similar to what pip-tools does) for our team projects, that I might be able to throw out now :)

To get back to the original issue: in the light of the fact that this problem is better solved by a tool that can be used by tox maybe it would be better to deprecate the -r option and throw it out in the next major release? I don't use this option either as I had my own solution, but will definitely try pip-tools for this now.

[dimaqq]

I'm very glad to see this discussion coming back to life.

My 2c/experience:

pip-tools is a double-edges sword, it requires a separate pip-compile step, and voila, your one-step build is gone.

venv-update is cool! I think it replicates tox functionality in a way, but conserves resources (and thus shortens build time). Perhaps if it supports same range of interpreters, it could be integrated into tox.

pip-faster is off-topic, can be included in the above.

[gaborbernat]

@asottile can you detail? thanks!

[asottile]

venv-update aims to solve nearly the same thing as pip-tools but does so in a different implementation. Note that while confusing, venv-update and pip-faster are one-and-the-same (there has been some significant confusion in development as we've renamed the project back and forth at least once now!). The usage is almost identical to pip-tools above:

[testenv]
deps = venv-update
commands =
    pip-faster install --prune -r requirements.txt
    pip freeze

The plugin I'm writing works similarly to this ^

Internally, we suggest a dependencyless approach which involves vendoring a copy of venv-update and using it as follows:

[testenv]
commands =
    {toxinidir}/bin/venv-update venv= {envdir} install= -r {toxinidir}/requirements.txt
    pip freeze -l

venv-update currently supports cpython 2.6, 2.7, 3.5, 3.6, pypy -- it is known to work in 3.3+ (and may very well work for 3.2 and below as well as pypy3.2 but we've stopped testing against those due to the pypa group dropping support). It is likely to also work for modern pypy3 (targeting 3.5.x). No attempt to verify its behaviour has been made against ironpython / jython / etc.

There is one outstanding kinda awful bug that is similarly shared by pip itself. pip-tools avoids this by uninstall-then-install whereas venv-update does install-then-uninstall -- it's not clear if there's an easy fix for this (it's kind of a rare case and we haven't invested any time into investigating / fixing).

[merwok]

pip-tools is a double-edges sword, it requires a separate pip-compile step, and voila, your one-step build is gone.

I don’t know what «one-step build» refers to. In my usage, calling pip-compile to add a new dependency or upgrade existing deps is something I do during development when I choose to; the install step in tox testenvs or before starting the app is only pip-sync.

[merwok]

this problem is better solved by a tool that can be used by tox

IMO it’s still a real tox bug that there is caching with incorrect invalidation.

maybe it would be better to deprecate the -r option

It’s still a useful shortcut to delete and re-run.

[ulope]

maybe it would be better to deprecate the -r option

It’s still a useful shortcut to delete and re-run.

I think the -r that's being talked about here is the one in deps = and not the command line one.

However wouldn't it be more sensible to keep the -r deps capability but instead of reinventing the wheel just rely on pip-tools for the job? From a quick look at the source it seems as if using it as a library should be pretty easy (although maybe not officially supported?)

[merwok]

Ah ok! I don’t know if there is such a thing as “-r deps capability”, or if the fact that you can have this in tox.ini is just because it is compatible with the default install_command.

[zsoldosp]

_disclaimer: I'm not (yet) familiar with tox's internals and its design philosophy and AFAIK it is my first interaction with the project_

Would a Make style, last-modified-time (dependencies vs. 'sources') based approach be an acceptable solution here? I.e.: in VirtualEnv.update, instead of using only self.envconfig.recreate, use (self.envconfig.recreate or should_recreate_based_on_last_modified_times()) (or store into a variable/method for brevity)? It could check the -r file as well as the setup.py in the root folder (*).

Granted, its performance wouldn't be as good as a smart solution's, but it would produce a correct venv

* and I know there can be weird corner cases with editable dependencies having their own setup.py files that can change, or the repo having multiple setup.py files, etc., but those could be fixed iteratively, by expanding the list of files to check for timestamps

edit: or is this suggestion better suited for #93?

[asottile]

I've implemented a tox plugin to hook up venv-update to make it so tox -r is unnecessary. From my cursory testing, it seems to work pretty well:

• https://github.com/asottile/tox-pip-extensions

It's a little rough around the edges:

• overrides install_command of all testenvs
• overrides installdeps step to preinstall the required bootstrap packages (in this case venv-update and its dependencies)
• Adds a pretest hook which --prunes extraneous dependencies

but it seems to work

This test demonstrates the acceptance criteria described in this ticket: https://github.com/asottile/tox-pip-extensions/blob/4d0ccaae3d68495d2d3e7c1bdb78102f0d6fafae/tests/tox_pip_extensions_test.py#L166-L182

[obestwalter]

@asottile very nice! This brings up the question again if we should finally deprecate this in tox ...

[asottile]

I think it's definitely useful to be able to react to chasing dependencies (either through install_requires or through -r. I'd love to find a way to upstream some of the efforts made in my plugin as I think they're pretty universally useful (but may drastically change the current virtualenv setup and maintenance strategy, so it might need to wait for a tox major version).

I do think it's useful to support -r, it certainly makes working with other tools that also handle requirements files much simpler and less duplicated.

I'll try and come up with some sort of proposal for what I think this might look like - - do you think that would be useful from your end?

[asottile]

Oh I might be confusing which -r you're taking about deprecating as well (pip or tox?)

[obestwalter]

darn - did it again - -r is ambivalent. I was talking about the -deps = -rrequrirements.txt kind of -r - sorry. It's marked as experimental anyway, though I have no strong opinion about it either way atm.

[The-Compiler]

That'd be horrible IMHO, and keep a lot of projects (including mine) from using tox

[obestwalter]

@The-Compiler you mean to remove that? O.k. - like I said, I don't mind either way, just fishing for opinions to see where the journey might go.

Maybe we should remove the experimental mark then and document that the env recreation does not really work together with that feature (yet)?

[WhyNotHugo]

Removing the -r support would immediately break CI for a lot of people (almost nobody uses a pinned tox), and is a pretty important feature about tox, IMHO.

[nicoddemus]

Maybe we should remove the experimental mark then and document that the env recreation does not really work together with that feature (yet)?

Definitely. IMHO it is way past the "experimental" stage where it could be removed. Removing it would break tons of test suites everywhere.

[RonnyPfannschmidt]

its experimental, whether or not people use it, i think its a fair case to print warnings when using cached virtualenvs so they get the idea - in ci the virtualenvs tend to be removed in "correct" setups

[RonnyPfannschmidt]

and i#d definitively leave it experimental until the python packaging ecosystem supplies a way to do it correct

[obestwalter]

Looks like the experiment is going to run a few years longer then :D

[asottile]

That said, my plugin makes -r work much much better. I'll try and make a more thorough writeup on what it would take to have something like it in core :)

[volans-]

Thanks for working on this!

Independently of the specific solution chosen, please consider to make it work also for keeping dependencies up to date when installed from setup.py, I think that this is also a fairly standard use case.

To be explicit I'm referring to the usage of deps = . to install the install_requires dependencies or deps = .[key_in_extras_require] to install the install_requires dependencies plus the ones defined in extras_require['key_in_extras_require'].

In the end I'm seeing this as a cache issue on tox side, given that there are at least three working syntaxes to install dependencies , of which only one express them explicitly, while the others get them indirectly and tox is not able to detect changes or available updates in the indirect cases.

[gaborbernat]

@volans- I think this is actually on issue on pip side; will true that there are three ways to specify dependencies ultimately we delegate all of it to pip; it's sad that pip offers no guarantees of replacing versions upon call

[obestwalter]

Hi @volans

deps = .[key_in_extras_require]

FYI: you should use extras for that https://tox.readthedocs.io/en/latest/config.html#confval-extras=MULTI-LINE-LIST - but the underlying problem will likely be the same (I guess - I am sadly still not very familiar with a lot of implementation deatils in tox), so this is just comsetics.

[volans-]

Thanks for the tip @obestwalter, although after a couple of quick tests I was not able to get the dependencies installed using extras, both with it alone and with deps = . (with usedevelop = True, so I cannot confirm if the behaviour is the same but I would suspect it would probably be the same anyway.

[obestwalter]

extras and usedevelop should do the trick - deps = . would not be necessary. If it doesn't work, I would suspect it's because of caching (which is a bit flaky in tox and under some circumstances does not refresh the env, when it should (tox -r helps here)) or because you share tox dirs with envdir, where it is already installed by the other run using that env without the extras - I seem to remember, that extras are simply not installed then.

[volans-]

@obestwalter I've tried both tox -r and rm -rf .tox and continue to fail. I'm not setting any *dir configuration, they are all to the default. It keeps finding the system installed flake8 for example instead of the virtualenv's one and keeps telling me:

WARNING:test command found but not installed in testenv
...SNIP...
Maybe you forgot to specify a dependency? See also the whitelist_externals envconfig setting.

[obestwalter]

That's weird. From my experience this is very reliable (with the caveats I mentioned). If you could create a minimal reproducer for that, it would be good to open an issue, so that we can look into that.

[volans]

Why I get the email of this. Actually I never involved into such project on
github.

On Sat, 1 Jul 2017 at 6:23 AM, Oliver Bestwalter [e-mail]
wrote:

That's weird. From my experience this is very reliable (with the caveats I
mentioned). If you could create a minimal reproducer for that, it would be
good to open an issue, so that we can look into that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tox-dev/tox/issues/149#issuecomment-312339689, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAT1wd-bdINe0CYqnwJyxVXWmQnQHgh_ks5sJT0UgaJpZM4KQ_WE
.

[obestwalter]

@volans

Why I get the email of this. Actually I never involved into such project on github.

Could be a Github mailing bug: volans- (same username as yours with a dash at the end) is part of this conversation ...

[The-Compiler]

@obestwalter Not a GitHub bug, you just mentioned the wrong nickname in https://github.com/tox-dev/tox/issues/149#issuecomment-312246798 :wink:

[obestwalter]

No it can't be me ... it must be a Github bug! Shame on me 😀

[asottile]

I forgot to finish my writeup on what would probably need to happen in tox (core) for this to happen.

As it currently is, tox installs dependencies and/or the project under test in many different stages:

• dependencies
• inst
• inst-no-deps
• etc.

and with many different combinations when it is installed with / without extras and with / without development

In order for pip to know the entire set of things that need to be installed, generally all of that needs to happen in a single step. My extension linked above (here's another link in case you missed it) largely leaves the current install steps alone and adds an additional step which performs all of the installs in a single invocation of pip. This is a bit wasteful as the deps / inst-no-deps / inst / etc. steps are essentially for nothing. I'm perhaps oversimplifying things, but it seems all of those additional steps can be written with a few lines and a single invocation of pip.

The slight (imo, it might be more than slight for some?) downside to the all-at-once approach is there's some overhead of pip (or your install tool) parsing all dependencies each run of tox -- the upside of course is less wtf with your dependencies not updating when you change your project.

I admittedly have not been intimately involved in the tox project or why it chose to split install into a bunch of incremental steps -- there may be good reasons for this that I'm overlooking?

This wasn't the writeup I intended, just wanted to dump some brain while I was thinking about this :D

[obestwalter]

Hey @asottile I also don't know, why this is split that way, but my feeling would be that it grew that way and that this is an area where tox could greatly profit from a thorough look why things are the way they are and then to simplify them if possible. Maybe @hpk42 can share some insights to get started and what is important to keep in mind, when working on this.

[volans-]

@obestwalter regarding the non working extras it's actually my fault, the system where I was having the issue had tox 2.3.1 installed system-wise, and I cannot reproduce it with tox 2.5.0 or 2.7.0. Sorry about the misunderstanding.

As already stated, this doesn't change the main issue here, that the dependencies are not updated. Anyway thanks for the tip.

[guyd]

Both issues 566 and 149 are closed as duplicate of each other. Any plan to fix it?

[The-Compiler]

@guyd I marked #566 as a duplicate of this. This is still open.

[guyd]

Ah! Sorry my mistake. I saw the closed badge on the previous comment.

[nicain]

@merwok Help wanted, RE your suggestion with pip-sync:

[testenv]
deps =
    pip-tools == 1.8.1rc3
commands =
    pip-sync requirements.txt requirements-test.txt
    pyflakes project
    pytest {posargs}

I have found that re-running tox (2.9.1) a second time is resulting in pip-sync uninstalling "py", causing a failure in pytest (on this line: https://github.com/pytest-dev/pytest/blob/672c901c704384b28e0079209684ba71e8867bf3/_pytest/config.py#L10)

A workaround that seems to be working for me is, instead of using pip-sync, eliminating [deps] completely:

[testenv]
commands =

    pip install -r {toxinidir}/requirements.txt
    pip install -r {toxinidir}/requirements-test.txt
    pyflakes project
    pytest {posargs}

Is this a terrible idea?

[asottile]

@nicain fwiw, this is basically what tox-pip-extensions does: https://github.com/tox-dev/tox-pip-extensions/blob/a989ec95ef8f3c5e63bb809308cd4260f0690e76/tox_pip_extensions.py#L143-L144

I'm surprised pip-sync is uninstalling py -- smells like a bug in piptools to me :)

[merwok]

I re-run tox all the time and never had the problem of py being uninstalled. I haven’t upgraded to pip-tools 1.10 though (I’m with 1.9).

[nicain]

@merwok @asottile Thanks for your help! The problem persists with both pip-tools 1.10 and 1.9, however I was able to change:

commands =
    pip install -U pip
    pip-sync {toxinidir}/requirements.txt {toxinidir}/requirements-test.txt
    pytest --basetemp={envtmpdir}

deps =
    pip-tool

to

commands =
    pip install -U pip
    pip-sync {toxinidir}/requirements.txt
    pip-sync {toxinidir}/requirements-test.txt
    pytest --basetemp={envtmpdir}

deps =
    pip-tool

I made a minimal repo to reproduce the problem: https://github.com/nicain/reproduce_tox_issue

Would one of you mind trying this out, and letting me know if I should make an issue with tox, pip-tools, or somewhere else?

EDIT: for posterities sake: https://github.com/nicain/reproduce_tox_issue/issues/1#issue-284247704

Working example: https://github.com/nicain/reproduce_tox_issue/tree/fix

[asottile]

Ah I see, you're misunderstanding how pip-sync works.

From https://github.com/jazzband/pip-tools#example-usage-for-pip-sync

Be careful: pip-sync is meant to be used only with a requirements.txt generated by pip-compile.

[acrewdson]

+1 for @asottile's tox-pip-extensions as a solution to this problem, though obviously it would still be nice to have it fixed in tox out of the box

[merwok]

Or use pip-tools, never* spend time re-creating testenvs, always have up-to-date installed dependencies.

* very rarely

[ssbarnea]

I hope this bug does not endup closed before we have this fixed inside tox itself. We should not endup using external tools or hacking tox.ini in order to get around it (workaround which mainly disables the deps option in tox).

[ssbarnea]

Is this ever going to be fixed in tox, or at least having tox document an official and reliable way to install or update requirements in its environments? So far I see only hacks and use of external tools that are likely to cause more problems than solving.

[RonnyPfannschmidt]

i am no longer working on that as its quite time-consuming to create the correct set of parts to solve this

[ssbarnea]

@asottile Any chance of fixing this painful bug? Is the olded tox bug I know about and was never solved and made me drop use of deps = in at least a dozen of projects and replacing it with a pip install command at the top of each environment.

The final result is really ugly but as opposed to the tox code, it does not break when req.txt are updated. I don't even remember how often I got complaints from developers reporting "it does not work for me"... when in fact what happened was that his virtualenv was not refreshed.

[gaborbernat]

It's on the to be done list but this is not trivial. You're free to submit PRs if you want it sooner than sometime in the future.

[ssbarnea]

@gaborbernat I suspect this is because this is not externalized to pip because it this task would have being "outsourced" to pip, it would not have being such a challenge to fix, right?

[gaborbernat]

Change tracking happens within tox, not in pip. We don't always call pip because that would be slow.

[asottile]

I've wanted to take pip-faster install --prune, upstream it, and then use it for this purpose (probably as pip prune? similar to npm prune). But I haven't really had the time or motivation (and sadly we don't use tox at work so I can't even float it there :/). Until then, I've used tox-pip-extensions with the venv-update extension to work around this

[ssbarnea]

@asottile I hope someone from core would edit this bug to include the clear tox-pip-extensions recipe for avoiding it.

I tested it and it works very well, sadly it requires newer tox and additional plugin which is a PITA as the plugins need to be pre-installed before running tox.

I would update the ticket but I have no such permissions.

[gaborbernat]

@ssbarnea you might want to follow https://github.com/tox-dev/tox/issues/998 to ease that PITA (if you want it faster, you could fill in a PR implementing it).

[igor47]

i ran into this issue because i added a dependency in requirements.txt and then it was missing from tox environment, and tox didn't recreate the environment. this may have been caused by me rebasing locally, but it also bit me in my circleci build.

my workaround is suggested by @ssbarnea (thanks for the tip!) i added this to testenv:

commands =
    # this ugly hack is here because:
    # https://github.com/tox-dev/tox/issues/149
    pip install -q -r {toxinidir}/requirements.txt
    pytest {posargs}
    flake8 {toxinidir}

although i saw the suggestion to remove deps = -Ur{toxinidir}/requirements.txt i left it in place in the hopes that this issue will some day be fixed!

[gaborbernat]

Just to give an update of this. There has been a significant discussion going on upstream to build backends to offer dependency information (and other metadata) without a build happening. Once this takes shape we'll be able to implement the feature request here in a reliable fashion. I plan to push this through so should be addressed by the end of the year (my plan as of now).

[ssbarnea]

@gaborbernat Really nice to hear you aim to nail it! On the other hand I realise that we are in March... so the end of the year is not as near as I would have wished for.

[gaborbernat]

Sadly this is not an easy issue and has many moving parts outside of tox that will need doing.

[ssbarnea]

@gaborbernat I hope that this solution would not add some requriments that would render it useless, like not working with py27 or py35.

[johnthagen]

Could tox hash any requirements.txt files that are used and cache that? Then it could know if the file had changed and recreate if necessary.

[gaborbernat]

Yes, and it's planned for tox 4 🤔

[WhyNotHugo]

Could tox hash any requirements.txt files that are used and cache that?

That's actually a brilliant idea. It would also make sense to order requirements before hashing, so change in order don't result in an environment recreation.

[The-Compiler]

This approach has been discussed before (probably multiple times by now?) in this thread. The main problem is that requirement files can include others via -r, which still wouldn't be fixed by a "naive" approach. However, I'd argue that even a naive approach which doesn't deal with requirement files including others would be a big benefit.

[twm]

It would also make sense to order requirements before hashing, so change in order don't result in an environment recreation.

Order is significant in requirements files (for now at least — Pip's new resolver may change that).

[janluke]

Yes, and it's planned for tox 4 🤔

Using "-r requirements.txt" in tox is so common that I'm suprised this issue has remained unresolved for >4 years instead of being solved by a hotfix. When is tox 4 planned to be released?

[gaborbernat]

Yes, and it's planned for tox 4 🤔

Using "-r requirements.txt" in tox is so common that I'm suprised this issue has remained unresolved for >4 years instead of being solved by a hotfix. When is tox 4 planned to be released?

It's a fairly complicated issue, it's more like adding a major feature than hotfix. We have an alpha version of it https://pypi.org/project/tox/4.0.0a2/, a first public release expected in a few months.

[JulienPalard]

Hi @merwok, as a user of pip-compile, I was willing to try this today, slighly modified version of you comment from 2017:

[testenv]
deps = pip-tools
commands_pre = pip-sync requirements-dev.txt
commands = coverage run -m pytest

Issue is: pip-sync uninstalls the project being tested :D

Do you still use this "trick"? If so have you found a nice and clean way to workaround this?

[nicoddemus]

Hi @JulienPalard,

I haven't tried with tox specifically, but I usually have this in my requirements.in file when using piptools:

-e file:.#egg=<my project>

(Replacing <my project> with the top level package name of your project).

This tells pip-sync to install . in develop mode.

HTH

[merwok]

Two options:

• some projects don’t need to be installed (e.g. django sites), so pip-sync is fine
• other need to be installed (Pyramid sites and other projects that need entry points), so I run flit install or pip install . from commands section.

[JulienPalard]

Thanks @merwok and @nicoddemus for sharing!

[gaborbernat]

I'm closing this as this has now been implemented in the alpha branch of rewrite. We can open more specific issue tickets on the implementation separately.

[ssbarnea]

@gaborbernat How about adding a fixed-by-tox4 label and also locking the ticket? There are lots of other similar tickets which are solved by it and which will not be addressed by old version. I you give me triage rights, I could help with that.

[gaborbernat]

You got it 👍🏻