This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: bundlebuilder: easily keep main routine in orig location
Type: enhancement Stage:
Components: macOS Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: bob.ippolito, reowen, ronaldoussoren
Priority: normal Keywords:

Created on 2004-02-19 18:44 by reowen, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg61161 - (view) Author: Russell Owen (reowen) Date: 2004-02-19 18:44
I'd like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app's main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn't sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder's assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.
msg61162 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-26 02:39
Logged In: YES 
user_id=139309

This doesn't *really* make sense.. is it too hard to have a bootstrap 
script that imports and executes this?  Isn't that what you would have on 
other platforms?
msg61163 - (view) Author: Russell Owen (reowen) Date: 2004-02-26 17:33
Logged In: YES 
user_id=431773

I'm afraid I don't follow your reply. My point was that bundlebuilder could always write some kind of executable whose job was to import and execute the user's main .py script.

This has several advantages:
- The user's main code gets compiled; presumably this makes it run faster
- The user's main code never has to be moved

I suspect the bundlebuilder option "executable" may even have been designed for this task, but I've not yet figured out how to use it; I did try it a bit, but bb still required a "mainprogram" so I realized I hadn't a clue what I was doing and gave up on it.
msg61164 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-26 17:43
Logged In: YES 
user_id=139309

I don't agree with either of your advantages.
- bundlebuilder could compile the "main code" as-is, it just doesn't
- never has to be moved, in exchange for importing foo.bar as 
__main__?  No thanks.

"executable" is for something else.  "mainprogram" is exactly what it 
says it is, it's a program, not a module-inside-a-package-that-should-be-
imported-as-__main__.  Perhaps there could be a 
"writemeamainprogram" argument where you would specify something 
like "foo.bar:main" where foo.bar is the module and main is the 
function.. but then how would you decide which idiom it should be called 
with (sys.argv[1:], sys.argv, no arguments, etc.).

It's not hard to make a two-line program that does what you need it to 
and use that as the mainprogram.. I think this use case is just too 
specific to the style of your single application.  I *always* see the 
separate-main-program idiom used that imports something and calls 
some function, I have *never* seen people symlink something in /usr/
local/bin to something in site-packages.
msg61165 - (view) Author: Russell Owen (reowen) Date: 2004-02-26 18:03
Logged In: YES 
user_id=431773

I think this discussion is getting off track.

It is certainly reasonable (or at least I hope it is) to write
TUI/
  Main.py
and expect unix users to execute Main.py, for example:
alias tui <tui_root>/TUI/Main.py

The problem comes when bundlebuilder helpfully pulls Main.py out of TUI and puts up up at the main level. It seems an odd arrangement of files to me -- I'd much rather stuff all my app's files into a directory and make that a package (to reduce the danger of namespace collisions).

I really don't see the importing issue coming up here. I was hoping bundlebuilder would simply execute the file TUI/Main.py without moving it. It doesn't need to import anything, it just needs to execute the file.

Anyway, I do agree it's not that hard to work around. It just seems a shame that bundlebuilder moves files around without being asked. Once one realizes what is going on, one can figure out workarounds -- such as making the main file movable or writing a stupid 2-line extra script to call the main file.
msg61166 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-26 18:11
Logged In: YES 
user_id=139309

The problem is that it doesn't know that the path TUI is important when 
you give it a mainprogram; mainprogram can be any path.  When it does 
modulefinder on your mainprogram, it sees it as __main__, not as 
TUI.Main, as it should.

If you follow the standard unix way of doing scripts, which is writing a 
script "tui" that imports TUI.Main and calls whatever needs to be called, 
then everything will work just fine.  That's what mainprogram is.
msg78814 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-01-02 15:10
I agree with Bob's last response. Futhermore bundlebuilder is deprecated, 
use py2app instead.
History
Date User Action Args
2022-04-11 14:56:02adminsetgithub: 39953
2009-01-02 15:10:19ronaldoussorensetstatus: open -> closed
resolution: wont fix
messages: + msg78814
nosy: + ronaldoussoren
2004-02-19 18:44:15reowencreate