I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I've found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It's a huge app; I've not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

Logged In: YES 
user_id=45365

Hmm. Let's first try and find out what else can be meant by "in use". It is 
probably either a filesystem-related thing or a process/framework-
related thing.

First: could you check both the console log file and the system log file 
(both with Utilities->Console) for any clues? Probably best to open both, 
then run the app, then try to delete it, and see whether anything shows 
up.

Next thing to try is good old unix "rm -r" on the app. Does that work or 
not?

If rm -r works then I think I would proceed by "rm -r"ing specific parts of 
the app, and see whether there's any part that, when removed, will 
make empty trash continue. 

Logged In: YES 
user_id=431773

First of all, after trying to empty the trash (and saying "Continue" when it complains that Python is in use), all that is left of the application bundle is:
Contents/Frameworks/Python.framework/Versions/2.3/Python

I opened the system.log and console.log and watched while I started and stopped the application and then deleted as much of it as I could. Absolutely nothing showed up in system.log. The console showed: "running sitecustomize.py" as usual on startup and then 0 (the digit zero) on quit. No messages during the partial emptying of trash.

Next I tried rm -R. It did empty the trash. I hope it doesn't cause any problems (nothing so far, but I just did it a minute ago).

Any other ideas? (Trying rm on a specific file seems sort of pointless because I think I already know which single file is tied up.)

Logged In: YES 
user_id=139309

I would like to see the output of "ls -l" and "otool -L" on that file..

This is a Python framework build built by yourself, correct?  If you are 
running --standalone w/ a "/System" Python then you are not really 
doing anything useful (or supported, etc.) in the first place.

Logged In: YES 
user_id=431773

% pwd
/Users/rowen/PythonRO/testbuild/TUI 0.84.app/Contents/Frameworks/Python.framework/Versions/2.3
% ls -l Python 
-rwxr-xr-x  1 rowen  staff  1088276 19 Feb 09:21 Python
% otool -L Python
Python:
        /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 16.0.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 496.0.0)

This data was taken on a fresh build that has not yet been run. If that makes any difference I can run the app and trash it, so only this file is left. But I'd rather not generate undeletable files unnecessarily. Anyway, I hope it helps.

This is NOT a Python built by myself. I'm using the standard Python framework that comes with Panther (in /System).

Yes it's not stunningly useful to build a fully standalone app with Panther. I originally did it because I naively thought it would run under Jaguar. I stumbled across the bug at that time and reported it.

I can still imagine uses for doing a full standalone build (if they'll be compatible with later versions of MacOS X). Mainly Python has not been 100% backwards compatible (it's been good but not perfect). I had a few changes to make before my app would run under Python 2.3. A fully standalone build would eliminate this issue.

Meanwhile, I use semi_standlone for my real releases. Partly because of this bug and partly because I'm not sure it's worth the extra app size to guard against future problems. At least for now the app is fully maintained. At some future date it could well become an issue.

Logged In: YES 
user_id=139309

The version of Python that comes with OS X 10.3 is **NOT** future or 
backwards compatible (even with --semi-standalone!).  There are a lot of 
reasons for this, but I do not wish to explain them.

10.4's /System Python will probably be **future** compatible (assuming 
10.5 includes the same major python version), but with --semi-
standalone and not --standalone.

If you want future compatibility right now you **must** use a non-Apple 
compiled Python with --standalone.

If you want backwards compatibility, you can't have it (by default).  

Technically, you can (in theory) set up an elaborate environment such 
that you can compile Python and any extensions you need from 10.3 that 
would work on 10.2, but this is *not the default* and to my knowledge 
*nobody has tried it*.  Currently, the best solution is to have access to a 
10.2 machine for compiling and bundling Python and its extensions.  I 
don't consider this backwards compatibility though, because in either 
case you area compiling/building against OS X 10.2, whether or not you 
happen to be running it at the time.

Surely this is not what you want to hear, but it is what it is.  Sometime in 
the future, hopefully I or someone else will get this elaborate cross-
compiling environment going and write up a tutorial.  As for me, I'm FAR 
more interested in fixing current and future problems than spinning my 
wheels catering to people who can't/won't upgrade.

Logged In: YES 
user_id=45365

I'm going to close this bug: (a) no progress was made for 4 months, (b) 
it's pretty esoteric and (c) doing standalone buildapplication on Panther is 
useless anyway.

Feel free to reopen if you don't agree, though...