Provide framework build on macOS?

[cbrnr]

I was wondering if providing a framework build on macOS would make sense. I'm not entirely sure how this works exactly, but a framework build seems to be necessary to access the macOS GUI reliably. I've tried this with my own projects (using PySide6 mostly), and even though my GUI app works fine in most cases with a non-framework build, sometimes there are no menus in the global menubar (it's really hard to reproduce). Furthermore, the official Python installers for macOS ship a framework build, so I'm guessing that there are reasons why this is a good idea in general. However, there might be downsides that I'm not aware of, but I think it would be good to discuss this rather sooner than later.

[glyph]

I tried to write up the vague constellation of reasons you might want this, and I'd love to see it. You don't need it for GUI access, but "reliably" is a good word: https://blog.glyph.im/2024/09/python-macos-framework-builds.html

[hoechenberger]

Super friendly bump – are there any news on that front, or is this planned?

[zanieb]

There's no progress here yet, it hasn't been a priority because there haven't been many concrete bugs related to it.

From @glyph's article, the following seems concerning:

Framework builds do have some small drawbacks. They tend to be larger, they can be a bit more annoying to relocate, they typically want to live in a location like /Library or ~/Library. You can move Python.framework into an application bundle according to certain rules, as any bundling tool for macOS will have to do, but it might not work in random filesystem locations. This may make managing really large number of Python versions more annoying.

I'm also not sure what value-prop there is here, since the Python org publishes framework build installers for macOS already, right?

[indygreg]

Historically I never needed a framework build of Python, so I never produced it.

To echo Zanie's thoughts, if you need a framework build, why not use the official Python.org framework builds?

So far nobody has articulated a value proposition for why this project should publish a framework build.

[glyph]

So far nobody has articulated a value proposition for why this project should publish a framework build.

I am sorry in advance for this brick of words; Pascal's apology applies :)

Here's my concern: Astral has built a great toolchain for building everything Python-related. The community tends to converge: we don't want to have 10 different ways to install Python depending on peculiar nuances of our projects. This means that recommendations, tutorials, workflows, standards, and just general vibes throughout the community will tend to simplify decisions like "how do I get Python installed?" Both the asker and the answerer of that question want the answer to be a simple statement, like uv python install, and not an hour-long consultation where you ask what the asker's needs are.

UI use-cases for Python are already relatively niche, and so a lot of people who get into using Python for desktop apps, or games, get into it because they were doing something else, and hey presto, Python magically does this other cool thing too. I think that we as a community should generally try to preserve this versatility, because that sort of pleasant surprise is great, and it's something that Python has more often than almost any other ecosystem except maybe JavaScript. Few languages can be used in so many different places.

If this project becomes the load-bearing way that everybody gets Python because it's the easiest answer for "how should I install Python", macs are popular with developers, and maybe even the official upstream build atrophies and eventually gets discontinued (python.org doesn't distribute binaries for Linux, if the audience for Mac builds shrinks to a very fringe use-case because everyone is using this project instead, perhaps they give up on that platform too), then various UX automation workflows won't work, and they won't work in a peculiar, half-broken way because UNIX-ish executables are peculiar and half-broken on macOS, then we end up in a situation where, in the rare case, when a developer veers out of their data-science lane to try out some PyPI package with some GUI or a game made with PyGame, something is wrong, the window doesn't take focus properly, the app icon is blank, or whatever, then folk wisdom develops "oh, you can't use Python for this, it's just kind of janky and broken. you should learn Swift instead" and the community loses a valuable direction for growth and cross-pollination.

Now, all of that doesn't have to be your project's problem, per se. Perhaps python.org should just fix their official builds to be relocatable, and then uv python could just install those instead. Or perhaps the overhead of grabbing the official build is not all that hard, and desktop things could keep doing it, and perhaps we could just build some conventions around detecting build-framework-ness where libraries could issue a clear warning rather than silently breaking in some way. Maybe that last one is the right one because some of these things also have code-signing and entitlements requirements that aren't fully resolved by frameworkifying build; this is just one step down an series of annoying rabbit holes.

But, all things being equal, if it isn't an unreasonable amount of work for you, I would personally love it if we could all stop worrying about the framework/non-framework distinction because everybody just stopped making non-framework builds and they all worked for every purpose without some people needing to learn and re-learn this unfortunate and extremely esoteric detail.

[cbrnr]

FWIW, have you considered working with the PSF on this one? I remember Brett Cannon talking about this topic on Mastodon (he made a poll if people would find it useful to have this option), but I cannot find that post anymore.

[hugovk]

@cbrnr This one? https://fosstodon.org/@brettcannon/113148479890148086

[zanieb]

FWIW, have you considered working with the PSF on this one? I remember Brett Cannon talking about this topic on Mastodon (he made a poll if people would find it useful to have this option), but I cannot find that post anymore.

Yep we're talking to Brett and other CPython developers.

[zanieb]

It seems possible that the solution is that uv should install macOS framework builds from python.org instead of adding framework builds here? Unsure. Is it feasible to make the framework builds relocatable?

[glyph]

Is it feasible to make the framework builds relocatable?

Build tools like py2app and briefcase have to rewrite framework builds to make them relocatable, because you can't dictate where a user puts an app bundle, and the framework needs to live in that bundle. Not sure how https://github.com/beeware/briefcase does it, but py2app uses "macholib" to rewrite the binary relative to the executable path, like this: https://github.com/ronaldoussoren/macholib/blob/e3c7ece6d39afbdcff75e8a2075798953918502d/macholib/MachOStandalone.py#L110-L115

I think that you could build a framework build the usual way, then do something similar as a post-build fixup? As I understand it the main relocatability issue is actually the Python binary itself, which links against the static /Library path. libpython has a self-reference which it seems in your builds is already the invalid /install/lib/libpython… so this wouldn't be any worse; just rewrite to a similar @executable_path with macholib and the result should be the same.

To be clear, I just know that it's possible to do because these tools do it, and I know that it's possible to do with a small reliable binary patch because I know that py2app does it. However, I don't know if the thing py2app produces is fully compliant with other constraints that this project might have (I suspect not, as it strips down many Python features, doesn't include most of the headers, etc, in service of just having the relatively minimal stuff you need at runtime rather than the full development install of Python)

[glyph]

It seems possible that the solution is that uv should install macOS framework builds from python.org instead of adding framework builds here?

The only issue with this is that it would require admin access to install the macOS framework builds, on account of requiring write access to /Library.

(Perhaps making the first-party framework builds properly relocatable at build time is actually just a thing Python.org could do, and then uv could install those without worry?)