Fix pex warning

[jeffwidman]

I was using pex on an application that lists google-auth as a dependency and got the following warning:

..../pex/environment.py:330 UserWarning: The `pkg_resources` package was loaded from a pex
vendored version when declaring namespace packages defined by google-auth 1.6.2. The 
google-auth 1.6.2 distribution should fix its `install_requires` to include `setuptools`

So adding setuptools as a listed dependency to fix this.

Also making the listing alphabetical.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[jeffwidman]

Note:
I am a bit unclear on the actual root cause of why pex is complaining about this.

But it seems like a harmless change as setuptools is the de-facto way to do things in python land these days.

[googlebot]

CLAs look good, thanks!

[theacodes]

This is fine, but can we set a minimum version on setuptools? It's unlikely this will work with any setuptools.

[jeffwidman]

This is fine, but can we set a minimum version on setuptools? It's unlikely this will work with any setuptools.

So I thought about that originally myself, but decided against it.

I agree that it's unlikely to work with all versions. However, let's think about what's happening here:

1. The code is already calling pkg_resources, so if an invalid version of setuptools was used, this would already be failing.
2. Therefore, all this PR does is make an implicit dependency explicit to silence a warning.
3. So the practical reality is that all the versions of setuptools that your users are fetching will work.
4. And if not, you'd be already seeing other bug reports.

Given the above, it would be arguably more confusing to pin a specific minimum version, because that implies there's something different about whatever arbitrary version we pick.

That said, this is your library, so if you want me to pick a specific version, I'm happy to, I just am not sure it makes sense here unless you already have reports of known bugs with older versions of setuptools.

[theacodes]

There are certainly versions of setuptools with buggy support for namespace packages.

…

On Tue, Feb 26, 2019, 5:37 PM Jeff Widman ***@***.***> wrote: This is fine, but can we set a minimum version on setuptools? It's unlikely this will work with *any* setuptools. So I thought about that originally myself, but decided against it. I agree that it's unlikely to work with all versions. However, let's think about what's happening here: 1. The code is already calling pkg_resources, so if an invalid version of setuptools was used, this would already be failing. 2. Therefore, all this PR does is make an implicit dependency explicit to silence a warning. 3. So the practical reality is that all the versions of setuptools that your users are fetching will work. 4. And if not, you'd be already seeing other bug reports. Given the above, it would be arguably more confusing to pin a specific minimum version, because that implies there's something *different* about whatever arbitrary version we pick. That said, this is your library, so if you want me to pick a specific version, I'm happy to, I just am not sure it makes sense here unless you already have reports of known bugs with older versions of setuptools. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#322 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc4AJZr9VZ_rUEGzmjkWiJyYLeI_Fks5vReFdgaJpZM4a36VQ> .

[jeffwidman]

Is there a minimum setuptools version that you want to require?

I'm not very familiar with those bugs (or the packaging of namespaced packages in general), so happy to defer to your expertise.

Also, I'm not clear what level of "bugginess" you're comfortable tolerating. For example, if it's a bug in a recent version, but an edge case that only manifests in certain rare environments, you may want to allow it so that users who aren't able to upgrade their environment but also aren't affected by the edge-case bug aren't excluded from using this library. Or you may not, I don't know...

[theacodes]

(apologies, I'm traveling so I'm not able to pull the exact versions) There were some old versions that would crash due to namespace packages being present. We can try to track them down, but I think any version newer than two years old is likely fine.

…

On Tue, Feb 26, 2019, 5:48 PM Jeff Widman ***@***.***> wrote: Is there a minimum setuptools version that you want to require? I'm not very familiar with those bugs (or the packaging of namespaced packages in general), so happy to defer to your expertise. Also, I'm not clear what level of "bugginess" you're comfortable tolerating. For example, if it's a bug in a recent version, but an edge case that only manifests in certain rare environments, you may want to allow it so that users who aren't able to upgrade their environment but also aren't affected by the edge-case bug aren't excluded from using this library. Or you may not, I don't know... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#322 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc764wPVVee_AVvTJme4C1lmjUVn5ks5vReP-gaJpZM4a36VQ> .

[jeffwidman]

Gotcha.

Grep'ing https://setuptools.readthedocs.io/en/latest/history.html for "namespace" shows 40.3.0 solved a problem with pkg_resource-style namespaces (pypa/setuptools#1321).

That said, 40.3.0 was released Sept 16, 2018 which is fairly recent...

If that's too new, 38.2.2 from Nov 27, 2017 fixed another bug (pypa/setuptools#1214 solved by pypa/setuptools#1215).

Thoughts?

[theacodes]

I'd say let's go with 40.3.0, thank you for doing this research!

…

On Tue, Feb 26, 2019, 7:10 PM Jeff Widman ***@***.***> wrote: Gotcha. Grep'ing https://setuptools.readthedocs.io/en/latest/history.html for "namespace" shows 40.3.0 solved a problem with pkg_resource-style namespaces (pypa/setuptools#1321 <pypa/setuptools#1321>). That said, 40.3.0 was released Sept 16, 2018 which is fairly recent... If that's too new, 38.2.2 from Nov 27, 2017 fixed another bug ( pypa/setuptools#1214 <pypa/setuptools#1214> solved by pypa/setuptools#1215 <pypa/setuptools#1215>). Thoughts? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#322 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc3TQVlw0gQg1CvNqbrmveTzk2Ib7ks5vRekFgaJpZM4a36VQ> .

[jeffwidman]

Sounds good. Updated.