@mrmathematica Thanks for putting this together.

Working towards a more relocatable distribution is a goal of this project but we also want to balance this with not deviating too far from upstream. Rather than modify sysconfigdata as part of this projects build script a preferred approach would be apply a patch to CPython itself to performs these modification as part of the standard build process. If these modification are part of building CPython directly the patch can be submitted upstream for inclusion in a future release of CPython. See#861 for an example of this type of work where portions of the RPATH adjusts in the build script are migrated to a patch.

If this is something you are interested in working on, I'd be happy to assist.

@jjhelmus
Do you mean a patch file here first, or a patch to CPython itself? A patch to CPython, even if merged, will likely only be adopted for python 3.15+, thus not helping all existing python versions. If you mean a patch file applied in this repo, I think we can work together for that.

A patch here first is what I was referring to.

OK@jjhelmus I give that atry.

I see there can be all kinds of downstream places that touches_sysconfigdata_ again, includinghttps://github.com/python/cpython/blob/a03efb533a58fd13fb0cc7f4a5c02c8406a407bd/Mac/BuildScript/build-installer.py#L1360C1-L1385C15 as mentioned in one of the touched file. All such places need to be modified to work with the new_sysconfigdata_.py file format and f-string inside dict, which is kind of fragile.

On the otherhand, the change in this PR is much more robust. It happened at the same place in this repo where_sysconfigdata_.py is hacked, which is the last step in the process.