81–90 of 152 posts
genuine question - is nobody using anaconda/conda in production ? I have found the binary install experience in conda far more pleasant than in anything else. Going forward, the trend is going to be pipenv+manylinux ( https://github.com/pypa/manylinux ), but conda is super pleasant today
What's wrong with pipenv? I am genuinely curious. On local : mkdir my_project_directory cd my_project_directory export PIPENV_VENV_IN_PROJECT=1 (To make the virtual environment folder determininstic(.venv/) otherwise you will get a hash based directory(my_project_directory-some-hash-value) which might not be suitable for automatic deployments in applications like docker. I don't know why this is not default.) pipenv…
Last time I tried, it also required that the target Python version be installed somewhere on the path. If pipenv used venv instead of virtualenv, something like pyenv to retrieve/install Python versions, and was distributed as a full executable (rather than requiring a bootstrapped Python) I would actually it.
What's wrong with pipenv? I am genuinely curious. On local : mkdir my_project_directory cd my_project_directory export PIPENV_VENV_IN_PROJECT=1 (To make the virtual environment folder determininstic(.venv/) otherwise you will get a hash based directory(my_project_directory-some-hash-value) which might not be suitable for automatic deployments in applications like docker. I don't know why this is not default.) pipenv…
A lot of people seem to run into bugs and some hit a brick wall when they report them: https://www.reddit.com/r/Python/comments/8elkqe/pipenv_a_gui... Personally I think poetry doesn't get enough visibility. It's not as hyped as pipenv but it feels a bit nicer: https://poetry.eustace.io/
After skimming the docs and tinkering with poetry a bit, I'm not sure what my workflow with it would be for containerized python apps, though - where you generally don't want virtual environments at all. Pipenv handles that case pretty well.
I might reach for it though if I were developing open-source libraries that would be distributed on pypi
I feel that all of these language specific solutions still only solve halve the problem. Your code depends on a lot more than _just_ the python libraries. And often this is exactly what makes projects break on different systems. Let me make another suggestion: nixpkgs [0] it helps to define exactly that fixed set of dependencies. Not just on published version number, but on the actual source code _and_ all it's depen…
Earlier quoted context omitted.
A lot of people seem to run into bugs and some hit a brick wall when they report them: https://www.reddit.com/r/Python/comments/8elkqe/pipenv_a_gui... Personally I think poetry doesn't get enough visibility. It's not as hyped as pipenv but it feels a bit nicer: https://poetry.eustace.io/
Poetry looks nice - that dev has authored some other really nice looking libs. After skimming the docs and tinkering with poetry a bit, I'm not sure what my workflow with it would be for containerized python apps, though - where you generally don't want virtual environments at all. Pipenv handles that case pretty well. I might reach for it though if I were developing open-source libraries that would be distributed on…
Here's to Python 4 actually fixing this mess.
Earlier quoted context omitted.
Why are you moving away from conda going forward?
Not OP, but we would like to move away from it as well. - Breaking behavior between minor versions ( https://github.com/conda/conda/issues/7290 ) - Environments not actually being isolated ( https://github.com/conda/conda/issues/448 ) - Can't create environments in long paths ( https://github.com/conda/constructor/issues/156 ) Those are just a few I can remember. We unfortunately have not found a strong replacement.
See https://github.com/conda/conda/issues/7248 for where conda intends to head in the future on the environment.yml issue.
> Environments not actually being isolated
That's actually a really sticky issue, and one that's more about the python interpreter itself rather than anything conda is doing. More recent discussion at https://github.com/conda/conda/issues/7173. Yes, we can change the default behavior of the python interpreter. Either way though, we'll be making a group of people mad.
> Can't create environments in long paths
Of course you can. `conda create` works well with long paths on unix systems (Windows is more difficult, but we're working on that too). What you're bumping into in that issue is that the constructor installer builder isn't (right now) compatible with longer paths. The solution really is to get conda bootstrapped onto your system, and then just use that one conda. You don't need full miniconda installations scattered all over the place. One easy way to do it is bootstrap conda into `/opt/conda` and then symlink `/opt/conda/bin/conda` to `/usr/local/bin/conda`. Now `conda create` whatever and wherever you want.
> We unfortunately have not found a strong replacement.
Conda definitely isn't perfect, and it's far from a "done" project. One thing we do have at this point is years of battle-hardening with something like six million active users blanketing all sorts of operating environments. With conda-forge being as strong as it is today, I'm not sure anything else like it really exists. Nix and pkgsrc are probably the closest alternatives.
genuine question - is nobody using anaconda/conda in production ? I have found the binary install experience in conda far more pleasant than in anything else. Going forward, the trend is going to be pipenv+manylinux ( https://github.com/pypa/manylinux ), but conda is super pleasant today
What happens when there isn't a conda recipe for some package or inexplicably some dependency? Do I go back to pip? sudo pip ;) ? Use virtualenv?? Nothing is ever solved.......
You go contribute it on conda-forge? The conda team is also actively working on improving some of these problems specifically for python users. When you create a new conda environment with python in it, we put pip in it for you too. In a way, we're implicitly encouraging you to use pip along with conda, and yet it's not a seamless experience. So https://github.com/conda/conda/issues/7053 is a current effort. Eventually, we're working toward conda being able to install wheels directly (at least pure-python wheels at a minimum), so that packages available on PyPI that conda-forge or Anaconda haven't built out yet can still be installed with conda.
> Do I go back to pip? sudo pip ;) ?
If you're putting `sudo` in front of `pip`, you're probably doing it wrong ;-)
I'm not sure why the scientists don't use VMs and simply save the virtual disk files? That would at the very least allow them to verify the settings at a later date. Fresh install reproducibility doesn't seem necessary to verify experimental findings as long as the original vm is available to boot up.