Hello, Plonisters and Soapistas, my name is Jurgen Gmoch. I'm a Python software developer. I mostly do web development and also Linux sysadmin, and I love open source. That's me. You can always reach out to me on Twitter

at jukemark00 or via email. And today I want to tell you something about my latest open source training. This time it's about Tox. For those who don't know it, Tox is a virtual end management and test command line tool. What does this even mean? Over here, I have a little side project of mine.

This is a command line interface to the Haverbean Pwned API. And obviously I use Tox for testing. With Tox-L, you can list all the prepared environments. I do testing against Python 3.6, 3.7, 3.8, 3.9. I also create a coverage report. I lint via pre-commit,

and I also do static type analysis with mypy. I can run the test suite, let's say for Python 3.8 by specifying it, and Tox does all the heavy lifting, like creating the package, downloading all the dependencies, setting up a virtual environment, and even before I finished talking,

running the test for me. This is great, but what's even greater, Tox gets currently completely rewritten from scratch. And this is done by Bernard Gabor. One of the Tox maintainers. And what is the goal for the rewrite? Tox will be much faster. It will be more maintainable.

You can not only plug in virtual AMP, but also Docker and other back ends and many more really great features. A couple of weeks ago, Bernard announced on Twitter that he created a pre-release of the Tox rewrite for the upcoming Tox 4,

and he asked us, the users, to test the pre-release. And this is both good for us, for the users, because we can make sure once Tox 4 gets released finally, our project works with Tox 4, and it's also great for Bernard because he doesn't get all the bug reports on the day of the release.

So how do you even install a pre-release? Some times ago, I collected a couple of ways to do this. Usually I go with pip install dash dash pre, and then the package name. Over here, I've done this already, and now I have the Tox 4 binary available on my path.

I can also list environment that stays the same, and I can also run the test suite for, let's say again, for Python 3.8. As you can see, the output has changed. It's a little bit more verbose, and you exactly see what Tox is doing, and we have funky new colors, which I really like a lot.

The tests also run, and it finishes. This is all good, right? Well, I was a very early adopter of the Tox 4 rewrite, and so I noticed a couple of issues which I reported at the Tox issue tracker and which were fixed basically by Bernard in no time.

So I tested the pre-release for Tox for maybe my 10 personal projects, also for my 10 work projects, so I'm done now, right? No, because I'm also a co-maintainer of the Soap project. For those who don't know, Soap is the grandfather or grand lady

of Python web frameworks. It's older than 20 years still alive and kicking, and by the way, it's also the base for Plone. So one of the outstanding features of Soap is that almost all plugins are available

at the GitHub organization. Compare this to, well, you can, whenever you want to fix something, when you want a new feature, when there is anything, you can just go to the repository, either apply the changes yourself or write an issue,

and then you get a new package. Compare this to other frameworks where mostly individuals are writing the plugins and maintaining it, at some point in time, they may lose interest, maybe they don't use it anymore, maybe they switch the framework

or even the language or the job, and well, you can obviously fork it because it's open source, but you can't maintain all the repositories. So still those 393 repositories have to be maintained, but actually it's more like 300, a couple of them are already archived.

How do we do this? We are not so many maintainers. I found a really cool tool, it's called Our Repos written by Anthony Sottile. Once it's installed, you have a couple of command line issues, command line interfaces here. Like All Repos clone, you can clone all repositories at once, all 300,

because you don't want to do this by hand. You can search for files in all repositories, you can grab blazingly files in all repositories for code patterns or whatever. You can list all your repositories and it's especially cool, you can use all reposet,

the stream editor on all repositories. This means you can apply changes to every single of the 300 repositories at once and even create pull requests. A couple of months ago, when Travis CI announced that the migration from Travisci.org to Travisci.com,

well, the zone maintainers had to update like 300 repositories, you know, the little batches for the coverage, the green little batches, that all has changed. So how do we do this? I used All Reposet, a one-liner, I hit enter and boom, boom, boom, boom, boom,

like dozens and dozens or hundreds pull requests were created. Sadly, it was not during Hacktoberfest, so I didn't get a shirt, but I have a nicer shirt of PyCon.de. So this time we don't want to manipulate the repositories,

but we want to apply talks on them. How do we do this? There is no special command in all repos to apply arbitrary command line programs, but you can use all repos as a library. When I have a look around here, you see all repos list, repos is listing all repositories

and that's basically the thing we want to do, but except listing them, I want to apply talks on all repositories. Let's have a look how this works. I can issue all repos list to repos, and then I apply a config file.

So I only apply the commands on the soap repositories and not on the other repositories. This is the small little list of soap repositories we maintain. And okay, this is the list one

and now I want to show you how to apply talks. I used all repos list, repos command and I updated it a little bit. You can see here that I use all repos as a library.

Here is the command line interface. And when you scroll down a little bit, here the fun begins. I iterate over all repositories. Then I look for a talks ini file, which is the config file. And if it's there, I create a sub process,

run the development version of talks for them. And afterwards I check the return code. Zero means it was successful and otherwise it failed. I need to collect all the failed repositories for later investigation. At the very end, I just print the result. So how does it work?

I just also issue talks. Then I also specify that I want to only run this on the soap repositories. And well, this will take too long for this talk.

I can cancel it now. And the very first run on the 288 active soap repositories showed we have 17 repositories with our talks, 62 runs were successful and 208 were broken.

But well, this sounds bad, but it's not because there are some error clusters and some repeating errors and it wasn't all that bad. I then went through all the failures and reported the issues either in the talks issue tracker on the soap issue trackers or on the blown issue

trackers, which are also tested. Well then, Bernal can fix them all eventually. I then thought, well, I really love talks and I want to give something back. So I also tried to fix one or two of the issues myself. Eventually I made it and then something happened

which I never thought of. And I got invited to the talks development team. Whoa, now I'm also a talks developer. So what's left? I just can say thank you very much, Anthony for writing all repos. Thank you so much Bernal for maintaining talks

and offering this for all of us for free for the complete world. And I think we live in great times and yeah, that's it. Thank you very much. You can always reach out to me on Twitter. My name is Jurgen Smog and see you.