shipping python

Kristen J. Webb kwebb at teradactyl.com
Wed Oct 12 17:10:08 EDT 2011


I tried experimenting with .pyc files only to end up at:

RuntimeError: Bad magic number in .pyc file

can't run 2.5 pyc files on 2.6 :(

My main motivation to use .pyc is to keep end users from changing scripts,
breaking things, and then calling us.  Tamper proofing may be an
alternative approach if anyone has suggestions.

Otherwise, trying to summarize my goals:

	1. Distribute python (and other stuff) across many platforms
	(Linux, UNIXes, OSX, Windows)

	2. Support the current 2.X version of python installed on the system

	3. Take advantage of python modules that use shared OS libraries
	(e.g. libssl.so.whatever)

	4. For linux especially, support many distributions/versions
	(getting openssl to work right, for example, is a tricky problem)

	5. Take advantage of the latest python modules whenever possible
	(hence the argparse testing).  I realize that I may be able
	to go back so far for this to make sense...

	6. Provide additional product functionality through our own
	shared libraries (c code).

I'm assuming that the customer system has python 2.X installed, otherwise they
can use their favorite OS method to get it in the standard way.

Looking at methods that try to package and run without python installed at
all do not look appealing, anywhere from does it work, to export issues,
to needing a C compiler on the client system.....

Shipping .py files and support for modules like argparse for
backward compatibility is what I've come up with so far.
Then they have everything I need to create and install a .pyc file.
(The can modify the installer .py files, but I expect this to be
less of an issue and may be able to make my own simple tamper detecting
for this).

Can anyone suggest better strategies, or point out where this just won't work?

Is distutils a good starting point?

Many thanks!

Kris

On 10/11/11 7:31 PM, Steven D'Aprano wrote:
> On Tue, 11 Oct 2011 17:04:45 -0600, Kristen J. Webb wrote:
>
>> After some more digging I see that I can easy_install argparse on my
>> development system.
>>
>> My question is will I be able to ship this to a customer?  Can I create
>> .pyc files so that the customer does not have to install the argparse
>> module?
>
> Yes, and yes. The licence of argparse is a very liberal licence, so you
> can just include it in your application. There's no need for the user to
> install it separately.
>
> You could include just the .pyc file if you insist, but I personally
> don't like or recommend .pyc only installations.
>
>
>> If not, and I want to go back into the 2.3+ range, should I just use
>> optparse?
>
> That depends on how complex your command line arguments are.
>
>

-- 
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: kwebb at teradactyl.com
VISIT: http://www.teradactyl.com

  	Home of the

  True incremental Backup System



More information about the Python-list mailing list