dieter wrote: > ant <a...@anthive.com> writes: >> ... >> in order to get this far below i had to edit each >> file and put a try: except: around each import >> statment checking if the module could be found >> like (as an example): >> >> try: >> import config as cfg >> except: >> import frog.config as cfg > > Is "frog" the package, you want to install? > Then always use "import frog.config ...".
frog is my temporary adaptation of my project to test out how to do this without actually making all those changes until i'm sure it is doing what i want. frog is a package as i understand it. here is the structure: ===== (env) me@ant(15)~/src/salsa/frog$ find . -print | grep -v ".git" | grep -v "__pycache__" | grep -v "dist" | grep -v "build" | sort . ./frog ./frog/active.py ./frog/background.py ./frog/board.py ./frog/commands.py ./frog/config.py ./frog/dialog.py ./frog/doc ./frog/doc/ngfp.6 ./frog.egg-info ./frog.egg-info/dependency_links.txt ./frog.egg-info/entry_points.txt ./frog.egg-info/PKG-INFO ./frog.egg-info/requires.txt ./frog.egg-info/SOURCES.txt ./frog.egg-info/top_level.txt ./frog/history.py ./frog/__init__.py ./frog/labels.py ./frog/__main__.py ./frog/marbles.py ./frog/my_init.py ./frog/ngfp.py ./frog/png ./frog/png/arrows ./frog/png/arrows/picDDownW.png ./frog/png/arrows/picDLeftW.png ...80 lines skipped... ./frog/png/misc/sink_inv.png ./frog/png/misc/sink_orig.png ./frog/randboard.py ./LICENSE ./LICENSE.GPL ./MANIFEST.in ./NOTICE ./README.md ./setup.cfg ./setup.py ===== > Python locates (top level) packages/modules via the so > called "Python path" (--> "sys.path"). When > you run a script, the "Python path" is extended by the > directory the script resides in -- thus a script typically > can import "local" packages/module (residing in its directory). > However, it is good practise to always access installed > packages via their "official package path" (which > in your case likely means "frog.config"). this is the first i'm hearing of a path being extended. why isn't that reflected when i print the current working directory when the program is running (in both cases the paths show identical)? this is also the first time i'm hearing of "official package path". there are likely the details i'm beating my head against... thank you. :) > When you develop a package, it may not yet be installed. > This might hinder you to import in the "official" way. correct. when i am testing/writing code i am in the source code directory above called frog which looks like: ===== -rw------- 1 me me 8962 Dec 21 00:20 active.py -rw------- 1 me me 6673 Dec 21 00:11 background.py -rw------- 1 me me 11796 Dec 21 00:10 board.py -rw------- 1 me me 217 Dec 20 23:16 commands.py -rw------- 1 me me 5987 Dec 21 00:12 config.py -rw------- 1 me me 34077 Dec 21 00:14 dialog.py drwx------ 2 me me 4096 Dec 18 09:26 doc -rw------- 1 me me 1943 Dec 21 00:15 history.py -rw------- 1 me me 310 Dec 20 23:39 __init__.py -rw------- 1 me me 1845 Dec 21 00:15 labels.py -rw------- 1 me me 140 Dec 20 22:39 __main__.py -rw------- 1 me me 23973 Dec 21 00:17 marbles.py -rw------- 1 me me 13534 Dec 21 00:34 my_init.py -rw------- 1 me me 10354 Dec 21 09:02 ngfp.py drwx------ 10 me me 4096 Dec 18 09:26 png -rw------- 1 me me 5514 Dec 21 00:18 randboard.py (env) me@ant(18)~/src/salsa/frog/frog$ ===== so to test the code i simply run it via $ python3 ngfp.py which works as i expect it. ===== > I work around this by using "setuptools" and its "setup" > function in my "setup.py". "setuptools" supports the > command "develop" (activated via "python setup.py develop") > which "installs" the package in a way that it refers to > the developped sources. This way, I can always > import in the "official" way and nevertheless all > my changes are effective immediately. i'm not sure how this works, but i will look into it. > Another approach would be to lay out your package in such > a way that it refects the installed structure and > for testing put your script in the directory containing > your top level packages (or extend "sys.path" with this directory). i think that is what i've always assumed that was how the code is installed is exactly as how i have it in my development directory as shown above. your hint here says that it probably isn't so... heh... thanks, these are things a newbie doesn't know, but someone experienced just considers common sense. for me coming from C code, packed and unpacked via tarballs and such exactly where i want them to go is the normal and it seems so strange to find things so hard to figure out. the other problem i have is that things are cached and need to be cleared out sometimes before changes are reflected. i've run into this multiple times and it's really yet another frustrating thing. i wish there was a way for me to tell python to never cache anything (while i am developing) anywhere (even during the setup.py dist/sdist/wheel stuff or installs via pip). is the following missing anything i don't know about? ===== $ rm -rf build/ dist frog/__pycache__/ $ python3 setup.py sdist bdist_wheel ===== thank you for the hints, i'll go read up on them more now... :) ant -- https://mail.python.org/mailman/listinfo/python-list
