Is there a way to "link" a python program from several files?

[Edward A. Falk]

IOW, is there a "linker" for python? I've written a program comprised of about
five .py files. I'd like to find a way to combine them into a single
executable. Obviously, I could hand-edit them into a single .py file, but
I'm looking for a way to keep them as seperate files for development but
distribute the result as a single file.

If this were C, I'd compile and link them and distribute the resulting
executable. I'm trying to do that, but for Python.

TIA,

 

[Diez B. Roggisch]

IOW, is there a "linker" for python? I've written a program comprised of about
five .py files. I'd like to find a way to combine them into a single
executable. Obviously, I could hand-edit them into a single .py file, but
I'm looking for a way to keep them as seperate files for development but
distribute the result as a single file.

If this were C, I'd compile and link them and distribute the resulting
executable. I'm trying to do that, but for Python.

Depending on the OS, there are several options. Ranging from
distributing an .egg (setuptools) over py2exe for windows to py2app on
OSX - and some more, e.g. cx_freeze.

Google for one of the above.

Diez

 

[Brian Smith]

Depending on the OS, there are several options. Ranging from
distributing an .egg (setuptools) over py2exe for windows to
py2app on OSX - and some more, e.g. cx_freeze.

I would be interested in a program that can combine multiple modules
into a single module, which removes all the inter-package imports and
fixes other inter-module references, like Haskell All-in-One does for
Haskell: http://www.cs.utah.edu/~hal/HAllInOne/index.html

- Brian

 

[Diez B. Roggisch]

I would be interested in a program that can combine multiple modules
into a single module, which removes all the inter-package imports and
fixes other inter-module references, like Haskell All-in-One does for
Haskell: http://www.cs.utah.edu/~hal/HAllInOne/index.html

won't happen for python. python relies heavily on modules/packages being
namespaces.

Why would you want such a beast anyway? If it's about
single-file-distribution, that is solved by some of the above mentioned
tools - or even not desired anyway (say OS X bundles)

Diez

 

[Brian Smith]

won't happen for python. python relies heavily on
modules/packages being namespaces.

So does Haskell. Haskell All-In-One handles that by renaming every
top-level artifact.

Why would you want such a beast anyway? If it's about
single-file-distribution, that is solved by some of the above
mentioned tools - or even not desired anyway (say OS X bundles)

I want to package a complex WSGI application into a single CGI script,
so that users can copy the script into some CGI-enabled directory and
have it work without any further configuration, and so that it runs
faster (especially when the file is on NFS). If it is possible to run an
egg as a CGI (without modifying the web server configuration file), then
that would work as well.

- Brian

 

[Paul Rubin]

So does Haskell. Haskell All-In-One handles that by renaming every
top-level artifact.

That can't be done reliably in python because namespaces are dynamic.

If it is possible to run an egg as a CGI (without modifying the web
server configuration file), then that would work as well.

This would be an interesting enhancement.

 

[BlueBird]

IOW, is there a "linker" for python? I've written a program comprised of about
five .py files. I'd like to find a way to combine them into a single
executable.

I wrote a small wiki page to sum-up my findings about such typical
problem:

http://www.freehackers.org/Packaging_a_python_program

 

[Edward A. Falk]

I wrote a small wiki page to sum-up my findings about such typical
problem:

http://www.freehackers.org/Packaging_a_python_program

Excellent references, but maybe a bit of overkill. Everybody in my
target audience has python on their systems, I just want to send a
single .py (or .pyc) file so there's no complicated install procedure.

I mean, how *are* large python programs normally distributed under Linux?

 

[George Sakkis]

Excellent references, but maybe a bit of overkill. Everybody in my
target audience has python on their systems, I just want to send a
single .py (or .pyc) file so there's no complicated install procedure.

What's so complicated about "python setup.py install" ? Even that is
not strictly necessary for pure python packages; a user may just
unpack the archive, cd to the extracted directory and execute the
appropriate .py file(s).

George

 

[Diez B. Roggisch]

Excellent references, but maybe a bit of overkill. Everybody in my
target audience has python on their systems, I just want to send a
single .py (or .pyc) file so there's no complicated install procedure.

I mean, how *are* large python programs normally distributed under Linux?

By means of their package management. At least that's what many people
prefer.

But I don't get what's wrong with


you: python setup.py bdist_egg

your client: easy_install the.egg



Diez

 

[Edward A. Falk]

What's so complicated about "python setup.py install" ? Even that is
not strictly necessary for pure python packages; a user may just
unpack the archive, cd to the extracted directory and execute the
appropriate .py file(s).

Aha. Completely forgot about setup.py.

Unfortunately, under Linux, all it seems to do is build a tarball for
me, which when unpacked produces several discrete .py files, leaving
me back where I started.

Anyway, I did what I should have done in the first place and trolled
/usr/bin to see how other people had done it.

It turns out there are a few answers: First, you can simply just produce
the program as a single .py file (which is what I wound up doing).

Second, you can put all the .py files other than the "main" one into
/usr/share/<programname> and then append that directory to your
path before importing anything.

Third, you can put all the .py files other than the "main" one into
/usr/lib/python2.2/site-packages/<programname> and then you don't
have to modify your path.


The second and third methods have the advantage that you can have .pyc
files hanging around.


Anyway, thanks for all your input.