Is it wrong to package Python with my framework?

Here's the deal. I am developing a framework whose sole users have extremely messed up python installations on their servers (Linux). They all have multiple versions of Python on their servers and their PYTHONHOME and PYTHONPATH variables are pointing to different versions.

Since my framework will require Python 2.6, I thought that a safe way to distribute my application might be to bundle a pre-compiled version of Python with my application. To test this theory out, I downloaded ActivePython and bundled all the necessary files with by application. My main script calls #!/vendor/ActivePython2.6/bin/python.

So far, I have tested the framework on different server distributions and with different p开发者_开发问答eople's servers and it seems to have worked so far with no problems (yet).

My question is, are there any problems in doing this and are there any alternatives?

I'd recommend against it. You'll run into problems between 32b and 64b versions, between different libc versions, noexec locations, wrong selinux/apparmor profiles for custom paths and many other potential problems...

Unless you're planning to release (and test!) a package for each separate distribution, architecture and version, I'd say you're creating problems for yourself. The alternative is to provide both versions of course - provide the framework only by default and make the static python package available in case of problems.