Packaging and shipping a python library and scripts, the professional way

后端 未结 9 1391
执念已碎
执念已碎 2021-01-30 01:50

I have the task of packaging and shipping a commercial application bundle, which will include:

  1. a python library (developed by us)
  2. some python programs dep
相关标签:
9条回答
  • 2021-01-30 02:31

    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.

    0 讨论(0)
  • 2021-01-30 02:32

    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

    0 讨论(0)
  • 2021-01-30 02:34

    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

    • For Unices consider creating native OS packages. They provide better integration and visibility with processes like compliance, change management, dependency management, etc.
    • For OSX others have already suggested py2app. You may also be able to leverage MacPorts package format or the Fink package format.
    • For Windows others have already suggested py2exe.

    Relocation and Config Requirements

    • Put your Python executable under .../libexec. This prevents it from accidentally being called.
    • Change the name of the Python executable to prevent confusion. ie. /usr/local/libexec/<pkg>_python
    • Distribute the .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.
    • Install your libs in the correct location under /usr/local/lib/app_python/site_package/... and you won't need to use PYTHONPATH.

    Shared Libraries

    • If I remember correctly you'll want to make sure you strip any rpath entries from the libs as this can mess with their ability to be relocated.
    • The native OS packaging should help with any dependencies the shared libs require.
    0 讨论(0)
提交回复
热议问题