Try fix spec failure due to broken setuptools

[deivid-rodriguez]

Just trying to fix CI, like others 😆

This spec is currently locked to numpy 0.19 which did not yet restrict setuptools version. I tried to make sure it uses the latest numpy which does restrict it. I left requirements.txt untouched because I can't for the love of me regenerate it from the updated requirements.in, since I have no idea what I'm doing. But this change alone fixed the spec locally, so I may as well try it in CI 🤷.

[deivid-rodriguez]

Oh, I think I might get it. This spec is testing a project that does not resolve. So basically the requirements.txt file is unused since it fails to be regenerated. I'm going to try remove it to prove it.

[jakecoffman]

This makes sense!

[deivid-rodriguez]

That didn't work. Without requirements.txt, no resolution error happens at all.

I think pip compile does something similar to Bundler, it tracks changes in the requirements.in with respect to the existing requirement.txt and tries to keep everything in requirements.txt not affected by those changes locked. And it's probably those locked requirements causing the resolution conflict being tested here.

So I guess this PR makes sense as is, since it does not seem to affect the resolution but forces a good version of setuptools to be used.

[jeffwidman]

That didn't work. Without requirements.txt, no resolution error happens at all.

I suspect this was fixed in #5580. @deivid-rodriguez Does that change anything that you were trying to do in this PR?

[deivid-rodriguez]

I tried removing the requirements.txt file and the spec failed so I think it didn't change anything. I think what I was trying to do was wrong, as per my theory at #5546 (comment).