bundlebuilder: easily keep main routine in orig location

[e9d15def-f70a-44ca-b367-05ca61ceb40a]

BPO	900514
Nosy	@etrepum, @ronaldoussoren

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['OS-mac', 'type-feature'] title = 'bundlebuilder: easily keep main routine in orig location' updated_at = user = 'https://bugs.python.org/reowen' ``` bugs.python.org fields: ```python activity = actor = 'ronaldoussoren' assignee = 'none' closed = True closed_date = closer = 'ronaldoussoren' components = ['macOS'] creation = creator = 'reowen' dependencies = [] files = [] hgrepos = [] issue_num = 900514 keywords = [] message_count = 7.0 messages = ['61161', '61162', '61163', '61164', '61165', '61166', '78814'] nosy_count = 3.0 nosy_names = ['reowen', 'bob.ippolito', 'ronaldoussoren'] pr_nums = [] priority = 'normal' resolution = 'wont fix' stage = None status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue900514' versions = [] ```

[e9d15def-f70a-44ca-b367-05ca61ceb40a]

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.

[8bb2fe13-d245-4fef-8aa2-70d7108db3c3]

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?

[e9d15def-f70a-44ca-b367-05ca61ceb40a]

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.

[8bb2fe13-d245-4fef-8aa2-70d7108db3c3]

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.

[e9d15def-f70a-44ca-b367-05ca61ceb40a]

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.

[8bb2fe13-d245-4fef-8aa2-70d7108db3c3]

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.

[ronaldoussoren]

I agree with Bob's last response. Futhermore bundlebuilder is deprecated, use py2app instead.