RFC: Rename to `conda-pypi`?

[jaimergp]

I'm not sure conda-pip is the right name for the project and package. We are implementing tool agnostic behavior with EXTERNALLY-MANAGED and while we do have the conda pip subcommand, chances are we will also have conda uv in the future (or similar). Hence I think conda-pypi might be a better name for the project, which happens to implement the pip subcommand for now.

Thoughts? This a simple change to do now but it might get a bit more complicated later when things are packaged and folks start adding this to requirements, etc.

[jezdez]

I would rather call it conda-python since PyPI is the hosting service, not the purpose of the plugin.

[jaimergp]

I always struggled to find a correct term that encompasses "Python packages distributed through PyPI and similar services, either as wheels or sdists". It does provide a plugin to fetch packages from PyPI. pixi has pypi-dependencies, too.

conda-python is too broad imo, maybe conda-python-packaging, but it might convey they wrong meaning, as in "use this to package your Python projects".

Naming is hard 😭

[dharhas]

conda-python is too broad imo

agreed. for better or for worse, conda-pypi is the most descriptive, least confusing name.

Other ideas conda-interop, conda-compat, conda-resolve or something completely unrelated i.e chimera

[jaimergp]

conda-pypi-compat?

[jaimergp]

One more argument / precedent for pypi:

• It has been used as a "channel" identifier in the conda ecosystem.

[jezdez]

You've changed my mind, conda-pypi is the better term, as it goes well with the idea of making conda aware of additional 3rd party packaging ecosystem (independent of its own). This would bode well for supporting others long-term (e.g. R, npm, etc)