4 ms·

Not a fan of Conda, the cli is terrible, their unofficial builds are opaque and in my experience the very few packages that are not available on pypi are rarely

by orf 7y ago

Not a fan of Conda, the cli is terrible, their unofficial builds are opaque and in my experience the very few packages that are not available on pypi are rarely worth installing (usually the worst kind of "research code"[1]). Simply using pipenv and pyenv is enough for me (brew install pipenv pyenv). You don't ever have to think about this, or worry you're doing it wrong. Every project has an isolated environment in any python version you want, installed on demand. You get a lockfile for reproducibility (but this can be skipped) and the scripts section of the pipfile is very useful for repetitive commands. It's super simple to configure the environment to become active when you move into a project directory. It's not all roses, pipenv has some downsides which I hope the new release will fix. When I need a temporary environment to mess around in, then I use virtualfish by running `vf tmp`: https://virtualfish.readthedocs.io/en/latest/ https://virtualfish.readthedocs.io/en/latest/ 1. https://github.com/menpo/menpo/blob/master/setup.py#L17 https://github.com/menpo/menpo/blob/master/setup.py#L17

btashton 7y ago
I have fully moved over to pipenv and it is what I onboard new people with. Not having a virtualenv that everyone names something differently and invariably gets checked in on accident was a big plus on its own. For a while I was encouraging people to use conda especially on windows, but with WSL I found it to be mostly unnecessary. I do still leverage pip install --user for tools that are stable enough and I use frequently.
xapata 7y ago
I have had the opposite experience. Pipenv chose to ignore the use case of developing a package. In the docs, they state they only care about projects that are directly deployed, not installed and used by some other project. Conda helps with both types of projects and handles non-Python dependencies. It takes way too long to make a Pipenv.lock file, and I need to be in the project folder to activate the env?! Terrible user experience.
gchamonlive 7y ago
+1 for pipenv I develop using pipenv and then deploy installing the dependencies directly in the folder. It works for AWS lambda and containers, although lambda layers are a little more tricky to release: `pipenv lock -r > requirements.txt` `pipenv run pip install -r requirements.txt -t .`
- mcintyre1994 7y ago
  You might find AWS SAM CLI worth looking at if you're finding that awkward : https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html https://docs.aws.amazon.com/serverless-application-model/lat... I used to have a Makefile to do the install dependencies in directory, test locally, zip the directory up, deploy to AWS jobs - but SAM is a really good replacement for that workflow. It uses docker containers too, and the other big thing it makes trivial if you need it is running an API gateway locally so you can test the Lambda as an HTTP API instead of just hacking events in as standard input/function inputs.
ihnorton 7y ago
> Not a fan of Conda, the cli is terrible, their unofficial builds are opaque and in my experience the very few packages that are not available on pypi are rarely worth installing (usually the worst kind of "research code"[1]). The CLI used to be slow, but since 4.6 the performance is reasonable -- still slower than some non-Python package managers, but in my experience no longer so slow as to be aggravating (< 10s install now, whereas previously >30-60s in the past just solving the environment) > their unofficial builds are opaque I'm not entirely sure what builds you are referring to, but conda-forge [1] is completely open source and community-driven, and Anaconda recipes are in a github organization called AnacondaRecipes [2]. If you are talking specifically about the Python interpreter builds for the Anaconda distribution, I believe the build recipes are here [3] (although I don't know that for a fact). > my experience the very few packages that are not available on pypi are rarely worth installing Depending on your field, platform, and dependencies, that is certainly believable. However, several projects such as Apache Arrow and Rapids have dropped support for PyPI wheels [4] because the engineering cost of wheel-building on linux is prohibitive, and conda is preferable on windows for a variety of reasons. > usually the worst kind of "research code"[1] That's an oddly-specific complaint. Anyway, given the variety of environments where people run `setup.py`, that kind of thing is usually explained by "someone put in a PR to make it build somewhere." It might be surprising if you've never built or packaged python extensions with native dependencies before, but I'm not sure it's a particular indicator of quality. [1] https://conda-forge.org/ https://conda-forge.org/ [2] https://github.com/AnacondaRecipes https://github.com/AnacondaRecipes [3] https://github.com/AnacondaRecipes/python-feedstock https://github.com/AnacondaRecipes/python-feedstock [4] https://medium.com/rapids-ai/rapids-0-7-release-drops-pip-packages-47fc966e9472 https://medium.com/rapids-ai/rapids-0-7-release-drops-pip-pa...
- orf 7y ago
  > their unofficial builds are opaque By opaque I mean: https://github.com/AnacondaRecipes/tensorflow_recipes/tree/master/tensorflow-base-cpu https://github.com/AnacondaRecipes/tensorflow_recipes/tree/m... What do these do. Why are they adding an alternative gettime implementation for MacOS? Why are they patching a bunch of test files to make them pass? > That's an oddly-specific complaint. It's unfortunately one we ran into recently while migrating a legacy system off conda, but it's not the first and I doubt it will be the last.
deleted 7y ago
[deleted]

by orf 7y ago

btashton 7y ago

I have fully moved over to pipenv and it is what I onboard new people with. Not having a virtualenv that everyone names something differently and invariably gets checked in on accident was a big plus on its own. For a while I was encouraging people to use conda especially on windows, but with WSL I found it to be mostly unnecessary. I do still leverage pip install --user for tools that are stable enough and I use frequently.

xapata 7y ago

I have had the opposite experience. Pipenv chose to ignore the use case of developing a package. In the docs, they state they only care about projects that are directly deployed, not installed and used by some other project. Conda helps with both types of projects and handles non-Python dependencies. It takes way too long to make a Pipenv.lock file, and I need to be in the project folder to activate the env?! Terrible user experience.

gchamonlive 7y ago

+1 for pipenv I develop using pipenv and then deploy installing the dependencies directly in the folder. It works for AWS lambda and containers, although lambda layers are a little more tricky to release: `pipenv lock -r > requirements.txt` `pipenv run pip install -r requirements.txt -t .`

mcintyre1994 7y ago
You might find AWS SAM CLI worth looking at if you're finding that awkward : https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html https://docs.aws.amazon.com/serverless-application-model/lat... I used to have a Makefile to do the install dependencies in directory, test locally, zip the directory up, deploy to AWS jobs - but SAM is a really good replacement for that workflow. It uses docker containers too, and the other big thing it makes trivial if you need it is running an API gateway locally so you can test the Lambda as an HTTP API instead of just hacking events in as standard input/function inputs.

ihnorton 7y ago

> Not a fan of Conda, the cli is terrible, their unofficial builds are opaque and in my experience the very few packages that are not available on pypi are rarely worth installing (usually the worst kind of "research code"[1]). The CLI used to be slow, but since 4.6 the performance is reasonable -- still slower than some non-Python package managers, but in my experience no longer so slow as to be aggravating (< 10s install now, whereas previously >30-60s in the past just solving the environment) > their unofficial builds are opaque I'm not entirely sure what builds you are referring to, but conda-forge [1] is completely open source and community-driven, and Anaconda recipes are in a github organization called AnacondaRecipes [2]. If you are talking specifically about the Python interpreter builds for the Anaconda distribution, I believe the build recipes are here [3] (although I don't know that for a fact). > my experience the very few packages that are not available on pypi are rarely worth installing Depending on your field, platform, and dependencies, that is certainly believable. However, several projects such as Apache Arrow and Rapids have dropped support for PyPI wheels [4] because the engineering cost of wheel-building on linux is prohibitive, and conda is preferable on windows for a variety of reasons. > usually the worst kind of "research code"[1] That's an oddly-specific complaint. Anyway, given the variety of environments where people run `setup.py`, that kind of thing is usually explained by "someone put in a PR to make it build somewhere." It might be surprising if you've never built or packaged python extensions with native dependencies before, but I'm not sure it's a particular indicator of quality. [1] https://conda-forge.org/ https://conda-forge.org/ [2] https://github.com/AnacondaRecipes https://github.com/AnacondaRecipes [3] https://github.com/AnacondaRecipes/python-feedstock https://github.com/AnacondaRecipes/python-feedstock [4] https://medium.com/rapids-ai/rapids-0-7-release-drops-pip-packages-47fc966e9472 https://medium.com/rapids-ai/rapids-0-7-release-drops-pip-pa...

orf 7y ago
> their unofficial builds are opaque By opaque I mean: https://github.com/AnacondaRecipes/tensorflow_recipes/tree/master/tensorflow-base-cpu https://github.com/AnacondaRecipes/tensorflow_recipes/tree/m... What do these do. Why are they adding an alternative gettime implementation for MacOS? Why are they patching a bunch of test files to make them pass? > That's an oddly-specific complaint. It's unfortunately one we ran into recently while migrating a legacy system off conda, but it's not the first and I doubt it will be the last.

deleted 7y ago

[deleted]