ah, progress...

[ant]

dieter wrote:
> ant <ant at 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 at 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 at 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