Conda -> Venv for local development about enterprise_gateway HOT 4 CLOSED

I think these arguments make good sense Sam - thank you. We're essentially shortening the ramp for onboarding folks - good stuff. I'm +1.

from enterprise_gateway.

I'm using Mamba too, but I think there is value in "defaulting" to venv for the env make targets, reducing the additional "tooling" overhead for new people that may not know about conda/anaconda/mamba/etc. I'm not a python expert but my sense is this "pip install -e . should obtain requirements from pyproject.toml" is true, yes.

from enterprise_gateway.

Hi @bloomsa. I certainly don't have any affinity for a conda environment to do development in. That said, I don't think we should preclude devs from using either - which you not proposing either. IMO, the dev should be responsible for ensuring the env in which they are operating is correct, and that is why we removed the forced use of (conda) envs in our make targets. Yes, we left the ability to create, activate, and destroy (conda) envs, but no other targets perform those actions.

We do, however, recommend the use of conda within our docker images, primarily because a conda installation typically includes a data science stack, so it eases the burden. That said, most of our images derive from the jupyter docker stacks images, which already provide most of that heavy lifting.

I'm not sure a requirements.txt file is necessary since pip install -e . should obtain requirements from pyproject.toml. Is that a correct statement?

So, in the end, I don't really see an issue with changing the recommended dev env type from conda to venv. I will probably stick with mamba as my env "vendor".

I'm curious if @lresende or others have any opinions about this.

from enterprise_gateway.

I'll make the PR this weekend. thanks!

from enterprise_gateway.