Hi Brian, You are right, I will test and check a little more about some of the updates. But bare in mind that I check each one by testing them one by one, including pytest itself. Also tested some of my ports to see if the results matched out, those was: devel/py-parso devel/py-jedi textproc/py-xlrd
And some other random ports, Even find out that py-click test wasn't working because we should define LANG=C.UTF-8 before the test, I will check on that later. I will make a full report on the results of several test so you and the others rest assure about the update. About the changes on pytest, I looked into the changes and potential problems, didn't find anything that could make problems, mostly of the things that they changed are just marked as "deprecated". And yes, some changes might need to rework some of the ports if they where invoking for example "python setup.py test" instead of calling pytest directly, so your complain about checking them out is a legit one clearly. That*s why I didn't sent things and that's it, I asked for advice on how to treat the issue. Cheers. Elias. 2018-07-21 23:26 GMT-03:00 Brian Callahan <bcal...@devio.us>: > Hi Elias -- > > On 7/21/2018 7:57 AM, Elias M. Mariani wrote: >> Sorry to ping this but I would like to know how to proceed to keep working. >> >> Cheers. >> Elias. >> >> 2018-07-18 15:50 GMT-03:00 Elias M. Mariani <marianiel...@gmail.com>: >>> Hi, >>> I have the following list of ports, all share interdependencies >>> between them, thats why I think that the best would be to commit the >>> hole thing together. >>> I'm talking about py-test. >>> I have the diff ready to update: >>> devel/py-hypothesis >>> devel/py-py >>> devel/py-test >>> devel/py-test-httpbin >>> devel/py-test-localserver >>> devel/py-test-mock >>> devel/py-test-runner >>> devel/py-test-xdist >>> >>> And a tarball with: >>> devel/py-test-forked (new dependency of devel/py-test-xdist). >>> >>> The question is: >>> Should I send a single diff + tarball ? >>> Should I send each by each ? >>> >>> And a bigger "Should I": >>> Maybe create a devel/pytest/* subdir to add the plugins and fix the >>> name convention ? >>> The tool is called pytest, and if we want to update several other >>> plugins of the tool I will need to add even more plugins that are >>> missing and now have interdependencies (like pytest-flake8 and >>> others). >>> >>> Ideas? >>> I attach the single diff and tarball just because is free. >>> I took the liberty of getting the maintainer, if I did wrong or >>> Alexandr wants to keep it, no problem. >>> >>> Cheers. >>> Elias. > > I haven't seen any public replies to this so I'll throw one in. > > I agree that an update of py-test is beneficial. A quick perusal of the > ports tree turns up at least one port that has its tests disabled > because it needs a newer py-test. > > However, what I don't see either in your initial email with all the > diffs or any of your subsequent mails is any of the hard work that goes > into updating a more foundational port. There are lots of ports that > depend on py-test for their testing apparatus, and your emails leave me > less than confident that you have done the work to comb through py-test > (the Changelog perhaps as a start) to see if there's any potential > changes that would affect existing ports, or doing the work yourself of > actually running tests before and after the py-test update and comparing > the results. Bumping some MODPY_EGG_VERSION numbers and regen'ing some > PLISTs is easy; that's not the hard work. > > It is one thing when it is a leaf port and a sloppy update breaks it. We > would still be annoyed, but the damage would be minimal, and very likely > spotted before ever being committed. I would be very upset if an update > to py-test broke the testing apparatus of any of my ports, because I > depend on them to find bugs and coordinate fixes with upstreams. A > breakage here would have the potential to significantly increase the > time and labor I have to spend on updates. > > Frankly, something like this will take coordination with others. Coming > in with a plan, even if the plan itself ultimately gets changed > significantly, would be a good start. Your "Should I" section in your > original mail could be a part of that plan but is not itself a plan. > > And I'm sorry that I don't have the time to work on an undertaking such > as this. But if you start down the path outlined above, you are likely > to eventually get the attention of interested developers. Bear in mind > that all this takes time, so "eventually" might be longer than you > originally anticipate. > > ~Brian >
