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

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


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@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@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/users