There’s no mechanism in the wheel standard for distributing automatically created scripts other than console entry points. This has been true for many years now, it’s not new with PEP 660. Individual build backends like setuptools can offer ways to generate such scripts, but as they can’t be stored in wheels, you would have to invoke the backend directly to generate them.
What has changed is that pip has finally stopped[1] special-casing setuptools and invoking its interface directly. That gives you a problem, as you say, because you were (maybe unknowingly) relying on a non-standard interface in the install process.
Your options at this point are probably:
- Modify your application (or your build backend) to include the WSGI boilerplate in a function that can be called as a normal console entry point script. When I suggested this before, you said “that’s probbaly my answer”. I’m not sure why you have changed your mind.
- Use a custom install process, maybe by asking your users to run a post-install function after installing the wheel of your project. Pip won’t run a post-install automatically, (a) because there’s no standard for doing so, and (b) because that invalidates the promise that installing a wheel cannot run any untrusted code.
- Propose a new standard, adding support for other types of executables that can be created by installers when installing a wheel. This will be a very hard sell, because once we start adding application-specific types of support, where do we stop? And while WSGI is an important type of application, it’s still just one type.
or at least is in the process of stopping ↩︎