Applet support is broken in two ways:
- there is no sys.argv emulation anymore, and applets always see the -psnXXXX argument when started from the finder.
- when an applet is started from the commandline it is non-functional (no window manager connection).

Also, the building of the Idle applet doesn't work due to name conflicts.

Logged In: YES 
user_id=45365

sys.argv emulation works again, and that's the main part of this bug. A note has been added to NEWS that starting from the finder is broken in 2.3a2.

Building of Idle I cannot test right now.

Logged In: YES 
user_id=45365

Just thinks he can fix the commandline problem with a Python script, so assigning to him. Will you please also update Misc/NEWS if you do?

Logged In: YES 
user_id=45365

Building the Idle applet has been fixed (Mac/OSX/Makefile rev 1.36).

So now the python-based applet main program is the only thing that needs to be done.

Logged In: YES 
user_id=92689

I have a fix ready, but as I wrote in private, this will cause sys.executable to be different (ie. it will be the same as CFBundleExecutable). This apparently breaks your stuff, as well as bundlebuilder itself if it is run from a bundle it created itself...

Logged In: YES 
user_id=45365

Idea: we solve this for 50% and document it for 50%.

The "solve" bit involves applets that have the sys.argv support. This code is generated anyway, so we generate one extra line that sets sys.executable. It can do so, because we know what we want to put in there (bundlebuilder has just created the symlink anyway).

The document bit means that we have to state somewhere that if you create an applet without sys.argv emulation you are responsible yourself for setting it correctly. We do this in the IDE, so if we clearly flag the code that does this we've alreadly done quite a bit of "documenting".

Logged In: YES 
user_id=92689

Here's a further idea: let the bootstrap script instead set an environment variable called PYTHONEXECUTABLE. The argv support code could use this to properly set sys.executable, and apps without the need for argv emulation (ie. any not-100% braindead GUI app) would also be able to get at the right value. Perhaps it's even better to _not_ set sys.executable in wrapper code, but change the client code to:

if "PYTHONEXECUTABLE" in os.environ:
    executable = os.environ["PYTHONEXECUTABLE"]
else:
    executable = sys.executable

That way the client code is guaranteed to work correctly independent of whether the argv wrapper was used.

Perhaps a less generic name should be chosen, eg. PYTHONBUNDLEEXECUTABLE.

Logged In: YES 
user_id=45365

Good idea, but I would suggest that we *do* set sys.executable. It may be used deep down in other modules. And as per Guido's dictum sys.executable is expected to point to a python interpreter.

As to the name of the environment variable, why not simply PYTHON?

Logged In: YES 
user_id=92689

But we can only set it if there's a wrapper, and that's not always the case. Unless we add code to the Python _core_ that sets sys.executable if the environment variable is set. I doubt that would be accepted.

Or would there at the C level be a different way to distinguish between argv[0] as set by execve() and the actual executable?

Name: I would like to avoid accidental breakage, so longer is better...

Logged In: YES 
user_id=92689

I've found a solution: site[customize].py, I have a patch ready:
bundlebuilder.py adds a sitecustomize.pyc to the bundle which sets sys.executable according to the PYTHONEXECUTABLE environment variable.
Standalone apps already have a custom site.py, so the sys.executable munging happens there. I'll just check it in I suppose...

Leaving this item open until Jack confirms everything works as it should.

Logged In: YES 
user_id=45365

Two remarks:
- I really disagree with the sitecustomize.pyc. It obscures any real sitecustomize.py that the python admin may have installed, leading to weird behaviour (scripts will see the real sitecustomize but applets not). I think we should really handle this only in the argv emulator, which is going to be used for all "dumb" applets, and let "smart" applets handle it themselves by adding the two-liner
if os.environ.has_key("PYTHONEXECUTABLE"):
    sys.executable = os.environ["PYTHONEXECUTABLE"]

- I don't like the #!/usr/bin/env construct, why not use simply the same Python that Contents/MacOS/Python links to? If that Python goes away the applet will stop working anyway, so I see no reason to let the applet depend on possibly two different Pythons.

Logged In: YES 
user_id=45365

Something that just struct me: by putting the full pathname to a known interpreter into the #! line we also regain 10.1 compatibility again!

Logged In: YES 
user_id=92689

#!: That's the worst idea ever, as you will not be able to move your app *at* *all*.

Instead of using env, using /usr/bin/python should be ok. I just used env in the hope it would still work when someone removes /usr/bin/python and replaces it with a Python in a different location. Hm, this is brittle also, so I suggest to just hard-code /usr/bin/python.

sitecustomize: hm, good point. Alternative: insert a hacked site.py (copy the original, add a couple of lines).

I really want to get sys.executable right, as the client code is likely not aware (or rather *shouldn't* be aware) of whether it's run with argvemulator or not. This would/should result in *all* client code using the os.environ idiom. Eg. I don't expect the IDE to use the argvemulator, yet it will create applets, hence needs sys.executable. I feel strongly this is an either/or case: either we *always* set sys.executable or we don't do it ever.

Logged In: YES 
user_id=92689

#!: I misread you, what you suggest would work for applets to be run on the local system, but not for standalone apps: these need to be able to run on vanilla 10.2 installs. Although I'm not entirely comfortable with depending on /usr/bin/python, removing it (without replacing it with a different version) is an extremely bad idea, just like you're not supposed to remove /usr/bin/perl, as it would break the maintainance cron jobs (and probably much else). I would be happier to just use a shell script as before, but the entire point of this exercise was to fix the fact that we can't do something equivalent to os.execve() in sh (ie. lie about argv[0]).

Logged In: YES 
user_id=92689

I think this issue is completely fixed in CVS:
- the bootstrap script is written in Python again, using os.execve(), so the commandline vs. Finder issue is gone
- sys.executable is correctly set in main.c by means of an environment variable passed by the bootstrap script.