Running python from a usb drive

[cjl]

Hey:

I am trying to run python from a usb drive under windows xp. I
installed python "for this user" on to a machine, then copied the
entire Python24 directory to the usb drive.

I have the following in a batch file at the root of the drive:

@path=%PATH%;%CD%Python24;%CD%Python24\libs;%CD%Python24\Scripts;%CD%Python24\Lib\site-packages;%CD%Python24\DLLs
@set pythonpath = %CD%Python24
@cmd

When I double click the file and type 'python' at the prompt I am in a
working python environment, and I am able to import modules in the
site-packages directory (in this case, django).

However, when I run a script directly from the cmd prompt (in this case
'django-admin.py' the script runs, but fails to import modules from the
site-packages directory.

Is there a command line option to python.exe or an environment variable
I can set to remedy this?

Any other thoughts?

Thanks in advance,
CJL

 

[Jordan]

If making a usb version of python was that easy, movable python would
be open source. Check out http://www.voidspace.org.uk/python/movpy/ if
you need a portable usb version of python for work or something.
Copying the Python24 directory is a good start, but doesn't include the
enormous number of registry keys that are included in the install and
are probably needed for the complete capabilites of python. I really
hope I didn't missunderstand what you were asking about -_-;
Environmental Variables? Try setting the user/system variable
"pythonpath"

 

[cjl]

Jordan:

Thank you for your reply.

If making a usb version of python was that easy, movable python would
be open source.

I knew about movable python, but I'm not using it because it's not open
source. I guess those guys but some work into it, and feel like a small
fee is appropriate, but I guess I would rather use something open, even
if it means I have to make it myself.

Copying the Python24 directory is a good start, but doesn't include the
enormous number of registry keys that are included in the install and
are probably needed for the complete capabilites of python.

Is the source of the windows python installer available? I guess I
could see what registry keys they are setting...

Environmental Variables? Try setting the user/system variable "pythonpath"

I do set pythonpath, see above.

Any other ideas?

Thanks again,
CJL

 

[Uwe Hoffmann]

I do set pythonpath, see above.

is pythonpath really case insensitive on windows ?

 

[Steve Holden]

cjl schrieb:



is pythonpath really case insensitive on windows ?

Only because the Windows filesystem implements case-insensitive
semantics. This is nothing to do with Python:

C:\Steve\Projects\Python\dbimp>dir DB.py
Volume in drive C has no label.
Volume Serial Number is 9CA8-2A02

Directory of C:\Steve\Projects\Python\dbimp

01/19/2005 06:03 PM 136 db.py
1 File(s) 136 bytes
0 Dir(s) 15,908,880,384 bytes free

C:\Steve\Projects\Python\dbimp>dir db.py
Volume in drive C has no label.
Volume Serial Number is 9CA8-2A02

Directory of C:\Steve\Projects\Python\dbimp

01/19/2005 06:03 PM 136 db.py
1 File(s) 136 bytes
0 Dir(s) 15,908,880,384 bytes free


regards
Steve

 

[cjl]

Uwe:

Thank you for your reply.

is pythonpath really case insensitive on windows ?

I think so. After running my batch file, I can load the python
interpreter by typing 'python', and can then type 'import django'
without error. This lives in the site-packages directory, so it is
finding it.

However, there is a python script that lives in python24\Scripts called
'django-admin.py', which I am adding to my path. When I type
'django-admin.py --help' I get an error that it couldn't load the
django module. When I type 'python E:\python24\django-admin.py --help'
I get the correct output, and no errors, so I know it is loading the
module.

I guess I am trying to figure out why, and what the top "shebang" line
should be for the script django-admin.py, because the removable drive
can have different drive letters, so I can't hard code it.

thanks again,
CJL

 

[Uwe Hoffmann]

Only because the Windows filesystem implements case-insensitive
semantics. This is nothing to do with Python:

no, i mean't the name not the content. Is the handling of the
env variable pythonpath case insensitive: pythonpath <--> PYTHONPATH.

regards
uwe

 

[Steve Holden]

no, i mean't the name not the content. Is the handling of the
env variable pythonpath case insensitive: pythonpath <--> PYTHONPATH.

You live and learn. Apparently it is:

C:\Steve\Projects\Python\dbimp>set SCREWUP="This is Windows"

C:\Steve\Projects\Python\dbimp>python
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
Started with C:/Steve/.pythonrc

>>> import os; print os.environ["screwup"] "This is Windows"
>>>

It turns out that there's code in os.py specifically for os2 and NT
systems, wherein a subclass of userDict is declared that used
case-insensitive pattern matching:

regards
Steve

 

[Thorsten Kampe]

* cjl (2006-09-11 20:34 +0100)

Is the source of the windows python installer available? I guess I
could see what registry keys they are setting...

Simply installing Python would be about one hundred times faster...

I do set pythonpath, see above.

Any other ideas?

Use Cywin Python.

 

[Thorsten Kampe]

* Steve Holden (2006-09-11 21:37 +0100)

Only because the Windows filesystem implements case-insensitive
semantics. This is nothing to do with Python:

That's nonsense: "Filenames are Case Sensitive on NTFS Volumes"[1]

Thorsten
[1] http://support.microsoft.com/kb/100625/en-us

 

[Steve Holden]

* Steve Holden (2006-09-11 21:37 +0100)

Only because the Windows filesystem implements case-insensitive
semantics. This is nothing to do with Python:

That's nonsense: "Filenames are Case Sensitive on NTFS Volumes"[1]

Thorsten
[1] http://support.microsoft.com/kb/100625/en-us

Sigh. Right, the semantics are actually inside the subsystem accessing
the filesystem, if I have to dot every I and cross every T. Note that
the reference you quote includes the test """However, if you attempt to
open one of these files in a Win32 application, such as Notepad, you
would only have access to one of the files, regardless of the case of
the filename you type in the Open File dialog box."""

So perhaps I should have said the Win32 API implements case-insensitive
semantics? Sure, if you want to use the POSIX compatibility layer it's
absolutely possible to create several files that Win32 applications will
be completely unable to distinguish between. Whatever good that might do
you.

Sheesh, the nits that get picked on this list nowadays. I can remember
when it used to be fun, not an exercise in ego inflation.

regards
Steve

 

[Thorsten Kampe]

* Steve Holden (2006-09-12 01:30 +0100)

* Steve Holden (2006-09-11 21:37 +0100)

Uwe Hoffmann wrote:
cjl schrieb:

I do set pythonpath, see above.

is pythonpath really case insensitive on windows ?

Only because the Windows filesystem implements case-insensitive
semantics. This is nothing to do with Python:

That's nonsense: "Filenames are Case Sensitive on NTFS Volumes"[1]

Thorsten
[1] http://support.microsoft.com/kb/100625/en-us

Sigh. Right, the semantics are actually inside the subsystem accessing
the filesystem, if I have to dot every I and cross every T. Note that
the reference you quote includes the test """However, if you attempt to
open one of these files in a Win32 application, such as Notepad, you
would only have access to one of the files, regardless of the case of
the filename you type in the Open File dialog box."""

So perhaps I should have said the Win32 API implements case-insensitive
semantics? Sure, if you want to use the POSIX compatibility layer it's
absolutely possible to create several files that Win32 applications will
be completely unable to distinguish between. Whatever good that might do
you.

Sheesh, the nits that get picked on this list nowadays. I can remember
when it used to be fun, not an exercise in ego inflation.

It's exactly the same issue as with the environment variables: "You
live and learn."[1]

Thorsten
[1] http://groups.google.com/group/comp.lang.python/msg/249fa3ce96e757b3

 

[cjl]

Hey all:

I'm getting closer. My startpython.bat file is now:

path=%PATH%;%CD%Python24;%CD%Python24\libs;%CD%Python24\Scripts;%CD%Python24\Lib\site-packages;%CD%Python24\DLLs
set PYTHONPATH=%CD%Python24
ASSOC .py=Python.File
ASSOC .pyc=Python.CompiledFile
ASSOC .pyo=Python.CompiledFile
ASSOC .pyw=Python.NoConFile
FTYPE Python.File=%CD%Python24\python.exe "%1" %*
FTYPE Python.CompiledFile=%CD%Python24\python.exe "%1" %*
FTYPE Python.NoConFile=%CD%Python24\pythonw.exe "%1" %*
set PATHTEXT=%PATHTEXT%;.py;.pyc;.pyo;.pyw
cmd

I am having a problem with the ftype commands as written above. If I
type them from the command line exactly like above they work. But for
some reason they do not work from my batch file. Anyone familiar with
bath file syntax that can help me? I am very close here...

Thanks again,
CJL

 

[cjl]

Hey all:

It seems no matter what I do the %1 gets replaced by paramaters sent to
the batch file...there must be some way of "escaping" this, but I can't
find the answer (yet) with google. Anyone?

-CJL

 

[Jason]

Hey all:

It seems no matter what I do the %1 gets replaced by paramaters sent to
the batch file...there must be some way of "escaping" this, but I can't
find the answer (yet) with google. Anyone?

-CJL

Use two percents in a row turn into a single percentage sign. So you'd
want "%%1".

--Jason

 

[cjl]

Jason:

Thanks! That worked...in fact, almost everything is now working as
expected (so far).

Here is my batch file:

echo "Making changes to path and file associations..."
path =
%PATH%;%CD%Python24;%CD%Python24\libs;%CD%Python24\Scripts;%CD%Python24\Lib\site-packages;%CD%Python24\DLLs
set PYTHONPATH=%CD%Python24
ASSOC .py=Python.File
ASSOC .pyc=Python.CompiledFile
ASSOC .pyo=Python.CompiledFile
ASSOC .pyw=Python.NoConFile
FTYPE Python.File=%CD%Python24\python.exe "%%1" %%*
FTYPE Python.CompiledFile=%CD%Python24\python.exe "%%1" %%*
FTYPE Python.NoConFile=%CD%Python24\pythonw.exe "%%1" %%*
set PATHTEXT=.py;%PATHTEXT%
CMD

I'm still having a problem with setting PATHTEXT...I should be able to
now type django-admin at the cmd prompt and have it work, but I need to
still type django-admin.py ... I'm not sure what's wrong with my
setting of pathtext.

Any ideas?

Thanks again,
CJL

 

[Thorsten Kampe]

* cjl (2006-09-12 13:10 +0100)

Jason:

Thanks! That worked...in fact, almost everything is now working as
expected (so far).

Here is my batch file:

echo "Making changes to path and file associations..."
path =
%PATH%;%CD%Python24;%CD%Python24\libs;%CD%Python24\Scripts;%CD%Python24\Lib\site-packages;%CD%Python24\DLLs
set PYTHONPATH=%CD%Python24
ASSOC .py=Python.File
ASSOC .pyc=Python.CompiledFile
ASSOC .pyo=Python.CompiledFile
ASSOC .pyw=Python.NoConFile
FTYPE Python.File=%CD%Python24\python.exe "%%1" %%*
FTYPE Python.CompiledFile=%CD%Python24\python.exe "%%1" %%*
FTYPE Python.NoConFile=%CD%Python24\pythonw.exe "%%1" %%*
set PATHTEXT=.py;%PATHTEXT%
CMD

I'm still having a problem with setting PATHTEXT...I should be able to
now type django-admin at the cmd prompt and have it work, but I need to
still type django-admin.py ... I'm not sure what's wrong with my
setting of pathtext.

Setting environment variables has only effect on the process itself
and the subprocesses. This has nothing to do with Windows, it's the
same with Linux.

 

[cjl]

Thorsten:

Thank you for your reply.

Setting environment variables has only effect on the process itself
and the subprocesses. This has nothing to do with Windows, it's the
same with Linux.

True, and the changes to path and pythonpath are gone after I close the
console window, but the results of the assoc and ftype commands are
changes to the registry that linger. If I run my setup on a computer
that has python installed, I will overwrite the pre-existing registry
settings. I can restore them with a script, but I can't guarantee that
my restore script will run.

I'm still looking for a way to modify these temporarily, but it looks
like I might be "up the creek" on this one. Oh well.

Thanks again,
CJL

 

[Jason]

Thorsten:

Thank you for your reply.


True, and the changes to path and pythonpath are gone after I close the
console window, but the results of the assoc and ftype commands are
changes to the registry that linger. If I run my setup on a computer
that has python installed, I will overwrite the pre-existing registry
settings. I can restore them with a script, but I can't guarantee that
my restore script will run.

I'm still looking for a way to modify these temporarily, but it looks
like I might be "up the creek" on this one. Oh well.

Thanks again,
CJL

I notice that you've already got the environmental variables set up to
run your Temp-Python. You can retrieve the current associations (if
any) by using the assoc and ftype commands:

C:\>assoc .py
..py=Python.File

C:\>ftype Python.File
Python.File="C:\Python24\python.exe" "%1" %*

C:\>assoc .NotAnExtension
File association not found for extension .NotAnExtension

C:\>

Using this information, you could write a little python script with
your distribution which records the current file associations and
settings. Then, when you're ready to revert, you run another little
python script which restores the associations.

These associations are also stored in the registry. You could back up
the registry keys which you know will be modified, make the registry
changes yourself, and restore the registry settings at finish. It
would require Python's win32 extension modules, though.

I don't know how you could do it without using a
backup/run-stuff/restore sequence.

--Jason