No longer pin setuptools as modern Pants supports modern setuptools

[Eric-Arellano]

Problem

We originally had to manually pin setuptools to 5.4.1 to workaround pantsbuild/pants#3948.

This is no longer the case thanks to multiple changes to Pex and Pants, most recently seen at pantsbuild/pants#6594.

Continuing to pin to 5.4.1 prevents Python 3 from working, as seen with https://travis-ci.org/pantsbuild/setup/jobs/507117401#L553.

Solution

Remove all custom code resolving setuptools and let Pip install and resolve as it normally does.

1. 14 fewer lines of custom code, making the script easier for people to understand and for us to develop.
   • Note pip ships with setuptools by default for a reason. It's a sensible default.
2. We end up with the same version as Pants after all is done, which is the behavior we want.
3. If we ever needed to bump the pinned version, we would need people to curl the script again, which is very infrequent for them to do.

Result

Because we pin setuptools in Pants' requirements.txt, we end up getting the exact same setuptools that Pants is using for that version.

This is the output after creating a new virtual env:

Successfully installed Markdown-2.1.1 Pygments-2.3.1 ansicolors-1.0.2 asn1crypto-0.24.0 asttokens-1.1.13 certifi-2019.3.9 cffi-1.11.1 chardet-3.0.4 configparser-3.5.0 contextlib2-0.5.5 cryptography-2.6.1 docutils-0.12 enum34-1.1.6 fasteners-0.14.1 faulthandler-2.6 future-0.17.1 idna-2.8 ipaddress-1.0.22 monotonic-1.5 packaging-16.8 pantsbuild.pants-1.15.0.dev4 pathspec-0.5.9 pex-1.5.3 ply-3.11 psutil-5.4.8 py-zipkin-0.17.0 pycparser-2.19 pyopenssl-17.3.0 pyparsing-2.3.1 pystache-0.5.3 pywatchman-1.4.1 requests-2.21.0 scandir-1.2 setproctitle-1.1.10 setuptools-40.4.3 six-1.12.0 subprocess32-3.2.7 thriftpy2-0.4.2 twitter.common.collections-0.3.10 twitter.common.confluence-0.3.10 twitter.common.dirutil-0.3.10 twitter.common.lang-0.3.10 twitter.common.log-0.3.10 twitter.common.options-0.3.10 urllib3-1.24.1 wheel-0.31.1 www-authenticate-0.9.2

New virtual environment successfully created at /Users/eric/.cache/pants/setup/bootstrap-Darwin-x86_64/1.15.0.dev4_py27.

[stuhood]

In general, pinning something this fundamental isn't the worst idea. Is there a modern working version that we can pin instead?

[Eric-Arellano]

In general, pinning something this fundamental isn't the worst idea. Is there a modern working version that we can pin instead?

@stuhood see

Because we pin setuptools in Pants' requirements.txt, we end up getting the exact same setuptools that Pants is using for that version. This is a good thing to let the version only be defined in Pants, as it de-duplicates the value. Users very infrequently update their ./pants script so it would be easy for the versions to fall out of sync.

I think we should not pin for these reasons:

1. 14 fewer lines of custom code, making the script easier for people to understand and for us to develop.
   • Note pip ships with setuptools by default for a reason. It's a sensible default.
2. We end up with the same version as Pants after all is done, which is the behavior we want.
3. If we ever needed to bump the pinned version, we would need people to curl the script again, which is very infrequent for them to do.

[stuhood]

Got it. Thanks!