regarding the future

[harelwa]

Hi,

I wanted to ask if you really plan on implementing -

Install available packages from conda + conda-forge before using pip.

And ! I wanted to ask how ?

Specifically, how you though to address

• conda version spec is different than pypi's
• some packages are named differently in conda

I think this feature will be very useful !

especially for packages that are not pure python, or python at all.

Many thanks,
Harel

[OldGrumpyViking]

Hi, good question.
I think it depends on how hatch is going to handle locking dependencies.
Hatch builds on top of pip so adding conda as a repository in the mix will have to involve some special handling by this library.
I do not plan on looking into this until the locking is in place in hatch.

[maximlt]

https://github.com/conda/conda-lock is a great project that tackles locking conda environments. It alo supports locking conda+pip dependencies by using poetry's solver.

[jaimergp]

some packages are named differently in conda

We have a mapping of the known equivalents :D

[harelwa]

some packages are named differently in conda

We have a mapping of the known equivalents :D

I can't believe I was not aware of that. thanks! now it's also clear why grayskul works :)

[harelwa]

Hi, good question. I think it depends on how hatch is going to handle locking dependencies. Hatch builds on top of pip so adding conda as a repository in the mix will have to involve some special handling by this library. I do not plan on looking into this until the locking is in place in hatch.

@OldGrumpyViking -

I'm not sure I understand how you imagine hatch deps management related code will play along with mamba ( conda ) exactly because it relies on pip. If you can explain in more detail - please do.

As for lock, well, this is painful, also with regards to poetry as it's not PEP 665 compliant, where as hatch wants to be afaik. All that said, conda has its own long established lock schema, and it also provides "pypi" lock like @maximlt mentioned.

At least in my use case, I'll say that conda envs means conda env YAML, along with all it's features - e.g. at least channels specification and the ability to explicitly decide what comes from pip and what from conda. Either Way, I'm not sure abstracting env YAML into pyproject / hatch toml sections is a good idea.

Regardless, I think conda should be a first class citizen in hatch, as in practice, at least for py-data / ML usage of conda is too common to dismiss.

[dimazest]

I usually manually curate environment.ymlto include as much conda packages as possible and don't rely on pip to install only missing packages.