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