On 10/12/2011 10:10 PM, Kristen J. Webb wrote:
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
Why do you want to use the system python and system libraries?
If you want to avoid too much troubles and compatibility hell maybe
give PyInstaller a try, you ship just one big executable and you're done.
But apart from that setuptools is very good to know.
And also the world is a funny place, but does it really happen that
a customer changes the code in your python scripts, and the *complain*
if it doens't work anymore??
--
http://mail.python.org/mailman/listinfo/python-list
