pytest 6.2.2 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/stable/changelog.html. Thanks to all of the contributors to this release: * Adam Johnson * Bruno Oliveira * Chris NeJame * Ran Benita Happy testing, The pytest Development Team
Hello pytest developers. As you may remember, back in 2017 at EuroPython in Rimini I made an attempt to restructure pytest's documentation, according to the principles in https://documentation.divio.com. See https://github.com/pytest-dev/pytest/issues/4119 and <https://github.com/pytest-dev/pytest/compare/master...evildmp:documentation-...>. It wasn't a success, and that was because I tried to do too much at once when too much else was going on at the same time. I'd like to have another attempt, but to approach it in a different way that has worked well for me since then. Rather than work on a large, monolithic reorganisation as I tried before, I would like to do it in very small commits and cycles, that can quickly be checked, approved and merged, over a period of a few weeks. Would you be interested in my tackling this again? I believe that this approach will be successful in a way that it wasn't last time. To help make it work, I would need to be able to rely on very short review/merge cycles, which I know is asking a lot in a project like this. On the other hand, each proposed change will typically be very small and easy to review. In fact some of them will likely seem quite trivial or banal in content, but if you can put up with that during the process, it's part of the approach. I will use the work as an example for my talk in April at Write the Docs, https://www.writethedocs.org/conf/portland/2021/speakers/#speaker-daniele-pr..., so that also gives you an idea of when I expect the process to be largely complete (I will also discuss my original attempt, and why it failed). I understand if you feel that this would require too much effort from the team to be worthwhile, but if you think it could be a good idea, I'd be happy to outline what I have in mind in more detail. Thanks a lot, Daniele
Hi Daniele, On Sat, Feb 27, 2021 at 9:26 AM Daniele Procida <daniele@vurt.org> wrote:
As you may remember, back in 2017 at EuroPython in Rimini I made an attempt to restructure pytest's documentation, according to the principles in https://documentation.divio.com. See https://github.com/pytest-dev/pytest/issues/4119 and < https://github.com/pytest-dev/pytest/compare/master...evildmp:documentation-...
.
It wasn't a success, and that was because I tried to do too much at once when too much else was going on at the same time.
Understandable, it is hard to apply large changes over a long period of time, especially documentation which has small additions/changes all the time, which causes conflicts in the long term. Also, life happens. I'd like to have another attempt, but to approach it in a different way
that has worked well for me since then.
Rather than work on a large, monolithic reorganisation as I tried before, I would like to do it in very small commits and cycles, that can quickly be checked, approved and merged, over a period of a few weeks.
That sounds good to me. Are the small changes self-contained? If so, I think they can target the master branch as usual with other PRs. If however the changes are just part of an overall redesign, where it only makes sense to publish them to users once the overall redesign is complete, we can have a separate branch in the repository, like before. Would you be interested in my tackling this again? I believe that this
approach will be successful in a way that it wasn't last time.
From my part, definitely. I really liked the direction that redesign was going.
To help make it work, I would need to be able to rely on very short
review/merge cycles, which I know is asking a lot in a project like this. On the other hand, each proposed change will typically be very small and easy to review. In fact some of them will likely seem quite trivial or banal in content, but if you can put up with that during the process, it's part of the approach.
Overall our review response is quick, usually within 1-2 days (if not a few hours). What do you think would be required for this work? I will use the work as an example for my talk in April at Write the Docs,
https://www.writethedocs.org/conf/portland/2021/speakers/#speaker-daniele-pr..., so that also gives you an idea of when I expect the process to be largely complete (I will also discuss my original attempt, and why it failed).
I understand if you feel that this would require too much effort from the team to be worthwhile, but if you think it could be a good idea, I'd be happy to outline what I have in mind in more detail.
I definitely think it would be a good idea, but I'm interested to hear what the other maintainers think as well. Thanks for offering to contribute again! Cheers, Bruno.
Bruno Oliveira wrote:
Rather than work on a large, monolithic reorganisation as I tried before, I would like to do it in very small commits and cycles, that can quickly be checked, approved and merged, over a period of a few weeks.
Are the small changes self-contained? If so, I think they can target the master branch as usual with other PRs.
If however the changes are just part of an overall redesign, where it only makes sense to publish them to users once the overall redesign is complete, we can have a separate branch in the repository, like before.
That's exactly the thing I want to and think I can successfully avoid. The changes will be iterative and evolutionary. The idea is that each one will contain something - however small - that moves in the right direction and can be included. So yes, I would like to target the master branch, in effect with a stream of small commits. It's possible to do this with documentation in a way that's not possible with code.
To help make it work, I would need to be able to rely on very short review/merge cycles, which I know is asking a lot in a project like this. On the other hand, each proposed change will typically be very small and easy to review. In fact some of them will likely seem quite trivial or banal in content, but if you can put up with that during the process, it's part of the approach.
Overall our review response is quick, usually within 1-2 days (if not a few hours). What do you think would be required for this work?
That would certainly work for me.
Thanks for offering to contribute again!
I'd really like to do this, it has been on my mind since 2017! But as it could be annoying for the team to be faced with the proposed stream of very small commits, I'd like to get a sense whether it would fit with the way you actually want to work. Regards, Daniele
Bruno Oliveira wrote:
I definitely think it would be a good idea, but I'm interested to hear what the other maintainers think as well.
I haven't heard any other replies - I would be glad to know what others think, to be sure that this will be a good way forward and of benefit to pytest (or not!). Thanks, Daniele
I'm still in favour, and it sounds like a smart way to avoid the problems of a long-lived branch. On Wed, 3 Mar 2021 at 07:57, Daniele Procida <daniele@vurt.org> wrote:
Bruno Oliveira wrote:
I definitely think it would be a good idea, but I'm interested to hear what the other maintainers think as well.
I haven't heard any other replies - I would be glad to know what others think, to be sure that this will be a good way forward and of benefit to pytest (or not!).
Thanks,
Daniele
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
-- They've just been waiting in a mountain for the right moment: http://modernthings.org/
Am 02.03.21 um 10:15 schrieb Daniele Procida:
I haven't heard any other replies - I would be glad to know what others think, to be sure that this will be a good way forward and of benefit to pytest (or not!).
IMHO this is a good idea. Anyhow, in the next weeks I will not have to to review your changes -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
On Sat, Feb 27, 2021, at 14:25, Daniele Procida wrote:
Would you be interested in my tackling this again? I believe that this approach will be successful in a way that it wasn't last time.
Thanks for the heads up. Evolution over revolution sounds good. For my part, I cannot guarantee prompt reviews, but I'll certainly review when I can. You can maybe start with a few PRs and see how it goes. Ran
participants (5)
-
Brianna Laugher -
Bruno Oliveira -
Daniele Procida -
Hartmut Goebel -
Ran Benita