tox requires a file system with support for hard links to work

Issue #86 on hold
Hynek Schlawack created an issue

Since tox runs sdist, it requires hard links to work.

That’s a problem if you work in a VM with a guess file system like e.g. VirtualBox which don’t. Thus at the moment, it’s impossible to use tox in such a – thanks to vagrant increasingly common – setup.

There’s a related question on StackOverflow.

The only ad-hoc solution I can come up with is detecting that situation and monkey patch :)

Comments (12)

  1. Holger Krekel repo owner

    How do you do this, btw, if you don't use sdist? Or do you simply not package in a guest system?

  2. Hynek Schlawack reporter

    I don’t understand the first part of the question :) but yeah, I don’t package very much and when I do, I do it directly on my Mac.

    If it were just about packaging, the workaround would be to copy the source tree away from the shared folder and run sdist there. But I tend to run tox more often than that so it’s not practicable. :)

  3. Ronny Pfannschmidt

    a possible solution could be to ship a script with tox, that removes before doing a execfile on and having tox use that instead of directly invoking

    are you up for puting that together?

  4. s

    I'm running into this issue as well. Is there a way to tell tox to run everything in a separate path on the VM to avoid the vboxfs issues?

  5. Hynek Schlawack reporter

    That doesn’t appear feasible to me because it would require to copy/rsync the whole source tree elsewhere on each tox invocation.

    However: I solved this problem by simply using NFS for shared folders which is also faster. So win-win I guess. Maybe we should just make this a doc issue instead of monkey-patching distutil.

  6. Jason Pellerin

    Unfortunately NFS shared folders don't work everywhere. For instance, I can't use them on my ubuntu system because Vagrant's private networking and my employer's VPN don't get along. And of course it doesn't work for Windows hosts at all.

  7. Cal Leeming

    Just ran into this problem now, I had to use the del hack to make it work, as shown here.

    Could we possibly add a command line arg or an ini setting which lets you define this behaviour? Monkey patching can result in some projects breaking if the code relies on at runtime.

    Could a core dev please comment on whether such as PR would be accepted? Thanks.

  8. Holger Krekel repo owner

    I am not sure i understand yet -- is this about monkeypatching in the subprocess that is started by tox for creating the sdist?

  9. Cal Leeming

    @holgar From what I understand, this problem is caused by hard links not supported by the file system (which is the default for Vagrant/VirtualBox sharing). However I don't fully understand why hard links are created, it was discussed on the distutils mailing list several years ago, but no conclusion was ever reached. There is also an open patch on Python bug tracker, but no action yet.

    Our options are;

    A) Wait for bug to be fixed upstream (could take a long time, and will take even longer to be adopted by OS repos etc)

    B) Monkeypatch distutils (would require too much testing and could result in weird edge cases)

    C) Add a patch into Tox which tests if is successful inside cwd, and if not, then it removes Make this test an optional keyword argument for tox/ini, so that it doesn't impact backwards compatibility

    Personally I'd say C is the best way forward, it gives us flexibility to fix this problem by using flags, and doesn't break backwards compat.


  10. Log in to comment