Assure that setuptools <45 is installed

[MichaIng]

In some circumstances pip pulls setuptools 45.0.0, which is not compatible with Python 2. To assure the correct version is installed, add the "--no-setuptools" flag to virtualenv and install the correct setuptools version manually afterwards.

Workaround for: #239

---

While this works, it could be added probably more cleanly, e.g. adding --no-setuptools to VIRTUALENV variable and merging $(INSTALL) -U "setuptools<45" with $(INSTALL) -i https://pypi.python.org/simple -U pip to:

$(INSTALL) -i https://pypi.python.org/simple -U pip "setuptools<45"

What was actually the reason for adding the explicit pip install/upgrade? Since virtualenv does (or should) do this already. I can only imagine that it was a similar issue than the present one since pip is pulled from an explicit mirror?

Also some comment in code would be a good idea. Please advice about how it is wanted.

[rfk]

What was actually the reason for adding the explicit pip install/upgrade?

I don't think there was any deep reason, apart from "good hygiene to stay as up-to-date as possible". Now that we're stuck on a legacy python, of course, the opposite applies and we need to work to stay as out-of-date as we safely can :-(

[MichaIng]

I don't think there was any deep reason, apart from "good hygiene to stay as up-to-date as possible". Now that we're stuck on a legacy python, of course, the opposite applies and we need to work to stay as out-of-date as we safely can :-(

Usually upgrading pip or any other modules via pip to latest offered version is not an issue. There are several stages where compatibility with the local Python version is checked and all of them must fail somehow for an issue like this to happen 😉.

Let me check if virtualenv actually includes pip + setuptools + wheel upgrade, if the environment exists already, or not. In case it makes sense to upgrade all of them, which matches a new environment, and add <45 to setuptools to work around the issue.

EDIT: make build exists if it has run once, due to local/COMPLETE file existence. Either make clean needs to run or the file needs to be removed manually. Even when manually removing the COMPLETE file, so when the environment still exists, the four modules setuptools, pkg_resources, pip, wheel are installed again, so they will be always on most current supported version.

[MichaIng]

Comment added, obsolete pip install/upgrade removed, commit text updated accordingly. That removed empty line indentation is not somehow required for Makefile syntax, is it? 😄

[jrconlin]

just tested it locally. Hilariously, I needed to pre-run python-virtualenv because my system's native python2 doesn't include the virtualenv module, nor could I easily install it using the old python2 pip. Running make from inside a virtualenv dir was able to run make build until successful completion.

[MichaIng]

Hilariously, I needed to pre-run python-virtualenv because my system's native python2 doesn't include the virtualenv module, nor could I easily install it using the old python2 pip.

Reads similar to the issues we face on Debian Bullseye and Ubuntu Focal where the python-* do not exist anymore but only a very limited set of python2-* packages, excluding virtualenv. What works there is:

apt install python2-dev
cd /tmp
curl -sSfLO https://bootstrap.pypa.io/get-pip.py
python2 ./get-pip.py
rm get-pip.py
pip install virtualenv
cd /path/to/ffsync
make build

[jrconlin]

Yep, that works too.

Fortunately, we're making fairly good progress on the rust syncstorage-rs server. There's still the tokenserver bits that need to be hammered out, but hoping to get those in order soon too.

Then we can move things over to rust and send the python2 bits to a farm.
Upstate.
Where they can chase rabbits.

[MichaIng]

Reasonable, however, from my side there is interest to keep things running until next summer when Debian Bullseye gets released 🙂.

OOT, the next to take care of:

ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.

We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.

appears when running latest pip.