I've reported the spam to GitHub Support. In the meanwhile, I'll keep this issue locked. Sorry about the noise!

(unlocked since the accounts have been deleted)

I can make a PR here and will probably start by just calling that private function I linked to.

Is the process here to promote things like this to public functions in distlib before a PR can be merged or do we care little or not because we vendor things anyway and therefore don’t risk breaking when using private functions?

Personally, I'm uncomfortable relying on undocumented internals of our dependencies. We insist that people only use our documented API, so it seems hypocritical to not follow the same rule with regard to our dependencies.

No idea if you already have, but I do think it's worth comparing to what uv does, which I've seen go through a few rounds of trying to handle spaces in venvs.

uv uses the '''exec' … workaround for both [project.scripts] and *.data/scripts/.

How does a proper dev setup for pip work?

Seems like not only does nox not do a dev install (which makes breakpoints set in VS Code useless), tests like the one I modify copy pip into the venv which also makes breakpoints useless.

Can I make it so pip dev-installs itself into the venvs it creates during testing or otherwise just make breakpoints work normally?

By the way, I'll note that script files are generally considered to be deprecated (although no standard has formally done so yet). I'm not convinced we should be spending effort on adding support to script files as opposed to directing people to use entry points.

On Windows, scripts with a shebang file are not natively supported by the OS, they require workarounds using file associations and the py launcher, which don't work in all circumstances. They very definitely don't provide a production-quality user experience, unlike entry points (which use a native executable).

Any Python script can very easily be converted into a callable function within the application, and exposed via an entry point, so it seems like there are very few reasonable use cases which would demand a script rather than an entry point. While "it's an unnecessary cost" is a prefectly good reason for not just wholesale rewriting scripts to entry points, doing so to provide a more robust user experience does seem like a good reason - and IMO better than expecting changes to pip which will allow the script approach to last for a little longer.

I appreciate that scripts with a shebang are a much more reasonable solution on POSIX, and not everything has to be cross-platform, but conversely, pip's features do have to be and that makes supporting things in pip harder.

pipx is held back from using standard directories for its data files (and maybe also cache files?) on MacOS because of this issue. I don’t think they’ll consider breaking things, so unless things get formally deprecated within the next weeks, I think we should go forward here.