Python on portable storage

[Ben Finney]

Howdy all,

I'm experimenting with carrying my personal computing environment around
on a keychain USB flash storage device. I have the usual suspects on
there: SSH keys, GPG keys, program configs.

I'm probably not the first to think that a standalone distribution of
Python would be a useful thing to have in my back pocket. Finding
information on that is proving to be a problem, however.

Can anyone provide pointers to how to go about this? My goals are:

- Carry a working Python >= 2.3 on the thing (must).
- Be able to run it on GNU/Linux systems from the device (must).
- Be able to run it on Win32 systems from the device (maybe).
- Refer to one copy of the standard library, regardless of how many
instances of the python executable (must).
- Ease of updating when future Python releases come out (maybe).

--
\ "Time's fun when you're having flies." -- Kermit the Frog |
`\ |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Ben Finney]

On 27 Jan 2004 12:59:26 +1050, Ben Finney wrote:

Howdy all,

I'm experimenting with carrying my personal computing environment around
on a keychain USB flash storage device. I have the usual suspects on
there: SSH keys, GPG keys, program configs.

I'm probably not the first to think that a standalone distribution of
Python would be a useful thing to have in my back pocket. Finding
information on that is proving to be a problem, however.

I did find this thread:

<http://groups.google.c om/groups?group=co mp.lang.python& threadm=VXcVa.2 8%24HY3.42617%4 0news.uswest.ne t>

where the OP asked much the same question; the responses were mostly
"boot GNU/Linux and run it that way". This isn't what I'm after; I want
to walk up to an existing machine, and, without rebooting or installing
any software on the machine, plug in my USB storage device and run
Python entirely from that.

This will mean having a Python executable that can run under the
existing environment, of course. What I'm hoping is that there is
information on how to set that up, so that the resulting storage has a
self-contained Python environment, assuming the executable will run in
the first place.

--
\ "I filled my humidifier with wax. Now my room is all shiny." |
`\ -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Jeff Epler]

One idea would be a directory structure that looks like the source tree:

python23/python # linux executable
python23/python.exe # windows executable
python23/Lib # shared version of /usr/lib/python2.3
python23/Lib/site.py # modify this to add any extra tweaks needed for
# things to work properly (it's loaded very early)
python23/Lib/plat-linux # linux shared-object modules
python23/Lib/plat-win32 # win32 shared-object modules

In this setup, you are assuming some set of Linux shared objects, use
ldd to find out which. (A script setting LD_LIBRARY_PATH to point at
necessary libraries before calling python could help here)

If you want to support multiple Unix architectures, make python a
shell script, and include multiple python.ARCH binaries. Have the shell
script determine the architecture, and then exec python.ARCH with
arguments intact. This should not affect the way Python determines the
default sys.path.

I don't know much about windows .dll requirements or how to resolve
problems there.

Jeff

[Jeff Epler]

I forgot to mention that you should refer to the documentation to find
out about using .zip files to store .py/.pyc modules. This will have a
fairly dramatic effect on the amount of space needed to store the
standard library.

Jeff

[Ben Finney]

On Mon, 26 Jan 2004 21:34:56 -0600, Jeff Epler wrote:

One idea would be a directory structure that looks like the source
tree: [...]

Thanks for this idea. I probably won't get the time to implement it for
a while, but when I do at least this gives an idea for where to start.

--
\ "A free society is one where it is safe to be unpopular." -- |
`\ Adlai Stevenson |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Paul Paterson]

"Jeff Epler" <je****@unpytho nic.net> wrote in message
news:ma******** *************** *************** @python.org...

One idea would be a directory structure that looks like the source tree:

python23/python # linux executable
python23/python.exe # windows executable
python23/Lib # shared version of /usr/lib/python2.3
python23/Lib/site.py # modify this to add any extra tweaks needed for
# things to work properly (it's loaded very early)
python23/Lib/plat-linux # linux shared-object modules
python23/Lib/plat-win32 # win32 shared-object modules

In this setup, you are assuming some set of Linux shared objects, use
ldd to find out which. (A script setting LD_LIBRARY_PATH to point at
necessary libraries before calling python could help here)

If you want to support multiple Unix architectures, make python a
shell script, and include multiple python.ARCH binaries. Have the shell
script determine the architecture, and then exec python.ARCH with
arguments intact. This should not affect the way Python determines the
default sys.path.

I don't know much about windows .dll requirements or how to resolve
problems there.

I can't add to the Linux part but I have Python23 installed on a USB
keychain drive to run on Windows alone. I just installed using the standard
Windows installer into a Python23 directory on the USB drive. You also need
to make sure Python23.dll ends up in the Python23 directory, probably by
manually copying it. Then to get it all to work properly I have a little
batch file in the root of the USB drive with the following,

---- setup.bat ----
echo Setting Path
path =
%1:\python23;%1 \python23\lib;% 1:\python23\lib \site-packages;%1:\py thon23\dll
s
set pythonpath = %1:\python23
---- end ----

When you mount the USB drive you open a command prompt and CD to the root of
the USB and type "setup X" where X is the drive letter assigned to the USB
drive. You can now run Python by just typing "python" at the command prompt.

This works for me. You have to be a bit careful if you already have Python
installed on the machine as sometimes sys.path includes parts of the
existing installation even after you run the batch file. I think this might
be something to do with stuff in the registry.

Hope this helps. It is cool to keep a Python in your pocket.

Paul