Opened 8 years ago

Last modified 7 years ago

#2381 defect new

Twisted CMD box doesn't always work (win32)

Reported by: teratorn Owned by: teratorn
Priority: normal Milestone:
Component: core Keywords: win32
Cc: moonfallen, teratorn Branch:
Author: Launchpad Bug:

Description

Consider a scenario such as:

Install Python2.4
Install Twisted for Python2.4
Install Python2.5

This is the way my machine is set up right now, and when I open a Twisted CMD.exe box and type 'trial' I get this:

C:\>trial
Traceback (most recent call last):
  File "C:\Python24\scripts\trial.py", line 23, in <module>
    from twisted.scripts.trial import run
ImportError: No module named twisted.scripts.trial

This is because Python2.5 is associated with .py files. The Twisted CMD box adds .py to PATHEXT in order to make .py files "executable". It also adds Python's scripts directory to your Path.

With that done it allows you to just type 'trial' and have it work. Unfortunately it will always use the system-default Python interpreter. In my case that is Python2.5, but I don't have Twisted for Python2.5 installed so it can't find the module.

It's not obvious to me how we can fix this. Obviously the user expectation is that when they click the Twisted CMD box link for Python2.4 that will give them commands that actually use Python2.4.

I have a few ideas, but I want to think about it some more and try a few things out first. Suggestions welcome.

Change History (5)

comment:1 Changed 8 years ago by moonfallen

  • Cc moonfallen added

Bleh, trac suckiness strikes again.. make sure to cc me, merely assigning to me doesn't send me an email.

This is indeed a problem. I think we could make it run "../python.exe" pretty easily though, don't you?

comment:2 Changed 8 years ago by teratorn

Yeah that's probably the easiest thing to do. The exec* functions work on Windows, so there you go. As a performance concern I think we should check if the currently running Python is the right one before exec'ing. sys.executable should be handy for that.

comment:3 Changed 8 years ago by teratorn

  • Owner changed from moonfallen to teratorn

Branching to win32Scripts-2381

comment:4 Changed 7 years ago by teratorn

  • Cc teratorn added

comment:5 Changed 7 years ago by teratorn

I've committed a change to bin/trial that uses execv() to spawn the right version of Python. I'm not actually proposing that this is a correct solution to the problem though.

exec* on Windows seems to spawn a new process, giving it a new PID and everything. The new process is also "disconnected" from the parent's console. This means that you get returned to the CMD prompt while the newly exec'ed process runs in the "background".

I'm not entirely sure what my chosen terminology, "disconnected" and "background", actually *mean* on win32, but there you go.

I can't think of any *obviously* correct solutions. I'm considering writing a tiny .exe wrapper that runs the correct script file with the correct version of the Python DLL. Python.exe is, after all, just a tiny front-end to the DLL. Should be fun.

Anyone else have a better idea?

Note: See TracTickets for help on using tickets.