top-level venv doesn't work

[vanschelven]

Describe the bug

When the virtualenv is the same as the project-dir, fawltydeps doesn't work

To Reproduce

When the venv is external, everything is fine:

klaas@pop-os:/tmp$ git clone [email protected]:simplejson/simplejson.git
Cloning into 'simplejson'...
[..]
klaas@pop-os:/tmp$ python -m venv externalvenv
klaas@pop-os:/tmp$ . externalvenv/bin/activate
(externalvenv) klaas@pop-os:/tmp$ pip install fawltydeps
Collecting fawltydeps
  Using cached fawltydeps-0.18.0-py3-none-any.whl (64 kB)
[..]
(externalvenv) klaas@pop-os:/tmp$ cd simplejson/
(externalvenv) klaas@pop-os:/tmp/simplejson$ fawltydeps 
[..]
WARNING:fawltydeps.limited_eval:Failed to parse assignment of 'cmdclass': Call(func=Name(id='dict', ctx=Load()), args=[], keywords=[keyword(arg='test', value=Name(id='TestCommand', ctx=Load()))]) from dict(test=TestCommand) @ setup.py:100

These imports appear to be undeclared dependencies:
- 'setuptools'

For a more verbose report re-run with the `--detailed` option.

Approach with "top level venv", however:

klaas@pop-os:/tmp/simplejson$ python -m venv .
klaas@pop-os:/tmp/simplejson$ . bin/activate
(simplejson) klaas@pop-os:/tmp/simplejson$ pip install fawltydeps
Collecting fawltydeps
  Using cached fawltydeps-0.18.0-py3-none-any.whl (64 kB)
[..]
(simplejson) klaas@pop-os:/tmp/simplejson$ fawltydeps 

No undeclared or unused dependencies detected.

Being explicit doesn't help:

(simplejson) klaas@pop-os:/tmp/simplejson$ fawltydeps --pyenv .

No undeclared or unused dependencies detected.

Expected behavior

I expect this to work equally well as when using a venv outside of the project-dir, or a deeply nested venv

Environment

• Linux (pop-os 22.04)
• Version of the code: FawltyDeps v0.18.0

[jherland]

Thanks for reporting! To be honest this is the first time I've seen top-level venv, and I was not aware that keeping your source tree "inside" a virtualenv, like this, was even an option.

I seem to remember that we have some code in FawltyDeps for automatically excluding the contents of virtualenvs when we search for code and dependency declarations. This is to avoid FawltyDeps analyzing and reporting problems with code that happened to be installed in a virtualenv, but that is not part of your project. I suspect that this check now regards your entire source tree as being "inside" a virtualenv and therefore excludes it...

Will look into this as time permits.

[vanschelven]

I have no idea how (un)canonical my approach is, it's a habit I've picked up a loooong time ago, and it has never bitten me before. Also, because venv does this (name-of-venv) thing with your prompt, it's actually quite a good match since it shows the name of the relevant project rather than (venv) in this approach.

Happy to hear more, though this is certainly not a blocker for me.