variety not loading

After seeing that other bugs had been reported (Bug #1609548 at https://bugs.launchpad.net/variety/+bug/1609548 specifically), I attempted to install/verify if the solution proposed there would help me.

python-openssl was removed, installed requests==2.6.0 using pip, then re-installed python-openssl. as proposed in http://stackoverflow.com/questions/28987891/patch-pyopenssl-for-sslv3-issue

No change, variety still had same error.

Noticed that urllib3 was version 1.10.4; upgraded to 1.13.1, and variety started up from terminal. I killed that process, and started it up by icon. All seems fixed now.

I suggest that requirements include urllib3 1.13.1 and requests==2.6.0

What OS/version does this happen on?
It seems there are incompatibilities between certain reqeusts/urllib3 versions, which might be triggered by mixing the lib installations via apt-get and pip.

The problem is that Variety is packaged as a deb and can depend on Ubuntu packages (e.g. python-requests, python-urllib3), not on pip requirements, so it't not easy to require a specific version - it might not be in the repos.

My OS/version is Ubuntu 16.04.1 LTS, currently running Gnome 3 and MATE for different users.

I understand about the differences between Ubuntu packages and pip requirements.

Is there a way to detect the current versions of these requirements from within variety, and show a message if they don't correspond to the needed requirements (possibly guiding the neophyte user on how to update them using pip)?

I'm not sure which combinations of requests/urllib3 versions don't play well with each other, or if they're even documented as such.

There is, and Variety does something sort-of similar to install the SSL-related pip requirements needed for Wallhaven (not version checking, but catches the error and proceeds to suggest the fix).

I could have plugged there to also fix the requests/urllib3 mess. But with the very imports failing, and Variety not even starting right now, this won't do, I'll have to handle the import failure which kind of sucks. It's possible but I don't want to do such hacks before I understand when exactly this happens and how common of a problem it is. For example on my machine I couldn't reproduce it.

Theoretically requests should include its own copy of urllib3 (according to http://stackoverflow.com/a/32988728 and https://news.ycombinator.com/item?id=12179579). So I'm not sure why the version of the external urllib3 matters, but it does.

If needed, I don't mind "breaking" my install of variety if it'll help diagnose the problem; I enjoy using it and contributing to its proper function. Feel free to contact me at taserian AT gmail DOT com to coordinate, or we can continue through this bug report.

If you're up for some debugging, the first step is probably to start with a clean install of 16.04.1 in a VM, then check what's installed there out of the box and at which version (python-requests, python-urllib3). Then install Variety, check again the versions and whether it runs or not.

If Variety does not start after a clean install on a clean 16.04, it's a critical bug. Otherwise, it's individuals users' specific setups and some instructions may be enough.

Sorry about the lateness, this week has been difficult to get anything programming done.

Tried a clean VM install of Ubuntu GNOME 16.04.1 without updates, after updates, installing variety, and a dist-upgrade afterwards:
Versions of:
python-requests: 2.9.1-3
python-urllib3: 1.13.1-2ubuntu0.16.04.1

No changes to the versions across all changes.

I'll try again with a VM after downloading Ubuntu GNOME 16.04; it probably has a different version of the above. But it looks like using 16.04.1 seems to be the solution.

Now on Ubuntu GNOME 16.04 (fresh install without updates):
python-requests: 2.9.1-3
python-urllib3: 1.13.1-2

I can't seem to set up the situation where I had urllib3 == 1.10.4 with a fresh install. Any suggestions?