Package requests #1354

Activity

1. chrisrodrigue commented on Apr 23, 2025

   

   chrisrodrigue

   on Apr 23, 2025

   Last edited by chrisrodrigue

   More actions

   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 🙂
2. stonebig commented on Apr 23, 2025

   

   stonebig

   on Apr 23, 2025

   Last edited by stonebig

   Contributor

   More actions

   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
3. stonebig

   added

   packages

   on May 4, 2025