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+rene...@gmail.com> >>>>>>>>>>>> Cc: Igor Opaniuk <igor.opan...@linaro.org> >>>>>>>>>>>> Cc: Tom Rini <tr...@konsulko.com> >>>>>>>>>>>> Cc: Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
