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

From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings
Date: Wed, 13 Mar 2019 15:42:47 -0400	[thread overview]
Message-ID: <20190313194247.GL8732@bill-the-cat> (raw)
In-Reply-To: <ceff291e-6a0b-2448-8a5c-2f0880737cfd@gmail.com>

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@gmail.com>
> >>>>>>>> Cc: Igor Opaniuk <igor.opaniuk@linaro.org>
> >>>>>>>> Cc: Tom Rini <trini@konsulko.com>
> >>>>>>>> Cc: Simon Glass <sjg@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.

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.

-- 
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/20190313/471bd000/attachment.sig>