What's up Python? A new Windows installer, ruff will type check, Pypi quarantines...

Jan 2025

Summary

• PEP 773, a proposal for a new Python installation experience

• Astral officially announces that ruff will get type-checking features

• Pypi adds the ability to quarantine projects to help fight malware

PEP 773 - A Python installation Manager for Windows

If you look at Python's Windows builds, you'll find Steve Dower's name all over; and he just authored PEP 773 which proposes a unified Python installation tool named 'PyManager'.

The goal is to eventually replace existing installers like the traditional exe, Windows Store packages, or alternative ones in 3rd party stores such as NuGet. It should provide commands for executing, installing, uninstalling, and listing Python versions, along with configuration options for environment variables, Start Menu shortcuts, and file associations.

For now, it only targets Windows, but doesn't close the door open for other OS later on. Only it acknowledges the project is already big enough as it is for one platform.

The current way people install Python on Windows is riddled with problems, so I understand where the proposal comes from. People don't know what to choose, how to handle several versions being installed, how to deal with the PATH, that the py the command exists, nor the implications of per-user vs system-wide, and so on.

Then there is the fact it's based on a tech that is basically abandonware, it's not easy to automate, lacks of isolation and make upgrades difficult while relying too much on the registry.

Here are a few ways PyManager hopes to solve this:

• You don't get one installer per version, but one single "Python installer" you use to install whatever Python you need.

• The installer defaults to per-user installations and version management without interfering with the system-wide Python installation (and of course, no admin rights needed).

• The approach is CLI first to install, uninstall, list, and configure Python versions, to ease automation.

• py, the command that is current the PyLauncher, will be improved to provide the PyManager's main features and you will be able to do py install 3.11 to install python 3.11.

• The current python alias in Windows will now tell you to use PyManager (in the form of the py command) if Python is not installed. It is not clear if PyManager will be shipped with the OS in future Windows versions though, but I want to interpret it as that.

If it reminds you of uv, you are not the only one. Except it will not use the stand-alone builds, which means it will provide all the goodies the usual Windows installer comes with, such as headers.

I'm glad this debate is taking place. After all, I'm a strong proponent that most packaging problems in Python are actually bootstraping problem, and uv have shown that there is an apetite for a better solution to Python provision.

I do feel nervous about a few things:

• It's a CLI-only tool, but many Python users are not very comfortable with the terminal, especially on Windows. I wish a GUI were provided a well so as to lower the barrier to entry into the Python world.

• This makes the Python installation experience online-only, you can't put an exe on your USB drive and keep it at hand just in case. It's a rare use case, but when you need it, you REALLY need it. Maybe there will the the possibility to use a local, offline index?

• This will break things. There scripts out there that download those installers based on the standard names and URLs. At least the proposal acknowledges this and gives a deprecation period, suggests warnings, and ensures aliases will support the old installers.

• The proposal says we may backfill old Python versions into PyManager, even if they are not fully compatible (E.G: NuGet build with no Tcl/Tk). I'm not fond of that idea. If you can't provide a unified experience if it's not, well, unified.

But all my interactions with Steve have taught me that he is a kind, pragmatic, and experienced professional so I want to believe it will work out for the best.

Ruff gets a type checker

The news that moved the most the community this month is of course the official annoucement that Astral is working on a type checker, or more precisely, is changing ruff's architecture to add this feature to the already very popular linter.

Yet, it's not a surprise.

Charlie Marsh already talked about it in the Bitecode podcast, explaining the very interesting technical challenges that come with having to move from dealing with one file to an interconnection of information scattered in a whole project.

They are also in the habit of building in the open, and the work for this has been wearing the red-knot label for some time.

Still, given how ruff and uv took the community by storm, with good reasons, making it official is great: it means we will likely see a first release soon.

Typing slowly improved in Python, starting from frankly unusable, to awkward, to a useful and decent feature. It's still too verbose for my taste (damn you Annotated!), but I've been using it on several projects and ended up being happy about the decision.

And the state of the type checker space is one of the reasons it's still painful to use: they are slow (especially mypy, but pyright is far from ruff-fast), missing features, unreliable, and hard to configure.

All things that Astral has a proven track record of solving.

I trust they will kill the game once more, even if I assume the first release will see more bugs and issues than their previous products since it's simply a much harder problem.

Not directly related, this month a new project popped out, uv-migrator, to automate migration to uv from pip, pipenv and poetry. It's not amazing yet, but it can save you time by pointing you in the right direction.

Although, I found that manual migration was not a big deal, but I have more experience than most in dealing with those topics.

Pypi offers quarantine

While technically this feature has been in use since August (with 140 projects marked as quarantined), I've never heard anybody talk about it until last month, hence it's making this January round.

The busy bees at Pypi are continuously improving security, and this time they added the ability to quarantine projects, meaning to mark them as potentially harmful and prevent them from being easily installed by users, without deleting them.

Indeed, because Pypi is crazy popular, it is constantly under attack and attempts to inject Malware into packages never stop. So far, when a researcher reported a project as malware, the PyPI Admins had one main tool at their disposal: complete removal. It's disruptive, irrevocable, and may not be the best course of action. After all, maybe only the last release is contaminated, but the project itself is sane and useful.

On the other hand, do nothing, and the project will contaminate more and more users.

The quarantine makes a project temporarily uninstallable by clients, giving time to reach the authors and for them to act.

Right now, it blocks the whole project, not individual releases, but Mike Fiedler (PyPI Admin, Safety & Security Engineer) hints that if the need arise, they may implement more granularity.