I can try to chime in a little more on these…

pdm - great alternative to poetry, PEP-compliant, with lockfile support

Not so sure about pdm. It looks like uv is gaining more traction. It is releasing quite frequently and replaces so many different tools… perhaps it could shrink the size of WinPython quite a bit once it is mature enough to include.

fire - Google-developed argument parser

Would recommend typer over fire, since it has the same feature set and then some. It looks a bit nicer as well.

flet - beautiful GUIs

flet is promising. Flutter is backed by Google and looks beautiful, but learning Dart just to use a GUI framework is a nonstarter for most people, so wrapping it in Python just makes sense. Excited to see how it matures. There is a recent Talk Python episode here with the creator: Podcast, YouTube.

loguru - simple logging

loguru looks nice, 21k stars, more Pythonic than logging if you ask me. Not sure how it is performance-wise, though.

paramiko-expect - expect-like syntax for paramiko

Discontinued.

pexpect-serial

Looks like newer versions have issues, and it is possibly discontinued. The code looks trivial enough that this could just be implemented by someone who really needs this functionality.

scp

Is this library robust and secure? It has less than 500 stars. What are the advantages of using SCP via paramiko, versus just shelling out to the scp binary included in Windows?

codespell

If a spellchecker is really needed, I would recommend typos over codespell since the former is implemented in Rust and quite a bit faster. But this seems like more of a CI/CD tool and doesn’t bring any utility as a library you can use with Python…

commitizen

Looks good, but this is a JS tool, and also seems like more of a CI/CD tool. Let’s wait and see if uv gets a feature like this.

cyclonedx-bom

This is very relevant. See PEP 770, which just got accepted.

pre-commit
pre-commit-hooks

I love precommit. Although, I think it creates ephemeral virtual environments on the system for running the tools declared in the project’s .pre-commit-config.yaml. This could be tricky to manage within WinPython’s self-contained directory structure, if it isn’t configurable.

ruff - this one is amazing... replaces black, autopep8, flake0, pyupgrade, pylint and tons of other packages

I can vouch for this. ruff is extremely fast and is a drop-in replacement for so many other static analysis tools. It could shrink the size of WinPython considerably. But even though it supports the rulesets of all the other tools, it would force users of black, flake, etc. to migrate if those tools were dropped from WinPython.

types-paramiko
types-pexpect
types-pyserial
types-pywin32

Are these just typing stubs? Type hints are always nice. If only the original projects just included these in their base packages…

pytest-asyncio
pytest-cov
pytest-csv
pytest-html
pytest-mock
pytest-randomly
pytest-subprocess
pytest-sugar
pytest-xdist

Some pytest plugins automatically alter pytest behavior without any configuration or opt-in. For this reason, I cannot recommend the plugins below, since they could surprise WinPython users:

pytest-randomly

This randomizes the order of tests without configuration. Would recommended the pytest-random-order plugin instead, which is opt-in by default.

pytest-sugar

This alters the appearance of pytest (subjective) and makes failures show instantly. This may be undesirable to some users and confuse them.

pytest-cov
pytest-mock

I have personally used pytest-cov and pytest-mock extensively and can vouch for these.

pytest-xdist
pytest-html
pytest-asyncio

Bryan Okken from the Python Bytes podcast maintains a list of the most popular pytest plugins and has some commentary, and these place highly on it.

Based on his list, I could also recommend these:

• hypothesis
• pytest-rerunfailures
• pytest-timeout
• pytest-metadata

pytest-csv
pytest-subprocess

These plugins are pretty unpopular. pytest-csv is 4 years old. I can see the value in making a parseable pytest report, but besides that, I would argue that the report should be first and foremost human readable which is probably why pytest-html and allure-pytest have more downloads. If only Allure didn’t require Java…

Regarding pytest-subprocess… subprocesses are easy to just mock and shouldn’t warrant a whole plugin.

mkdocs
mkdocs-material
mkdocstrings[python]

These are indeed very popular packages. mkdocs seem to be rapidly becoming the go-to documentation tool of choice, with Markdown considerably more popular than reStructuredText. mkdocs is similar to pytest in that sense that it takes an extensibility/plugin-based approached.

Sphinx, however, has a lot of users. It would probably not be a good idea to replace it with mkdocs since it would force them to migrate.

Hopefully this helps! I know that keeping WinPython to a manageable size is one of the goals, and keeping the package list modern and relevant makes this a big challenge. @stonebig has the final say in what makes the cut and should know much better than me what would work best for WinPython users 🙂

General Remarks:

• total size of WinPython must be kept below VirusTotal limit, today 650 Mo,
• by default, existing wheels do increase in size, with a "hubble constant" of about 4% per year
• adding several packages participate to that expansion also.

So there is a permanent search for complementary actions to keep size in check, where help/allies is never in over-supply.
In particular:

• favorize DLLs convergence / less vendoring
• influencing devs on "total size"
• droping tech or package, when it's the less bad way.
• adding or replacing packages

Currently WinPython is kept at about 600 Mo, to leave room for "smooth" maneuvering, when a maneuver will have to be done.

on the list:

• hypothesis is there
• pdm/poetry: "pip"+"pep751" shall become equivalent to pdm/poetry,
• typer apparently way more popular than fire, and fire is not a wheel
• flet: no obvious "forward choice" between flet/kivy/toga/streamlit/Qt(s)/other(s) yet
• ruff / uv: are iterating way too fast for their supposely stable domain, 1 version per year for python, 1 per 5 years for wheel
• cyclonedx-bom: never heard of it until now , same for the devs ... but if it's a good idea, they will do noise, and PEP 770 is I presume on the ToDo