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

[valeriupredoi]

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 🍺

[carlio]

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 #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]

(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]

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 😁

[carlio]

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]

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