[U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings

Fri Mar 15 17:39:23 UTC 2019

On 3/14/19 2:01 AM, Tom Rini wrote:
> On Thu, Mar 14, 2019 at 01:20:09AM +0100, Marek Vasut wrote:
>> On 3/13/19 8:42 PM, Tom Rini wrote:
>>> On Wed, Mar 13, 2019 at 07:23:15PM +0100, Marek Vasut wrote:
>>>> On 3/13/19 5:01 PM, Tom Rini wrote:
>>>>> On Wed, Mar 13, 2019 at 12:30:59PM +0100, Marek Vasut wrote:
>>>>>> On 3/13/19 12:29 PM, Tom Rini wrote:
>>>>>>> On Wed, Mar 13, 2019 at 12:27:38PM +0100, Marek Vasut wrote:
>>>>>>>> On 3/13/19 12:25 PM, Tom Rini wrote:
>>>>>>>>> On Wed, Mar 13, 2019 at 12:20:49PM +0100, Marek Vasut wrote:
>>>>>>>>>> On 3/13/19 12:19 PM, Tom Rini wrote:
>>>>>>>>>>> On Wed, Mar 13, 2019 at 05:08:14AM +0100, Marek Vasut wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Fix the following spit from pytest:
>>>>>>>>>>>>
>>>>>>>>>>>> u-boot/test/py/conftest.py:438: RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged marks which are hard to deal with correctly.
>>>>>>>>>>>>   Please use node.get_closest_marker(name) or node.iter_markers(name).
>>>>>>>>>>>>   Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
>>>>>>>>>>>>     for board in mark.args:
>>>>>>>>>>>>
>>>>>>>>>>>> In both cases, the later suggestion is applicable.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas at gmail.com>
>>>>>>>>>>>> Cc: Igor Opaniuk <igor.opaniuk at linaro.org>
>>>>>>>>>>>> Cc: Tom Rini <trini at konsulko.com>
>>>>>>>>>>>> Cc: Simon Glass <sjg at chromium.org>
>>>>>>>>>>>
>>>>>>>>>>> Deferred, for now we don't support newer pytest than 2.8.7 and you'll
>>>>>>>>>>> need to use virtualenv to set that up if needed.  There is not, AFAICT,
>>>>>>>>>>> a way to support both versions.
>>>>>>>>>>
>>>>>>>>>> That's what's in debian testing though, so maybe we need to support it
>>>>>>>>>> somehow.
>>>>>>>>>
>>>>>>>>> Yes, I'm _very_ frustrated at the speed at which pytest went from "this
>>>>>>>>> is the API" to "this API is deprecated" to "this API doesn't work and
>>>>>>>>> here's the new, incompatible API".  Debian/testing needs to use
>>>>>>>>> virtualenv to setup a python area with older pytest installed, just like
>>>>>>>>> we do in .travis.yml.
>>>>>>>>
>>>>>>>> Can't we rather have people use the new APIs and virtualenv new python?
>>>>>>>
>>>>>>> Not as easily, no.  Debian/testing may have something much newer but
>>>>>>> Debian/stable doesn't, and I don't know what Ubuntu/18.04 has off-hand
>>>>>>> but it's probably inbetween and so on.
>>>>>>
>>>>>> While I'm not a python expert, shouldn't virtualenv help with that ?
>>>>>
>>>>> Yes, and breaking old setups is usually frowned upon and making new
>>>>> setups conform to the existing ways is how things are usually done.
>>>>
>>>> If you use venv with old setup, won't that give you the new python you
>>>> need ?
>>>
>>> No, you don't need to.  Travis is special in that it's based on Ubuntu
>>> 14.04 (!!!!) and so we needed to use pip there to setup anything, and
>>> have for forever.  That in turn lead to us hitting this problem a while
>>> back, when "pip install pytest" first gave us something where the old
>>> behavior became a fatal error.  That leads to installing the last
>>> version before pytest starts to complain about changing APIs.  Normally
>>> old distributions however ship with 2.8.7 anyways and don't need
>>> virtaulenv.
>>
>> I don't think I get your point here. Sure, old distros might need to
>> change and start using virtualenv because the software is just too old.
>> We cannot support all kinds of old stuff. If the API we're using is
>> getting deprecated, let's just switch to the new one and ask the users
>> of old software to upgrade (?).
> 
> My point is that "pin to a newer pytest version" is not something I want
> right now.  It will break existing setups and provide nothing in return.

Besides, using latest code instead of old stuff, as we should ?
If your existing setup breaks, maybe you should update your existing setup.

> There's not some new feature of pytest we're missing out on.  My take
> away from all of this is that we need to move the whole thing into being
> wrapped up, for everyone, as we cannot expect random community python
> modules to remove an API in an extremely quick fashion.  If you're
> motivated enough over this to go off and do that, yes, sure.  But I will
> not take a patch this patch as-is, as it breaks travis-ci.

Cool, and without this patch, all the tests fail on debian testing.
So maybe travis needs an update ?

> I will not
> take a v2 of this patch that is the above plus pinning to a new pytest
> as that's just going to push the problem from "Debian/Buster and others
> people need to continue to setup virtualenv" to "Ubuntu 16.04 and other
> people now need to setup virtualenv".  That's just pushing the problem
> around and not making anything better.

I think everyone should just setup virtualenv if their setup is too old?

>>> So no, I'm not going to change the setup that's working for existing
>>> installs today.  Frankly, the whole thing has me sighing rather loudly
>>> and figuring the only path forward is that yes, we'll have to mandate
>>> _everyone_ use a virtualenv and some helper script around that so it's
>>> not too painful.  But all of that is much less important that getting
>>> away from python2.
>>
>> I think that's a bit off-topic here. However, what's still stuck on
>> python2 ?
> 
> $ git grep -il python2
> Documentation/sphinx/kerneldoc.py
> Makefile
> scripts/dtc/pylibfdt/Makefile
> scripts/dtc/pylibfdt/setup.py
> scripts/fill_scrapyard.py
> scripts/mailmapper
> test/py/test.py
> tools/binman/binman.py
> tools/buildman/buildman.py
> tools/dtoc/dtoc.py
> tools/genboardscfg.py
> tools/microcode-tool.py
> tools/moveconfig.py
> tools/patman/patman.py
> tools/rkmux.py
> 
>>
>> -- 
>> Best regards,
>> Marek Vasut
> 

-- 
Best regards,
Marek Vasut