"<module_name>" is not accessed Pylance warning when using Conda

[Ritesh313]

I'm getting "<module_name>"is not accessed warnings from Pylance in my python file while importing all the stdlib modules.
The warning description just says:
conda_env_location/lib/python3.9/<module_name>.py" is overriding the stdlib module "<module_name>"

I have my anaconda environment selected as my interpreter in VS code. I know it's just a warning and not interrupting my code, but I would just like to know if I have something setup wrong. Please let me know if I should provide some other information for this.

Modules which have this warning: datetime, random, typing, argparse
Platform: VS code
Environment: Conda
Python version: 3.9.7

Here's a screenshot of the warning:

[EricYoung37]

EDIT: Ignore this question. It's just a mental lapse. Sorry for that.

Having similar issue while I'm using a native Python interpreter (that is directly installed on my PC).

In my case, I have a module transaction_manager.py that contains class TransactionManager. However, even if I've imported the module and instantiate an object of the class in the module, Pylance complains that the module is not accessed and the class is not defined.

[rchiodo]

@EricYoung7 I believe the correct way to reference TransactionManager would be like so:

tm = transaction_manager.TransactionManager()

Otherwise, you're not using the module.

[EricYoung37]

Thanks for your response! Sorry for the dumb question. I haven't been using Python for a while and I guess I was thinking stupid last night as I was working late.

I was wondering the same thing. It seemed to make sense that I got access to everything in a module by just importing it without specifying it in front of the member of the module. However, I googled and then realized specification is indeeded necessary if from import is not being used. I find it reasonable since referencing two methods having the same name from different modules may be ambiguous without specificication of the module.

[rchiodo]

No worries, I had to look it up myself to be sure.

I believe this is why it behaves that way: I find it reasonable since referencing two methods having the same name from different modules may be ambiguous without specificication of the module.

[rchiodo]

@Ritesh313 it looks like your configuration thinks the site-packages folder is user code for some reason. We'd need to see your settings.json and the log as described here:
https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#filing-an-issue

[rchiodo]

It's this code here that checks if a folder should be skipped or not:
https://github.com/microsoft/pyright/blob/23942f31e902a82084960611e0db2051a86f999b/packages/pyright-internal/src/analyzer/service.ts#L1121C15-L1121C26

It might be a conda environment doesn't have a bin/activate folder.

[rchiodo]

Yeah that's it. I can repro if I open my conda env folder as the root of the workspace:

This is probably fixable on our end (detect this situation) but I don't think it's likely to be fixed any time soon. It's not a very common thing for people to have their conda environments exist in their workspace.

[Ritesh313]

There are indeed a lot of directories in the root folder:

I didn't understand what you mean by

Meaning so that the pt2 folder isn't listed in the workspace?

This is where pt2 is (along with other conda environments I have)

And I checked the pt2 folder. It doesn't have bin/activate folder.

Here's the .condarc file that I have in my home directory to make this (conda environment at a specific location) work:

channels:
  - conda-forge
  - bioconda
  - defaults
  - https://repo.anaconda.com/pkgs/main
  - https://repo.anaconda.com/pkgs/free
pkgs_dirs:
  - /blue/azare/riteshchowdhry/virt_envs_anaconda/pkgs/
auto_activate_base: false
anaconda_upload: false
env_prompt: ({name})
envs_dirs:
  - /blue/azare/riteshchowdhry/virt_envs_anaconda/

[rchiodo]

Yeah that's the root cause, your virtual env folder is in the workspace. So we treat it as user source because we can't tell that it's actually a virtual env directory.

You can workaround this a number of ways:

1. Don't add your virtual env folder under your workspace. Put it somewhere else. You can still set it as the interpreter in use, but then Pylance won't parse it.
2. Add an explicit python.analysis.exclude setting for that directory
3. Add a bin/activate script to the venv directories. It doesn't actually have to do anything.

[Ritesh313]

Thanks! I added that directory to python.analysis.exclude in VS code settings. Discussion on excluding paths in VS code #2581

[rchiodo]

Made an issue out of this:
#5191