Packaging and shipping a python library and scripts, the professional way
<p>I have the task of packaging and shipping a commercial application bundle, which will include:</p>

<ol>
<li>a python library (developed by us)</li>
<li>some python programs depending on the library above</li>
<li>additional libraries not developed by us, but which are dependencies of our library.</li>
<li>a complete python installation (python 2.6)</li>
<li>additional stuff, libs and programs in other languages. Not a concern here, as they are not hooked into the above machinery, and the current shipping process works already.</li>
</ol>

<p>The bundle is shipped to Linux, OSX and Windows. On Linux, it's distributed as a simple tar.gz. The user just unpacks the tar.gz and <code>source</code> a provided bash script in <code>.bashrc</code>, so that the environment is correctly set. On mac, it's a dmg. On windows, I have no idea. The windows guy is not here today, but what I see is that an exe is created somehow.</p>

<p>I will now explain in more detail the above points.</p>

<p><strong>Our Python Library</strong></p>

<p>We don't want to give out sources, so we want to provide only compiled python files. A better strategy to make them even more tamper-proof is welcome, even if it involves some deep hacking (e.g. I once saw magic done importing stuff from a .zip which was "corrupted" ad-hoc). The library at the moment does not have C level code or similar platform dependent code, but this is going to change soon. We will therefore have to provide platform-specific compiled <code>.so</code> together with the pyc.</p>

<p>Clearly, this library will be shipped in the package, together with the rest of our application. It will therefore be installed on the downloaded bundle. For this reason, it must be fully relocatable, and the user must in some way (either manually or via our env script) add the location of the untarred package to PYTHONPATH, so that the interpreter can find it.</p>

<p><strong>Our Python Programs</strong></p>

<p>We will ship applications in our bundle, and these applications will depend on our library. The code of these applications must be either visible by the user (so that he can learn how to use the library interface), or not visible (for those utilities we want to keep closed-source), so a double approach is called for.</p>

<p><strong>Additional Libraries</strong></p>

<p>Our library depends on 3rd party libraries we will have to ship, so that the user is up and running without any dependency hunting. Clearly, these libraries will be installed by us in the bundle, but we must hope these don't store the install path somewhere during the build, because that would make them non relocatable.</p>

<p><strong>Our python</strong></p>

<p>We will ship our version of python, which we assume the user will run in order to access our script. This is because we want to be sure of the python version running. Also, we may tinker a bit the executable or the standard library. We may have a concern about the interaction of this python with the standard python, and if the user wants a specific library on our python it will have to install it within our bundled package, and not on the standard place for libraries.</p>

<p><strong>Request</strong></p>

<p>I need to make my mind around this task. I've seen it done, but never done it personally, so I need your point of view. What I presented above is how I think things should work, according to how things are working right now, but it may be wrong. Any hint, quirk, suggestion, or strategy for a successful deployment is welcome. Given the complexity of the question, I already announce a high bounty on it, according to the best answer I can get.</p>
