@henryiii very nice. I once resurrected a project with unpinned requirements by checking PyPi for each package to find the version at the time… so nice to have a tool that can do it now.
Google fired their Python team, including one of our pybind11 lead developers (the list of accomplishments of that team is, ah, was, impressive!) We'll need to tighten up our min version support for pybind11, so I've opened up a poll: https://github.com/pybind/pybind11/discussions/5124 3.7+ or 3.8+? #python
We just released pybind11 2.12! Along with lots of fixes and features, this is also the first version to support NumPy 2.0 - please update and release new binaries of your packages before 2.0 goes final! You don't need NumPy 2 when building with pybind11! https://github.com/pybind/pybind11/releases/tag/v2.12.0#python. #release
Switching from mamba to prefix.dev's pixi in GitHub Actions for my book build took setup time from about a minute to 13 seconds (as long as you don’t cache). And now it’s fully locked, too! Quite happy. And it's simpler in Actions. https://github.com/henryiii/se-for-sci/pull/42
Cibuildwheel 2.17 is out! Highlights include a new inherit table for overrides, official GHA Apple silicon (macOS-14) support (was experimental in 2.16.5), auto platform detection when running locally, and setuptools/wheel removed. https://github.com/pypa/cibuildwheel/releases/tag/v2.17.0 thanks @joerick! #python#release
Nox 2024.3.2 is out! The new optional uv backend is blazing fast, and it has several long awaited features, like --force-python on non-parametrized sessions, venv reuse options, an envvar for backend selection, backend sequences with fallthrough, and more! #python#release (note: "virtualenv" is the Nox backend selector, it's virtualenv + pip)
@henryiii Ugh I have a bit of a problem with how you formulated this. In this case the 18 seconds difference is not because of virtualenv, but instead of because of pip... If I would have to guess I think uv it's probably around 50ms faster than virtualenv..
@henryiii This is honestly pretty shocking to me. I would have been confident that the bottleneck for pip was disk I/O and network latency, in which case rewriting in Rust would not really matter.
Is pip just slow now because of the resolver? Or is pip leaving a lot of performance on the table?
@pganssle@henryiii the latter, and uv is using a lot of smart caching techniques and doing things where code complexity provides bits of situational speedups that are all adding up.
And, it's making strong-ish assumptions about what to expect from index servers and such (which is good for PyPI but not generally).