search

prospector-dev / prospector

Inspects Python source files and provides information about type and location of classes, methods etc
GNU General Public License v2.0
1.95k stars 171 forks source link

Prospector 1.10.2 does not support `with_mypy` optional tool [in conda] #624

Open valeriupredoi opened 1 year ago

valeriupredoi commented 1 year ago

Hi @carlio long time no see (on GH), hope you doing good, mate! I ran into this little nugget just now:

(tool-latest2) valeriu@valeriu-PORTEGE-Z30-C:~/ESMValCore$ prospector esmvalcore/preprocessor/_area.py 

Cannot run tool mypy as support was not installed.
Please install by running 'pip install prospector[with_mypy]'

(tool-latest2) valeriu@valeriu-PORTEGE-Z30-C:~/ESMValCore$ pip install prospector[with_mypy]
Requirement already satisfied: prospector[with_mypy] in /home/valeriu/miniconda3/envs/tool-latest2/lib/python3.10/site-packages (1.10.2)
WARNING: prospector 1.10.2 does not provide the extra 'with_mypy'

It seems that with_mypy is not playing well with the latest prospector for some reason. I checked the package on conda-feedstock (I had previously approved the upgrade version PR from the bot, a few weeks ago) and the package specs are alright wrt mypy, but there's some oddity in poetry perhaps? Cheers, let me know if I can help :beer:

carlio commented 1 year ago

Try using with-mypy instead? There's an annoying thing to do with different versions of poetry packaging which makes it change whether optional dependencies use - or _

(See similar issues like https://github.com/landscapeio/prospector/issues/618)

Honestly I think it's a bit irritating and I might move away from poetry for packaging, or rename optional extras or something.

carlio commented 1 year ago

(Also the conda packaging is not something I am familiar with so I have no idea what black magic might go on there too.)

valeriupredoi commented 1 year ago

Blast! It works well with with-mypy - cheers! I can give you a hand migrate from poetry to a conda-based environment and package if you would want to, no problem. It is indeed not optimal to have extension names vary depending on what version the package manager decides to be on :grin:

carlio commented 1 year ago

I think it'd be good to get around to having "first-party" support for conda packaging as there are often conda-related bugs which turn out to be due to someone else packaging it in a way I don't understand or know about!

valeriupredoi commented 1 year ago

a migration to a conda-forge/Mambaforge environment file to hold all the dependencies, see eg one here - that may allow for PyPI-only packages (even if it's not optimal, and we'd have to nudge those maintainers to package their packages for conda-forge) would prob do better for you IMO - Of course there are issues with dependencies on conda-forge being improperly built at times, but most of these are detected early (by others too), so are easily fixable. Plus, this way it's really easy to have Github Actions tests that run env building and installation of your package and test the different modules etc