Packaging a proprietary Python library for multiple OSs

Roy Smith roy at panix.com
Thu Dec 5 09:09:32 EST 2013


In article <58d49c5b-c837-4dac-b764-369fea02568c at googlegroups.com>,
 Michael Herrmann <michael.herrmann at heliumhq.com> wrote:

>  1. Is it considered a bad idea in the Python community to ship one large Zip 
>  file with all dependencies?

Yes.

> How do *you* prefer to obtain and install Python libraries?

"pip install"

>  2. Is it possible to distribute the library in a form that allows for an 
>  offline installation without administrator privileges using other tools, 
>  such as setuptools?

You can use "pip --find-links" to point pip at a local repository of 
packages.  That solves the offline part.  And the "without admin privs" 
part is solved by setting up a virtualenv.

> A hard requirement is that I can only ship binary distributions of my 
> library, as this is a proprietary product. I looked at Distutils and 
> Setuptools, where the recommended approach seems to be to simply ship all 
> sources.

Keep in mind that shipping just the pyc files offers very weak 
protection against people examining your code.  Google for "python 
decompile" and you'll find a number of projects.  I'm looking at the 
docs for uncompyle now, which says:

> 'uncompyle' converts Python byte-code back into equivalent Python
> source. It accepts byte-code from Python version 2.7 only.
> 
> The generated source is very readable: docstrings, lists, tuples and
> hashes get pretty-printed.

About the only thing not shipping Python source does is satisfy a 
check-box requirement that you not ship source.  It may make the lawyers 
and bean-counters happy, but that's about it.



More information about the Python-list mailing list