On Sat, Nov 13, 2021 at 3:52 AM Paul Moore <p.f.moore@gmail.com> wrote: I love pytest, and I'm a happy user of it. But I've never wanted it in
the stdlib. Because it's a developer tool, basically.
I have no problem with getting pytest from PyPi for my projects. But there are two use cases where that’s less than ideal: 1) The Python standard library itself needs tests. Granted, I suppose the stdlib could use a third party package for testing without shipping it in the stdlib, but no one seems to want to do that at this point. 2) newbies and the community— why is unittest in the stdlib if it’s not the best option?? Personally, In my intro to Python class, I do have my students install Pytest early on and start using it well before I tell them about anything about unittest. There are two reasons for that: 1) I really think pytest is the better way to go. 2) I introduce unit testing and TDD really early — before classes. So being able to write tests with simple functions is a real win. But I’m guessing that’s not a very common approach. It really is confusing to the community to have a not-recommended unittest framework in the stdlib. Granted, it’s only my opinion that it’s “not recommended”, so maybe there is no problem to be solved, but my point is that “just keep it on PyPi” is not really a satisfactory solution, IF unittest is not the recommend way to write tests for Python. Oh, point 3) I think it was Ethan that said he’d never used pytest. He’s been very active in this community a long time! So clearly having something in the stdlib is very influential. Anyway — this really needs another thread if we want to continue the discussion. -CHB As a developer,
I'm perfectly fine having my tools installed in a per-project virtualenv, or set up as standalone commands via pipx, or whatever works best for my project. I don't need the full "developer experience" in the stdlib, because pip install works fine. And yes, I know that for some developers, access to PyPI isn't as easy as that (I've been in that position myself, many times!) but there are workarounds and hacks, which are fine if it's setting up stuff once on your dev machine.
And having pytest able to change and innovate is important - if it became part of the stdlib, it would (of necessity) stagnate, and the role of innovator in testing tools would pass to someone else.
**However**, the situation is completely different for packages that are used in applications that get shipped out to end users. And "applications" is a very broad term, that covers full standalone executables, web services, one-file scripts, Jupyter notebooks, etc.
Python's story on building and deploying such applications is still pretty bad (and I say this as a packaging specialist!) We've focused on libraries at the cost of the final result, and as a consequence it's extremely easy to use packages from PyPI when developing your new application, but when you get round to deploying it, things get hard and you start wishing that the stuff you used was in the stdlib, because that would make things so much easier. So there's regular discussions about adding functionality to the stdlib, but it's *that* sort of package (requests, toml, bits of numpy, data structure libraries, etc), and not tools like pytest (or tox, hypothesis, nox, black, or flake8, ...)
So basically, I don't think it's likely that a proposal to add pytest to the stdlib would get very far (it's fine as a PyPI package) but that's specific to pytest, and as a general principle, "it's on PyPI so it doesn't need to be in the stdlib" *doesn't* apply, and won't until we have a better deployment story for Python tools.
Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KZEZ2Q... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython