<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 13, 2020 at 5:36 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-12-13 14:39:58 +0100 (+0100), Luigi Toscano wrote:<br>
> On Saturday, 12 December 2020 00:12:36 CET Jeremy Stanley wrote:<br>
> > On 2020-12-11 20:38:30 +0000 (+0000), Sorin Sbarnea wrote:<br>
> > [...]<br>
> > > Regarding decoupling linting from test-requirements: yes! This was<br>
> > > already done by some when conflicts appeared. For old branches I<br>
> > > personally do not care much even if maintainers decide to disable<br>
> > > linting, their main benefit is on main branches.<br>
> > [...]<br>
> > <br>
> > To be honest, if I had my way, test-requirements.txt files would die<br>
> > in a fire. Sure it's a little more work to be specific about the<br>
> > individual requirements for each of your testenvs in tox.ini, but<br>
> > the payoff is that people aren't needlessly installing bandit when<br>
> > they run flake8 (for example). The thing we got into the PTI about<br>
> > using a separate doc/requirements.txt is a nice compromise in that<br>
> > direction, at least.<br>
> <br>
> Wouldn't this mean tracking requirements into two different kind<br>
> of places:the main requirements.txt file, which is still going to<br>
> be needed even for tests, and the tox environment definitions?<br>
<br>
Technically we already do. The requirements.txt file contains actual<br>
runtime Python dependencies of the software (technically<br>
setup_requires in Setuptools parlance). Then we have this vague<br>
test-requirements.txt file which installs everything under the sun<br>
a test might want, including the kitchen sink. Tox doesn't reuse one<br>
virtualenv for multiple testenv definitions, it creates a separate<br>
one for each, so for example...<br>
<br>
In the nova repo, if you `tox -e bandit` or `tox -e pep8` it's going<br>
to install coverage, psycopg2, PyMySQL, requests,<br>
python-barbicanclient, python-ironicclient, and a whole host of<br>
other stuff, including the entire transitive dependency set for<br>
everything in there, rather than just the one tool it needs to run.<br>
I can't even run the pep8 testenv locally because to do that I<br>
apparently need a Python package named zVMCloudConnector which wants<br>
root access to create files like<br>
/lib/systemd/system/sdkserver.service and<br>
/etc/sudoers.d/sudoers-zvmsdk and /var/lib/zvmsdk/* and<br>
/etc/zvmsdk/* in my system. WHAT?!? Do nova's developers actually<br>
ever run any of this themselves?<br>
<br>
Okay, so that one's actually in requirements.txt (might be a good<br>
candidate for a separate extras in the setup.cfg instead), but<br>
seriously, it's trying to install 182 packages (present count on<br>
master) just to do a "quick" style check, and the resulting .tox<br>
created from that is 319MB in size. How is that in any way sane? If<br>
I tweak the testenv:pep8 definition in tox.ini to set<br>
deps=flake8,hacking,mypy and and usedevelop=False, and set<br>
skipsdist=True in the general tox section, it installs a total of 9<br>
packages for a 36MB .tox directory. It's an extreme example, sure,<br>
but remember this is also happening in CI for each patch uploaded,<br>
and this setup cost is incurred every time in that context.<br></blockquote><div><br></div><div>Thanks for the hint btw, I'll apply it to our repos.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This is already solved in a few places in the nova repo, in<br>
different ways. One is the docs testenv, which installs<br>
doc/requirements.txt (currently 10 mostly Sphinx-related entries)<br>
instead of combining all that into test-requirements.txt too.<br>
Another is the osprofiler extra in setup.cfg allowing you to `pip<br>
install nova[osprofiler]` to get that specific dependency. Yet still<br>
another is the bindep testenv, which explicitly declares deps=bindep<br>
and so installs absolutely nothing else (save bindep's own<br>
dependencies)... or, well, it would except skipsdist got set to<br>
False by <a href="https://review.openstack.org/622972" rel="noreferrer" target="_blank">https://review.openstack.org/622972</a> making that testenv<br>
effectively pointless because now `tox -e bindep` has to install<br>
nova before it can tell you what packages you're missing to be able<br>
to install nova. *sigh*<br>
<br>
So anyway, there's a lot of opportunity for improvement, and that's<br>
just in nova, I'm sure there are similar situations throughout many<br>
of our projects. Using a test-requirements.txt file as a dumping<br>
ground for every last package any tox testenv could want may be<br>
convenient for tracking things, but it's far from convenient to<br>
actually use. The main thing we risk losing is that the<br>
requirements-check job currently reports whether entries in<br>
test-requirements.txt are compatible with the global<br>
upper-constraints.txt in openstack/requirements, so extending that<br>
to check dependencies declared in tox.ini or in package extras or<br>
additional external requirements lists would be needed if we wanted<br>
to preserve that capability.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>