I am trying to be helpful about PYTHONPATH, but I don't understand the question very well. This is a complete guess. Ignore as convenient. It looks to me like Paul wants App1 and App2 to be a root starting-point directories on (or in) the PYTHONPATH and to have another root directory in PYTHONPATH for common stuff, i.e. a library.  I think maybe others are recommending that the parent to all those directories be the directory on the root path. Not sure. Not going to go parse the mail either. If I'm way off, just stop reading. :) If you want the apps to be able to live anywhere with ignorance of each other, then you don't want to use the common parent directory for the PYTHONPATH reference directory? This code snippet might be useful to think about PYTHONPATH management. import logging, os.path, sys # Build paths inside the project like this: os.path.join(BASE_DIR, ...) BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) # Add project library home for project use. PARENT_DIR = os.path.dirname(BASE_DIR) LIB_HOME = os.path.join(PARENT_DIR, 'lib') sys.path.append(os.path.abspath(LIB_HOME)) # Now safe to do this, but this is not the only reason for LIB_HOME append: from dmorris.utils.logging import ExceptionFormatter If you want to check for a directory already in PYTHONPATH, you can test with: if LIB_HOME not in sys.path:   sys.path.append( whatever ) And if you are done with a variable, you can remove it, e.g. 'del LIB_HOME'. The lib home will either be located relatively (as above) or absolutely, which is easier to code. It's been a year since I programmed in Python. I'm rusty. I don't think I ever used __init__.py, which I think is the old way. There was a chapter, guessing chapter 24, in Mark Lutz, Learning Python, 5th Edition. May or may not be dated to irrelevance. It was old when I borrowed it from the library, but it had aged well. I think this was it: Learning Python, 5th Edition | | | | | | | | | | | Learning Python, 5th Edition Get a comprehensive, in-depth introduction to the core Python language with this hands-on book. Based on author ... | | | The man is painfully thorough. You will know everything you ever wanted to know about PYTHONPATH if you read that part. If not at your public library, there's always interlibrary loan (in the US). There's always the official python documentation at 3.8.1rc1 Documentation | | | | 3.8.1rc1 Documentation | | | Dang yahoo replaces by urls. I'm sure there's more documentation out there. Hope this was useful. Pretty inexpensive if not. Good luck! Douglas Morris On Saturday, December 14, 2019, 2:41:07 PM EST, Paul Marlin <wurfsendungen(a)biketrain.net> wrote: On 12/13/19 3:02 PM, Matthew Brush wrote: I'm not sure exactly what you're going for, but often you will have your main script in the top level, and then put common/library code in a package directory, with an (often empty) `__init__.py` file. Something like this:   - py     - main.py     - common       - __init__.py       - fun.py If you lay it out like this, it "Just Works" out of the box with Geany's execute command for `main.py`, without messing with any path variables or anything. If you want to leave it where `main.py` is in a directory that is a sibling of your common/library package, you will probably have to mess with paths and/or use some kind of relative imports. I don't think your problem is with Geany as much as with trying to understand Python's quite complicated import mechanisms/rules/conventions.      Amen Hope that helps. Regards, Matthew Brush ============================================ What I'm looking for is a way to structure multiple python applications that all make use of user defined functions (VFP jargon perhaps) stored in a python script (this is how I did it with multiple PHP apps). I followed your suggestion and took the liberty of adding a second script, main1.py.  Both worked even without __init__.py. - py     - main.py     - main1.py    - common        - fun.py  But my problem is that main.py and main1.py really represent separate applications each with multiple files.  The only way I know of organizing apps is to  place their files in their own directory.  So I tried - py     - app1         - main1.py     - app2         - main2.py     - common         - fun.py Even though this seems to be the same structure as I started with, both main1.py and main2.py worked.  So it appears Geany is now accepting /home/paul/py as being in the PYTHONPATH.  Since common is downstream of that, it works. Thank you. PS: I'm sure this belongs in a separate thread; but I got cocky and tried an alarm clock program that I had written involving a tkinter GUI.  It worked fine in Idle; but all I got from Geany was a terminal window telling me the exit code was 0.  Using the ancient dicotomy of system vs. applcation programing, wouldn't it be fair to say all application programs are GUI? Paul _______________________________________________ Users mailing list Users(a)lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users(a)lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users

the main loop of a GUI tries to act like an internet browser: disguise as OS and do as you like; it's actually the bottom line of 'social networks' (or even wider, humans simply act like that: finding out without leaving the cover); I just wonder how long they can sell there 'data analysis' (AI, there selling label, is older than anyone's live on this planet but still working fine); don't fight, be amused.. have a nice day -----Original Message----- From: Paul Marlin Sent: Saturday, December 14, 2019 11:55 PM To: users(a)lists.geany.org Subject: Re: [Geany-Users] Can't import local module. Need mainloop() On 12/14/19 2:40 PM, Paul Marlin wrote: PS: I'm sure this belongs in a separate thread; but I got cocky and tried an alarm clock program that I had written involving a tkinter GUI. It worked fine in Idle; but all I got from Geany was a terminal window telling me the exit code was 0. Using the ancient dicotomy of system vs. applcation programing, wouldn't it be fair to say all application programs are GUI? ================================================================== Please ignore this. Idle displays the GUI without the mainloop() function. When I added it, Geany displays the GUI as well. _______________________________________________ Users mailing list Users(a)lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users

an whilst you are at it set up a virtual environment (venv) to keep the versions nicely apart (batteries are included); in Geany, each environment corresponds to a particular project (with its respective settings).. -----Original Message----- From: Lex Trotman Sent: Friday, December 13, 2019 10:22 PM To: Geany general discussion list Subject: Re: [Geany-Users] Can't import local module How are you starting Geany? Its possible you are starting it in a way that PYTHONPATH is not set. Perhaps test it by running a small Python program with Geany to print sys.path. Cheers Lex On Sat, 14 Dec 2019 at 02:54, paul Marlin <wurfsendungen(a)biketrain.net> wrote: _______________________________________________ Users mailing list Users(a)lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users

On Sun, 15 Dec 2019 at 00:36, Paul Marlin <wurfsendungen(a)biketrain.net> wrote: I suspected so, (most) desktops start the application directly without running a shell. But the shell is the thing that reads your .bashrc or .profile or wherever you set PYTHONPATH. So without the shell being run first, geany is started with an environment that does not include PYTHONPATH. You can confirm this by starting Geany from the terminal not the menu. The likely solution is to make the menu run a shell script that runs geany, and maybe thats how idle is launched. Also some desktop menu editors have an option to run the command in a shell built in, I'm not a Ubuntist so I don't know what it has, probably check first and make a start script if needed. Cheers Lex