Many issues with project requirements analysis -- Is there an expectation for overhaul or resolution?

There are many issues related to automatic detection of project requirements and virtual environment resources. I'm talking about things like false positive for "Package requirement X is not satisfied" which arise because of something naming mismatch between pip install name and package name, or which arise when multiple projects are open, or which arise for no reason at all. I've also seen false negatives where a package was NOT included in the package requirements/venv but was not flagged. There are issues where stdlib packages get flagged as not being included in project requirements. There are lots of issues with support for editable installs including issues finding the packages and not having compatibility with pep 660. There's also no documentation on what pycharm is actually doing to resolve references. For example, how does pycharm determine what project requirements are? Does it look at pyproject.toml? Does it look at requirements.txt? What if multiple are present? Finally, once Pycharm has a list of what it thinks are the project requirements, how does it determine if they are satisfied by the current virtual environment or not?


So the upshot is, Pycharm has some usability for project requirements analysis, but fighting through all this issues to make it work for common use cases makes it pretty much not worth it to count on Pycharm to do requirements analysis. That is, you'll spend so much time trying to get Pycharm to work that it won't be worth it, even if it's possible. Are there any plans to look at this bundle of issues holistically and figure out a robust solution to requirements analysis?

1 comment
Here's a list of known issues in our packaging subsystem that mention requirements:

If you see an issue that affects you negatively, please vote for it and feel free to leave a comment -- this would help in prioritizing the issue.

Please sign in to leave a comment.