From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Sat, 16 Mar 2019 21:23:01 +0100 Subject: [U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings In-Reply-To: <20190316015003.GH8732@bill-the-cat> References: <20190313112501.GB8732@bill-the-cat> <904b8981-a18c-db82-e8bc-e75ea898f2e9@gmail.com> <20190313112942.GC8732@bill-the-cat> <806904e3-0d0d-3c02-a2d7-8db1310825b4@gmail.com> <20190313160127.GF8732@bill-the-cat> <20190313194247.GL8732@bill-the-cat> <20190314010153.GO8732@bill-the-cat> <57db2e90-3758-74a8-cbc8-0e30a968c128@gmail.com> <20190316015003.GH8732@bill-the-cat> Message-ID: <6e4745c3-985e-00f0-be0b-37858ad6a1f3@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>>>>>>>>>>> Cc: Igor Opaniuk >>>>>>>>>>>>>> Cc: Tom Rini >>>>>>>>>>>>>> Cc: Simon Glass >>>>>>>>>>>>> >>>>>>>>>>>>> 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