In general I'm all in for the nose -> pytest migration and pytest is what we're using in a lot of other projects.
Regarding the Puppet repo specifically though there are multiple angle to look at, that makes me wonder if those more complex scripts that requires testing shouldn't be inside the puppet repo in the first place. Also I think that if we start touching it we shouldn't just blindly replace nose with pytest but instead re-think the whole Python testing within the Puppet repo.

To give you a bit more context, here are other angles to look at the 'python testing in the Puppet repo' topic (I'm sure I'm missing some additional ones):

• We have both python3 and python2 files that should be linted with the same-version tool (as of now flake8, we could add more). See T184435
• We have a lot of python files that don't have a .py or .py.erb extension in the Puppet repo, while being Python files, and those are not checked at all. See T144169
• We should add checks to prevent from adding new Python2 code, but is quite tricky, see T197804
• Each tox environment to run unit tests currently is testing single modules with test files leaving in the same place where the deployed files are, often without any structure. Again, for the py2/3 coexistence it might become tricky within the same module during the long-term conversion of 2to3.

I recently added python tests to one of my modules with a significant python script in it. I honestly don't see how a python script that isn't tested that does something complicated enough to merit being in python should be in puppet (on the flip side of this). I have been on a personal crusade to start implementing testing discipline for code managed by the cloud team so that taking over existing projects is safer and more consistent.

To put it a different way, I'm uncomfortable deploying untested python to the environment in cloud and generally prefer to test infrastructure code in general (rspec/unittest or whatever). At least within the scope of cloud materials in the repo, I'm trying to bring it all into a testable form (even if just linting). I got python3 in the containers, and the python3 tests work great where they are (only in my tests right now), and I ensured that the tests are conditionally run. (Note, the tests I put up are in the sonofgridengine module, if you are curious and have thoughts.)

From my thinking, I am aiming to add tests to anything python the cloud team throws on servers. If something is simple enough to not test, it's probably running in bash rather that python.

I love the notion of pytest, and it is properly supported and the general thrust of foundation CI because of that. I don't think puppet repo actually gains anything from switching, but I love it in theory.

I'm now poking around also at what it would look like if all the python my team uses ended up in separate packages (debs etc), and I don't hate it...🤔