2

Of course, I doubt the ToD has anything to do with whether the package gets loaded or not, but it sure feels that way.

Please allow me to share a bit of background.

As part of my leveraging of the following GeeksforGeeks article:

https://www.geeksforgeeks.org/draw-control-flow-graph-using-pycfg-python/

I had to install pycfg.py. As shown in the GeeksforGeeks article, the file cfg.py has the following header:

from pycfg.pycfg import PyCFG, CFGNode, slurp
import argparse
import tkinter as tk
from PIL import ImageTk, Image

After PIP installing pyconfig, i still could not get this thing to run. (Note that I am running on Cygwin which is notorious for installation/path issues, and I was mucking with paths and installations quite a bit to try to get things going, so there is no telling what kind of messed up state I imposed on my Windows/Cygwin/Python environment.)

The guts of what I am trying to get working is the control flow graph that is so nicely enabled by the pycfg package.

Note that pycfg.py is installed here on Cygwin:

/usr/local/lib/python3.9/site-packages/pycfg

One dependency of pycfg is Graphviz, which is probably the trickiest part of running this thing on Cygwin. I'm not sure whether adding the path to the Windows environment, doing the pycfg install with PIP, doing the pycfg install with Cygwin, doing the Graphviz install any of various ways, modifying the Cygwin path, or some other modification of the environment or code was the "magic" that finally enabled the whole thing to work in Cygwin's XWindows. Internet searches, certainly offered many opinions about how to get things working in Cygwin, at least one of which involved rebuilding Graphviz from source. I think another might have suggested building CPython itself from source. I certainly did not want to go down that path this early in my Python "career", especially on Cygwin. Notwithstanding, I was willing to try just about anything to get these utopian control flow graph pictures!

OK, that is the background, now here is the weirdness. Everything was running great until I went boarding at Breckenridge the other week and subsequently returned home this week to run my "go" script, only to see the same issue with loading packages as before:

Traceback (most recent call last): File "/c/z/python/avaca/compiler/cfg/./cfg.py", line 1, in from pycfg import PyCFG, CFGNode, slurp ImportError: cannot import name 'PyCFG' from 'pycfg' (unknown location)

For some reason this seems to be the trigger:

from pycfg.pfcfg import PyCFG, CFGNode, slurp

vs

from pycfg import PyCFG, CFGNode, slurp

It appears based on whether I've been boarding or not, that one works or the other (or both). Note that the original was:

from pycfg.pycfg import PyCFG, CFGNode, slurp

The form, "pycfg.pycfg" is also working now.

I thought that it was weird from the get-go that they chose to use "from pycfg.pycfg" rather than "from pycfg", and lo and behold, it (originally) finally worked with:

from pycfg import PyCFG, CFGNode, slurp

Trying to understand this bizarreness, I switched it back to pycfg.pycfg, and it still worked. Then I switched it back to the more sensical (in my mind anyway), plain ole pycfg, and it continued working. That is, until I returned from Breck.

Ever since, I have been down a package/module implementation rabbit hole, and these efforts have been somewhat fruitless. I've watched several package related tutorials, and even peered a bit at the CPython source, but to no avail.

Now, there is a class called "PyCFG" in pycfg.py, but there is no reference to any lower case "pycfg" in the file.

Does anyone have any ideas about what might be causing this apparent ToD fiasco, or why and in what situations one might use "from pycfg.pycfg..." vs "from pycfg" to invoke a module or package?

Thanks!

user3761340
  • 603
  • 5
  • 19
  • Because this seems like a very localized problem, it's hard to give a definitive answer here. But my speculation would be that you might be dealing with module shadowing issues, where the name of a module in *your* codebase clashes with one in either the Python standard library, or pycfg. You say your main module is called `cfg.py`. That's an awfully generic name. I'd suggest renaming files in your code base to something truly unique (for now). After that, make sure to delete any *.pyc files with the old name, and `__pycache__` directories in your folder. – Lukas Graf Feb 17 '22 at 17:12
  • Thank you so much Lukas for your comment. Please note that ```cfg.py``` is not my module. I inherited it from the GeeksforGeeks module mentioned above. That being said, I will try renaming it to see if it has any effect. – user3761340 Feb 17 '22 at 17:18
  • I will also try your ```__pycache__``` and *.pyc files suggestions. – user3761340 Feb 17 '22 at 17:21
  • So pycfg does in fact have a `cfg.py` in [its own code](https://github.com/avacariu/pycfg/blob/master/src/pycfg/cfg.py). That would support my hypothesis that it could be a module shadowing issue. – Lukas Graf Feb 17 '22 at 17:32
  • That makes sense. Let me run some experiments to try to verify your hypothesis. – user3761340 Feb 17 '22 at 17:33
  • A tip about debugging this: Try starting just a plain `python` interpreter in your environment, and do `import pycfg`. After that, just type `pycfg`, to have Python print out a representation of the module it just imported. That should contain the path, and show you where it's finding it and loading it from. (You might also have *both* a pip installed package, and a "downloaded-and-dropped-file" version around, which could explain why both `from pycfg.pycfg ...` and the other variant seem to sometimes work). – Lukas Graf Feb 17 '22 at 17:37
  • That's great advice. I will try that immediately. – user3761340 Feb 17 '22 at 17:40
  • This is what I see from typing pycfg in the REPL: ```Vostro@DESKTOP-UGP94US /c/z/python/avaca/compiler/cfg $ p Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import pycfg >>> pycfg >>>``` – user3761340 Feb 17 '22 at 17:41
  • Also: For a pip-installed module, your working directory doesn't matter. But if you downloaded and dropped pycfg in a directory like `pycfg/pycfg.py`, then it *does* matter. If the `pycfg` folder is in your working directory, you would indeed need to do `from pycfg.pycfg import ...`. But if that `pycfg.py` is immediately inside your working dir, and not in a subfolder, `from pycfg import ...` would be correct. – Lukas Graf Feb 17 '22 at 17:42
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/242122/discussion-between-lukas-graf-and-user3761340). – Lukas Graf Feb 17 '22 at 17:44

0 Answers0