How to help people migrating from pip to conda?

[brettcannon]

@pf_moore

In short, the “grow up story” from venv-based tools is weak, because you have nowhere to go without restarting.

Well, there are people working on that - but the original focus of this discussion was “drawing a line” to the scope of venv-based tools, which basically means putting an artificial limit on that work (artificial, because it’s based on a principle, rather than on a lack of people willing to do the work). And yet, you’re now saying that if we do that, we have to tell people that there’s no way to go other than restarting?

So let’s think about what gets in the way of people migrating from pip to conda? Off the top of my head, the one people would probably bump up against is:

1. Lack of shared standard around specifying dependencies
2. Missing packages (versions) between PyPI and conda-forge
3. Different deployment story

For 1. there are two solutions. One is someone comes up with a requirements.txt → environment.yml translator. The other is something like Structured, Exchangeable lock file format (requirements.txt 2.0?) where we agree to a file format that everyone can work with.

For 2., I think that’s up to conda to fill in the holes in their package offering.

For 3., that’s basically just the way it is as conda is a shift in how you want things managed for you.

So to me it seems like the next potential step in harmony would be to figure out how to come up with agreed-upon dependency declaration format that everyone can work from (and also add anything specific for their tooling such that it isn’t only a common-denominator thing).