[Idle-dev] Re: Startup

[Kurt B. Kaiser]

Tony Lownds <tony@lownds.com> writes:

> >This failed to start the subprocess because the subprocess Python
> >can't see run() since it's not on the path (when you don't start in
> >Tools/idlefork).
> >
> >If I change PyShell.ModifiedInterpreter.build_subprocess_args() to say
> >
> >    + ["-c", "__import__('idlelib.run').main()", str(self.port)]
> >
> >then we can't startup in Tools/idlefork  via python2 idle.py,
> 
> I think the second element should be: "__import__('idlelib.run').run.main()"
> 
> """
> __import__(name, globals, locals, fromlist) -> module
> 
> [...]
> When importing a module from a package, note that __import__('A.B', ...)
> returns package A when fromlist is empty, but its submodule B when
> fromlist is not empty.
> """
> 
> Perhaps it would be cleaner to arrange for idlelib to be a package
> while developing (in Tools/idlefork  via python2 idle.py) than have
> the idle codebase
> work in two different modes.

How do you do that?

To get back to basics,  the standard way of running IDLE is to start Python
and somehow pass it a script which causes it to import PyShell and then
run PyShell.main().

In the case of the subprocess, start Python and cause it to import run
and then execute run.main().

To do this, Python has to be able to find PyShell.py and run.py
somewhere on sys.path.  That's no problem if you are working in the
IDLE source directory, but once IDLE is installed you could be
anywhere in the file system.  The system path finds Python and
sys.path finds IDLE.  The key to this is site-packages.  Note that
...Tools/... is never on sys.path unless explicitly inserted by
starting a script in, say, ...Tools/idle/ .  

For example, if I start in / on Linux, then the subprocess sees:
** cwd:  /
** sys.path:  ['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2',
 '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', 
'/usr/lib/python2.2/site-packages', 
'/usr/lib/python2.2/site-packages/idleforklib']

The user process is the same except it also has /usr/bin on the path
(that's the location of the idlefork script.)

The only way _Python_ can find PyShell or run is via site-packages or
possibly in the directory of /an/ IDLE script, as with Windows icons
targeted at ..../Tools/idle/idle.pyw

Idlelib is an install time entity.  It doesn't exist until IDLE has
been installed.

Executing out of the source tree(i.e. Tools/idle), as is still done on
Windows (at least in 2.2) in spite of the recent addition of
site-packages to the Windows directory structure, is IMHO a bit of a
kludge.

Currently I've got IDLEfork installed with an idlefork.pth and
idleforklib directory in site-packages.  This works well with Linux
RPMs and the Windows Installer, once you discover the stealth
distutils option "extra_path".  The IDLEfork installation doesn't appear
to conflict with Python IDLE, and the subprocess etc. is running ok on
both (with and without the .pyw start :).

However, I'm not wedded to this.  You point out that the .pth approach
is not the best way for the Mac.  It is possible to set up IDLE as a
package and I suspect I can figure out a way to start the subprocess
when idlelib doesn't (yet) exist: probably something in run.run() like
try: __import__ idlelib.run except: __import__ run and something
similar in idle.py so IDLE will work from the source tree before it's
installed.  Slightly kludgey but no one's going to turn into a pillar
of salt.  .pth files are kludges, too.

I think I'll check in what I've got so I don't lose it, and then
experiment a bit more with this. 

What do you guys think?  I'm ready for alpha on Linux and Windows.

Moving this discussion out to idle-dev.

Regards, KBK