Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conda -> Venv for local development #1294

Closed
bloomsa opened this issue May 4, 2023 · 4 comments
Closed

Conda -> Venv for local development #1294

bloomsa opened this issue May 4, 2023 · 4 comments

Comments

@bloomsa
Copy link
Contributor

bloomsa commented May 4, 2023

Problem

I'm wondering if there's any appetite for migrating from conda to venv for local development environment setup. I recently began the process in order to try tackling #1089 and I thought it might make more sense to use the Python endorsed virtual environment tool as long as we didn't need any specific conda features. It would reduce the barrier to entry for new contributions since more people might be familiar with setting up their virtual environments using that.

Proposed Solution

  • Rewrite requirements.yml -> requirements.txt
    • this could instead be left off in favor of pip install . which seems to be what jupyter_server and ipykernel suggest
  • update the Makefile env target to use venv rather than conda

Additional context

@kevin-bates
Copy link
Member

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.

@bloomsa
Copy link
Contributor Author

bloomsa commented May 5, 2023

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.

@kevin-bates
Copy link
Member

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

@bloomsa
Copy link
Contributor Author

bloomsa commented May 5, 2023

I'll make the PR this weekend. thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants