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