© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
I need to look at it again, but I think that this patch is covered by the current suite of tests (whether the buildout fails or not). If I'm wrong, I will add tests that cover this.
Let me describe the use-case in full.
We develop applications that are meant to run on various flavors of Windows, Linux, Solaris and other UNIXes. We do not rely on the system-level python, because there isn't such on all the platforms we support.
So we have a build system that compiles Python on our platforms in such a way that it makes it completely relocatable (with the shared libraries and all) on the file system for that particular OS.
We use buildout for doing this, but the build process itself is irrelevant to this issue (The code is on github: https:/
Now that we have this Python, we want our applications to use this one, and the way we currently do it is this:
* We use some version of python to run the bootstrap (we don't care which Python this is, because we will stop using it shortly
* We download the our pre-built Python interpreter
* From now on, we use the new interpreter.
All of this is done on our development hosts. In this way, each of our apps has its own isolated interpreter, which we can upgrade when necessary without risking compatibility with other apps.
For deployment, we pack everything into an archive (incl. the interpreter), and extract it at customer's site. Since the archive already contains our Python interpreter, we use the same one both for bootstrapping and other things.
What does this has to do with this issue? If the interpreter used for the bootstrapping is 32bit, and our pre-built Python is 64bit, and there's a need to install a platform-dependent or python-
We've been working on this use-case for quite some time, I would be happy to further discuss this.