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

Sat Mar 16 20:35:50 UTC 2019

On Sat, Mar 16, 2019 at 09:23:01PM +0100, Marek Vasut wrote:
> 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 :)

I don't even know what to say at this point.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190316/d7bfef90/attachment.sig>