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

Sat Mar 16 20:23:01 UTC 2019

On 3/16/19 2:50 AM, Tom Rini wrote:
> On Fri, Mar 15, 2019 at 06:39:23PM +0100, Marek Vasut wrote:
>> 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 ?
> 
> We should?  What's the reason we need to upgrade?  What problem we have
> is being fixed?

With this reasoning, we could've stuck to gcc 2.95 too though.
Why didn't we ?

>> If your existing setup breaks, maybe you should update your existing setup.
> 
> No, we don't break existing setups.

Heh? Seems to happen all the time with the DM/DT stuff.

>>> 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.
> 
> Everyone else is using virtualenv. 

Everyone else, but ancient systems, OK.

>> So maybe travis needs an update ?
> 
> Please go ${search_engine} the problem.  TL;DR, sure, just as soon as
> that's possible!

So why can't travis use virtualenv ? How do other systems set up various
python versions on travis ?

>>> 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?
> 
> Nope.  If we're going to do anything about this, we're going to fix the
> problem so we don't have the problem again in a year, when another API
> gets removed.  We're not going to break people that have a working setup
> already.

I think I'll use that argument at some point :)

-- 
Best regards,
Marek Vasut