-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
virtualbox vboxfs buggy filesystem causing issues with pip #16
Comments
full install.log command run was |
comment from @kitsuta is
|
Yup, this is exactly what I was referring to. You can see that even though it says it uninstalled the older version, the install directory isn't empty. Originally I was having this happen with pytz, then Eli and I both had it with pockets. I think it might not matter which package it is in particular. It's not Windows-only either, I use a Mac and Eli uses Linux. Since you mentioned the file system sharing I've been thinking that's a pretty good starting point to look into. |
was searching around, using this a dumping ground for possible leads: Not quite the same error, would be interesting to check out: Something about issues uninstalling if the fs you're uninstalling from and the fs that /tmp is on are different: |
working on repro steps after this error happens after a fresh
then one of these will trigger it: I do still bet it has something to do with doing it on a shared FS, but, at least we have an easy repro |
verbose pip install may indicate that this is something to do with the tmp dir and underlying fs
|
looks very related |
fascinating. OK, it seems each time the file is some random file. I think this isn't a pip bug, it might be a virtualbox+vboxfs bug. I have a new simpler repro: after everything failed once, I tried to check this out:
that pycache dir is CLEARLY EMPTY according to linux. but on windows, the directory is NOT empty: this has got to be some virtualbox fs bug then. |
maybe related to this: |
yea ok it's definitely some kind of virtualbox vboxfs bug / race condition. There's a nice repro here:
run that on vboxfs, it fails. run it on the native fs, it's fine. |
it MIGHT be related to https://coderwall.com/p/mvf0aq/vagrant-auto-update-virtualbox-guest-additions which we currently have disabled auto-updating, and my versions are mismatched, trying to upgrade all virtualbox versions and see if that helps... |
and..... didn't work, same behavior on vbox 5.2.28 with updated guest editions. yikes. |
ok, calling this a night. As a workaround to the underlying bug, we could try and fix our dependencies to not uninstall anything (like, there's no reason we need to be installing an old version of cherrypy and then install a newer version). But, that's a pretty flimsy workaround and we could run into other issues later in a different area if we can't trust the underlying vboxfs. Some workarounds maybe, all are kinda painful:
|
oh and for non-windows host users (i.e. @EliAndrewC and @kitsuta) you guys can switch your Vagrantfile from vboxfs to NFS (apparently pretty easy) and get around this. theoretically. https://www.vagrantup.com/docs/synced-folders/nfs.html Maybe this is finally time to install linux on this laptop..... |
I might.... try and fix virtualbox. Dropping some links pointing out the right areas to look at it in the guest additions vboxfs code: http://techblog.en.klab-blogs.com/archives/11851752.html?p=2 |
We're not sure what the rhyme or reason for this is, but our deploy process is reinstalling older versions of some libraries on top of newer versions, and tripping up a shared filesystem bug (magfest/reggie-formula#16). This changes some of the libraries we found that did this, though this likely doesn't catch them all.
* Stop re-installing some libraries We're not sure what the rhyme or reason for this is, but our deploy process is reinstalling older versions of some libraries on top of newer versions, and tripping up a shared filesystem bug (magfest/reggie-formula#16). This changes some of the libraries we found that did this, though this likely doesn't catch them all. * Update requirements.txt
Updates: This failure in pip appears to be an issue in the underlying virtualbox vboxfs shared directory not updating correctly between guest and host. I've updated the bug report here https://www.virtualbox.org/ticket/8761
Read below for the original thread trying to figure out what's going on here.
main part of install.log, looks like a conflict with CherryPy versions? more later
particularly, this bit:
The text was updated successfully, but these errors were encountered: