4 ms·

I just use Anaconda. It's basically the final word in monolithic Python distributions. For data science/numerical computation, all batteries included. It also

by wenc 7y ago

I just use Anaconda. It's basically the final word in monolithic Python distributions. For data science/numerical computation, all batteries included. It also has fast optimized linear algebra (MKL) plus extras like dask (paralellization), numba, out of the box. No fuss no muss. No need to fiddle with anything. Everything else is a "pip install" or "conda install" away. Virtual envs? Has it. Run different Python versions on the same machine via conda environments? Has it. Web dev with Django etc.? All there. Need to containerize? miniconda. The only downside? It's quite big and takes a while to install. But it's a one time cost.

westurner 7y ago
I also prefer conda for the same reasons. Precompiled MKL is really nice. Conda and conda-forge now build for aarch64. There are very few wheels for aarch64 on PyPI. Conda can install things like Qt (IPython-qt, spyder,) and NodeJS (JupyterLab extensions). If I want to switch python versions for a given condaenv (instead of just creating a new condaenv for a different CPython/PyPy version), I can just run e.g. `conda install -y python=3.7` and it'll reinstall everything in the depgraph that depended on the previous python version. I always just install miniconda instead of the whole anaconda distribution. I always create condaenvs (and avoid installing anything in the root condaenv) so that I can `conda-env export -f environment.yml` and clean that up. BinderHub ( https://mybinder.org/ https://mybinder.org/ ) creates docker containers from {git repos, Zenodo, FigShare,} and launches them in free cloud instances also running JupyterLab by building containers with repo2docker (with REES (Reproducible Execution Environment Specification)). This means that all I have to do is add an environment.yml to my git repo in order to get Binder support so that people can just click on the badge in the README to launch JupyterLab with all of the dependencies installed. REES supports a number of dependency specifications: requirements.txt, Pipfile.lock, environment.yml, aptSources, postBuild. With an environment.yml, I can install the necessary CPython/PyPy version and everything else. ... In my dotfiles, I have a setup_miniconda.sh script that installs miniconda into per-CPython-version CONDA_ROOT and then creates a CONDA_ENVS_PATH for the condaenvs. It may be overkill because I could just specify a different python version for all of the conda envs in one CONDA_ENVS_PATH, but it keeps things relatively organized and easily diffable: CONDA_ROOT="~/-wrk/-conda37" CONDA_ENVS_PATH="~/-wrk/-ce37" I run `_setup_conda 37; workon_conda|wec dotfiles` to work on the ~/-wrk/-ce37/dotfiles condaenv and set _WRD=~/-wrk/-ce37/dotfiles/src/dotfiles. Similarly, for virtualenvwrapper virtualenvs, I run `WORKON_HOME=~/-wrk/-ve37 workon|we dotfiles` to set all of the venv cdaliases; i.e. then _WRD="~/-wrk/-ve37/dotfiles/src/dotfiles" and I can just type `cdwrd|cdw` to cd to the working directory. (Some of the other cdaliases are: {cdwrk, cdve|cdce, cdvirtualenv|cdv, cdsrc|cds}. So far, I have implemented cdalias support for bash, IPython, and vim) One nice thing about defining _WRD is I can run `makew <tab>` and `gitw` to `cd $_WRD; make <tab>` and `git -C $_WRD` without having to change directory and then `cd -` to return to where I was. So, for development, I use a combination of virtualenvwrapper, pipsi, conda, and some shell scripts in my dotfiles that I should get around to releasing and maintaining someday. https://westurner.github.io/dotfiles/venv https://westurner.github.io/dotfiles/venv For publishing projects, I like environment.yml because of the REES support.
blendo 7y ago
I chose Anaconda for this use case: 1 Setup a production Python environment on Windows Server 2016 2 Write a README on how to set up a prod Python env on Windows Server 2016 (pretty short) 3 Tell my Win 10 coworkers to refer to the README to setup their own Python env 4 Minimize the number of "conda install" commands needed to setup a production Python env, which in our case are mostly the Oracle/cx_oracle and MS SQL Server dependencies.
tcpekin 7y ago
I'm in the same boat, but I use miniconda and install the individual packages I want as I need them, which helps minimize the size. For doing scientific analysis, it is really nice to have (basic) environment which has the basic required packages (matplotlib, numpy, scipy, ipython, etc.) from which I can duplicate and build off of. It works well with VSCode, and unlike other comments, I don't really see any negatives to the CLI. For someone who started not even programming a lot, to doing this in a scientific context (so potentially less rigorous with regards to how things should be perfectly set up, but where it is necessary that they are functional), this was by far the easiest and least complex way to set up all the stuff you need to get started.

by wenc 7y ago

westurner 7y ago

I also prefer conda for the same reasons. Precompiled MKL is really nice. Conda and conda-forge now build for aarch64. There are very few wheels for aarch64 on PyPI. Conda can install things like Qt (IPython-qt, spyder,) and NodeJS (JupyterLab extensions). If I want to switch python versions for a given condaenv (instead of just creating a new condaenv for a different CPython/PyPy version), I can just run e.g. `conda install -y python=3.7` and it'll reinstall everything in the depgraph that depended on the previous python version. I always just install miniconda instead of the whole anaconda distribution. I always create condaenvs (and avoid installing anything in the root condaenv) so that I can `conda-env export -f environment.yml` and clean that up. BinderHub ( https://mybinder.org/ https://mybinder.org/ ) creates docker containers from {git repos, Zenodo, FigShare,} and launches them in free cloud instances also running JupyterLab by building containers with repo2docker (with REES (Reproducible Execution Environment Specification)). This means that all I have to do is add an environment.yml to my git repo in order to get Binder support so that people can just click on the badge in the README to launch JupyterLab with all of the dependencies installed. REES supports a number of dependency specifications: requirements.txt, Pipfile.lock, environment.yml, aptSources, postBuild. With an environment.yml, I can install the necessary CPython/PyPy version and everything else. ... In my dotfiles, I have a setup_miniconda.sh script that installs miniconda into per-CPython-version CONDA_ROOT and then creates a CONDA_ENVS_PATH for the condaenvs. It may be overkill because I could just specify a different python version for all of the conda envs in one CONDA_ENVS_PATH, but it keeps things relatively organized and easily diffable: CONDA_ROOT="~/-wrk/-conda37" CONDA_ENVS_PATH="~/-wrk/-ce37" I run `_setup_conda 37; workon_conda|wec dotfiles` to work on the ~/-wrk/-ce37/dotfiles condaenv and set _WRD=~/-wrk/-ce37/dotfiles/src/dotfiles. Similarly, for virtualenvwrapper virtualenvs, I run `WORKON_HOME=~/-wrk/-ve37 workon|we dotfiles` to set all of the venv cdaliases; i.e. then _WRD="~/-wrk/-ve37/dotfiles/src/dotfiles" and I can just type `cdwrd|cdw` to cd to the working directory. (Some of the other cdaliases are: {cdwrk, cdve|cdce, cdvirtualenv|cdv, cdsrc|cds}. So far, I have implemented cdalias support for bash, IPython, and vim) One nice thing about defining _WRD is I can run `makew <tab>` and `gitw` to `cd $_WRD; make <tab>` and `git -C $_WRD` without having to change directory and then `cd -` to return to where I was. So, for development, I use a combination of virtualenvwrapper, pipsi, conda, and some shell scripts in my dotfiles that I should get around to releasing and maintaining someday. https://westurner.github.io/dotfiles/venv https://westurner.github.io/dotfiles/venv For publishing projects, I like environment.yml because of the REES support.

blendo 7y ago

I chose Anaconda for this use case: 1 Setup a production Python environment on Windows Server 2016 2 Write a README on how to set up a prod Python env on Windows Server 2016 (pretty short) 3 Tell my Win 10 coworkers to refer to the README to setup their own Python env 4 Minimize the number of "conda install" commands needed to setup a production Python env, which in our case are mostly the Oracle/cx_oracle and MS SQL Server dependencies.

tcpekin 7y ago

I'm in the same boat, but I use miniconda and install the individual packages I want as I need them, which helps minimize the size. For doing scientific analysis, it is really nice to have (basic) environment which has the basic required packages (matplotlib, numpy, scipy, ipython, etc.) from which I can duplicate and build off of. It works well with VSCode, and unlike other comments, I don't really see any negatives to the CLI. For someone who started not even programming a lot, to doing this in a scientific context (so potentially less rigorous with regards to how things should be perfectly set up, but where it is necessary that they are functional), this was by far the easiest and least complex way to set up all the stuff you need to get started.