chore: upgrade setuptools/pip in Dockerfile

[mistercrunch]

Making sure that pip and setuptools are the latest in our Dockerfile

closes #27405

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.60%. Comparing base (69d870c) to head (489ff0c).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #27405      +/-   ##
==========================================
- Coverage   69.71%   69.60%   -0.11%     
==========================================
  Files        1909     1909              
  Lines       74604    74619      +15     
  Branches     8323     8323              
==========================================
- Hits        52008    51937      -71     
- Misses      20544    20630      +86     
  Partials     2052     2052              

Flag	Coverage Δ
hive	?
mysql	77.97% <ø> (+0.01%)	⬆️
postgres	78.10% <ø> (+0.01%)	⬆️
presto	?
python	82.90% <ø> (-0.24%)	⬇️
sqlite	77.61% <ø> (+0.01%)	⬆️
unit	56.54% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[john-bodley]

@mistercrunch I don't see the requirements/development.in file in your PR? Note I agree with your thought process about not having setuptools as an explicit dependency.

[mistercrunch]

I thought I was stuck and couldn't run pip-compile-multi since it's busted, but I just found its --no-upgrade flag which did work just now.

BTW keep running in some issue where pip-compile-multi replaces the . in -e file:. to the full local path in my local computer randomly and I have to replace back to a . manually. Luckily it doesn't mess up the hash that pip-compile-multi manages.

[mistercrunch]

Oh btw, note that even after removing setuptools from requirements/development.in, all of our requirements/*.txt files still have that message:

# The following packages are considered to be unsafe in a requirements file:
# setuptools

[mistercrunch]

@john-bodley I think I addressed your point, let me know if there's anything else