None of pip, uv, pdm, poetry or hatch (or pypa/installer) currently implement generation of exe script wrappers on Windows for whl .data/scripts/* whose 1st line is #!python or #!pythonw (I tested all mentioned tools and read pypa/installer). All of these do implement said same for .dist-info/entry_points.txt console / gui scripts though. There are real whls in the world (dill for one) that take Binary distribution format - Python Packaging User Guide seriously and package .data/scripts that use #!python. What is the PyPA take on this? The only charitable take I can come up with is “Recommended” is doing alot of work. As a tool author I’ve run into implementing a PyPA spec as written being considered bad practice in the past (doing an ast-parse to properly handle PEP 723 metadata extraction). Would it be considered bad practice to implement this spec and provide exe data scripts wrappers on Windows?
It’s not “considered bad practice”, but on the other hand it’s certainly not required by the spec.
If you want to implement this, either in a tool of your own, or as a PR for one of the existing installers, you’re more than welcome to. If you submit a PR, it will be up to the maintainers of the project you’re contributing to whether they want to accept your submission, of course.
Some things to consider:
- Not everything in the
scriptsdirectory will be a Python script. Do you plan on supporting bash scripts? Fish scripts? Windows.batfiles? Powershell scripts? They don’t even need to be text files - it’s not illegal to put a binary executable inscripts(it’s non-portable and probably never happens in practice, but it’s allowed…) - You’ll need to either write your own script wrapper, or check that whichever one is used by your target installer supports wrapping raw script files. I suspect that some will only wrap the entry point syntax for referencing the code executed by the wrapper.
As I said, you’re welcome to do this. But the reason existing tools haven’t done so is basically that it’s a lot of work to support a rare, and largely obsolete, feature. So be prepared for some pushback (even if you do the work of writing a PR, there’s still the maintenance cost of supporting the code).
I won’t be asking other tools to do this, I just check other tools behavior often when working on Pex. It is definitely not hard to implement at all when you already implement exe script wrappers for entry_points.txt like all mentioned tools above do.
FWIW all those tools do rewrite the shebang (Looks like #!C:\..., which is useless). So they already do some amount of work, just not the right work for the Windows case.
Ok. I’ll implement then.
Apologies, I didn’t realise you were the author of pex. Good luck!
They don’t even need to be text files - it’s not illegal to put a binary executable in
scripts(it’s non-portable and probably never happens in practice, but it’s allowed…)
@pf_moore I will note I find it slightly shocking you say this in your current role since uv, not obscure at all, does this. And it itself does it in a non-obscure way (non-bespoke at least), it uses maturin.
I don’t find it shocking at all. Paul’s position does not mean he is expected to personally analyze every wheel file for every major project on PyPI. As well, he very well may not even install uv from its wheel on PyPI and instead do it using uv’s own standalone installer or some other package manager (uv themselves list the wheel as the 2nd option after the standalone installer).
I think Paul covered this perfectly already which is doing the work for a largely obsolete feature is just not high on other peoples roadmaps right now. And the Windows case is usually the one that takes the most effort to get to work. Linux and MacOS generally fall in line with each other enough that it is table stakes for doing them. I am aware of the fact that hatch does not support this right now and in the future if there are enough users that ask for it we would likely add support. We just do not see a ton of users asking us for this to pick it as work to do over things our users are asking for.
With that said, I also do not think this is a bad practice if you implement this in Pex. I would take the stance in the future that when evaluating what other tools are doing with regards to specs, is the lack of implementation more driven by the lack of bandwidth rather than anything where tools are saying that it is a bad practice to implement this part of a spec.