py.test-3 test discovery hangs when importing ubuntutools.lp.lpapicache Launchpad object

[Robie Basak]

In an Artful container, I am unable to run tests with:

py.test-3 gitubuntu/*.py

This is against 0.6.2-30-gb1551b1.

Instead of a regular test run, the run hangs at test collection stage:

$ py.test-3 gitubuntu/*.py
=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.6.3, pytest-3.1.3, py-1.4.34, pluggy-0.4.0
rootdir: /home/ubuntu/git-ubuntu/git, inifile:
collecting 35 items

Running with --fulltrace gets me the attached.

AFAICT, the problem is that "from ubuntutools.lp.lpapicache import Launchpad" brings in a Launchpad object into the module namespace (as intended). But this Launchpad object (an instance of class _Launchpad) has a __getattr__ method that results in attempting a Launchpad login as defined in /usr/lib/python3/dist-packages/ubuntutools/lp/lpapicache.py:119 in Artful (python3-ubuntutools 0.161). And py.test-3, during test discovery, attempts to look up the attribute '_pytestfixturefunction' against the Launchpad in case it exists. Presumably this is against all objects with names bound at module scope. And this Launchpad login attempt appears to hang when running inside the py.test-3 environment (though I haven't found a way to reproduce this at the CLI). Speculation: it's because of a stdio-related difference.

The actual hang is at the end of the backtrace, in make_end_user_authorize_token(). It looks like it's waiting for authorization in the browser, which will never happen especially because I never see the prompt.

This is an unexpected side effect. I do not expect that merely "from ubuntutools.lp.lpapicache import Launchpad" and running py.test-3 discovery on the result will result in any network traffic.

I'm not sure whether an assumption in py.test-3 is wrong, or if an assumption in ubuntutools.lp.lpapicache is wrong. Comments appreciated.

[Robie Basak (racb)]

17:56 <rbasak> cjwatson or wgrant: could I have your opinion on bug 1733388 please? I've identified what's going on, but am not sure which component is making the wrong assumption.
17:57 <ubot5> bug 1733388 in usd-importer "py.test-3 test discovery hangs when importing ubuntutools.lp.lpapicache Launchpad object" [Undecided,New] https://launchpad.net/bugs/1733388
17:57 * rbasak will be EOD in the next few minutes though, so no rush.
18:04 <cjwatson> rbasak: Well, um, I guess my opinion is that ubuntutools is distressingly and excessively magical. We don't maintain it though ...
18:05 <cjwatson> I mean pytest also contains a lot of magic. (I prefer less magical test runners.)
18:05 * rbasak isn't entirely sure what benefit use of this gives us over launchpadlib.launchpad. Presumably caching
18:06 <cjwatson> I guess it must be.
18:06 <cjwatson> I normally only use ubuntutools for its handy question-asking thing in my code.
18:08 <cjwatson> One perhaps reasonable fix would be to cause ubuntutools to not do the login thing for attributes that begin with '_'?
18:09 <rbasak> I suppose. I'm not very keen on this auto-login-on-getattr behaviour. But perhaps that's fundamental to the module.
18:10 <rbasak> OTOH it leads to side-effects such as UI prompts, so perhaps it's bad and it should be explicit.
18:10 <rbasak> It seems that I can work around it by not importing the Launchpad object into the module namespace.
18:11 <rbasak> So I could just leave the bug open against python3-ubuntutools for now I suppose.
18:13 * rbasak EODs
18:13 <cjwatson> Yeah, to me this sort of thing makes it not suitable for general-purpose use.

[Robie Basak (racb)]

Fixed in commit e5d0781, released in 0.7.

[Dan Streetman (ddstreet)]

please reopen if this problem still exists