I have the task of packaging and shipping a commercial application bundle, which will include:
I don't quite understand how your users end up using the program, so apologies if this isn't useful.
Have you looked at py2exe and py2app? They'll let you create a much more obfuscated executable on Windows and OS X that might be even easier. Fewer dependencies and things to go wrong.
We deployed an internal, company wide app with py2exe, and it was trivial. Regardless of what other pythons the user had or didn't have our script was an easy wizard installer, and worked reliably. It included a number of Python and C libraries we had to bundle up, along with a python interpreter. However we weren't trying to hide the contents, just make it easy.
Although this is answered really well I still want to link this to my post as we had the same issue. Some people might find it useful CX_Freeze Linux Python Packaging
This will vary depending on your target market. In specialized niche industries there is more variety in how stuff is distributed. In heavily commoditized areas I would expect native OS package (at least if I were a customer). I tend to take the quality of the deployment package as indicative of the quality of the software in general. I associate native OS packages as higher quality than other formats largely because the dependency information can be complete. This makes it easier to do some compliance testing and change management.
Native OS Packages
Relocation and Config Requirements
.../libexec
. This prevents it from accidentally being called./usr/local/libexec/<pkg>_python
.py
for the bins to make them easily relocatable. You can change the Magic Cookie at install time to whatever the location your Python was installed in via an install script. The only code you need in the bin is a line that calls into your lib which is a pyc./usr/local/lib/app_python/site_package/...
and you won't need to use PYTHONPATH
.Shared Libraries
rpath
entries from the libs as this can mess with their ability to be relocated.