Feature discussion: Add support for cross-version builds?

[pganssle]

Considering our version support strategy going forward, I was wondering if it might make sense for us to start trying to at least partially decouple the version of Python used to run build and the version of Python used to actually do the build. Similar to the way that virtualenv takes a -p option. This would allow us to drop support for installing python-build in Python 2.7 or other older versions of Python even before we are comfortable dropping support for using build to build packages _targeting _ those versions, because end users could do, e.g. python-build -p python2.7.

This might conflict somewhat with #103, because venv does not have support for cross-interpreter builds (though we may be able to work around that easily enough).

[FFY00]

I would be fine with this but I struggle to see the benefits. I don't plan to drop support for installing on Python 2 soon as it is relatively easy to keep it going. If it becomes more difficult and we decide to drop it, I could still backport relevant bug fixes to the last version that supports Python 2 for a little while.

Which benefits would this provide? If it's just for us to be able to drop Python 2, I would say it is not worth it as I think maintaining all that complexity is much harder than also just maintaining Python 2 support in the codebase.

[pganssle]

If it's very complicated to pull it off, it may not be worth it. The benefit is that, to some extent, it would be nice to be able to decouple the support matrix for running python-build from the support matrix for build targets. As long as python-build can only execute builds for the version of Python it's installed in, python-build must be able to run anywhere you can execute builds in order to build platform-specific wheels for those platforms.

Another potential use case: right now in the "no isolation" mode, you are guaranteed to be building in an environment that has python-build and all its dependencies installed in it (not great). Adding support for a -p would allow you to install python-build in a virtualenv (or equivalent) or compile it into a monolithic self-contained executable, then install only the build backend's dependencies.

In general, I think it would be desirable to make it more of an implementation detail that python-build is even written in Python (though for practical reasons it would be annoying if we migrated it over to something else, since so many people would be executing python -m build or pulling it in via virtual environments). It is likely to make it easier for people to work around the limitations of their unusual environments, it will make it easier to write code like "install python-build and then run it for 5 different interpreters", etc.

That said, I haven't tried to implement this, maybe it's horribly difficult to achieve — if most of the nitty-gritty code would need to have a wide support matrix anyway because it involves calling build hooks in the target environment, we might get very little benefit out of this because the bulk of the code needs to be widely compatible anyway.

[ofek]

Is this being worked on?

[pganssle]

I'm not working on it. I assume no one else is because it's not trivial and it's not on the critical path for a successful "production-ready" release.

I think it's safe to just work on it if you're interested @ofek. It might be helpful to investigate how this would interact with #103.

[FFY00]

With venv it should be fairly easy, but I don't want to commit to anything just yet. I also want to keep in mind that we could move away from venv, so I don't want to lock myself into a feature like this for now.

IMO, I think we should think about this after python-build is stable and we don't have any major issues.