Hi Daniel, I dropped the changes long ago, and as you say, they are newer versions for almost every port from that moment to now. I am NOT interested anymore in taking the maintainership.
That being said, send the diff to the list when you have it, I can help to test a little. Cheers. Elias. On Sun, Dec 2, 2018 at 4:14 PM Daniel Jakots <danj+o...@chown.me> wrote: > > Hi, > > I plan to look at those ports next week. (Nearly?) All the ports have > seen newer releases since July. I'm probably going to look at your > diff for hint but I doubt I'm going to apply them directly. Two > questions: > - Do you have any updated diff in your tree? No need to look at them if > you don't! I just want to be sure there's no duplicated work but I > can do it directly, it's barely the same amount of work. > - Do you still want to take Maintainership? > > Cheers, > Daniel > > On Tue, 24 Jul 2018 22:33:45 -0300, "Elias M. Mariani" > <marianiel...@gmail.com> wrote: > > > To check for the possibility of this updates affecting other ports I > > checked every port using the current versions vs the updated versions, > > the results are attached. > > The format is: > > FULLPKGPATH > > Result using current version > > Result using new version (if differences exist, none if equals) > > > > The only ones giving a different result are: > > www/py-httpie > > 4 failed, 223 passed, 4 skipped, 13 warnings > > Error: fixture is being applied more than once to the same function > > > > devel/py-doit > > 2 failed, 731 passed, 21 skipped > > Error: fixture is being applied more than once to the same function > > > > According to the pytest changelog: > > "Now when @pytest.fixture is applied more than once to the same > > function a ValueError is raised. This buggy behavior would cause > > surprising problems and if was working for a test suite it was mostly > > by accident." > > https://docs.pytest.org/en/latest/changelog.html#pytest-3-6-0-2018-05-23 > > > > So I think that with this we can rest assure that the updates work > > fine. With that I propose to update the versions with the unified > > diff that I attached as well, and the new dependency on py-test-xdist: > > py-test-forked (also attached...). > > Doing the change at once seems to me reasonable given the > > interdependency and also the way in witch I made the tests. > > > > Side notes: > > - I added Remi and Benoitt to the thread because I think they were the > > last ones working with py-httpie and py-doit. And might be interested > > I guess in the results. > > - The results might be wrong given the nature of the tests, sometimes > > errors appear because a conflict with another package and things like > > that, but the point of the tests is not to tests the ports in this > > case, but whether if the new version present any difference with the > > current one. > > > > Cheers. > > Elias. > > > > 2018-07-22 17:50 GMT-03:00 Elias M. Mariani <marianiel...@gmail.com>: > > > I will send this piece by piece. > > > Checking the results between the current version and the new one, to > > > see if something differ, and if so, if is because a positive outcome > > > of the update or a bug in the newer version. > > > I think that this will be positive to all, specially those that use > > > pytest in their outgoing effort of updating python ports. > > > > > > Cheers. > > > Elias. > > > > > > 2018-07-22 12:32 GMT-03:00 Elias M. Mariani > > > <marianiel...@gmail.com>: > > >> 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 > > >>> >
