On Sat, 13 Nov 2021 at 08:47, Stephen J. Turnbull <stephenjturnb...@gmail.com> wrote: > > A final comment: I wonder if you're being too conservative. It's true > that generally we prefer small targeted modules in the stdlib, but > everybody needs tests (even if they don't know it ;-), and there might > be quite large audiences for the great majority of PyTest. So maybe > we could get all of PyTest in (perhaps in a slimmed-down form without > some of the redundant/deprecated functionality). > > As I mentioned, I'm not a PyTest user (yet! :-), so I wouldn't be a > good proponent for this. But I find the proposal exciting.
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. 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-le...@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/KZEZ2QHR5V6QIHD7QQM75F7I2724JTKN/ Code of Conduct: http://python.org/psf/codeofconduct/
