3 ms·

I guess that there are many tools for environments now... my personal choice is using conda (I actually start with miniconda and download what I need from conda

by fabioz 6y ago

I guess that there are many tools for environments now... my personal choice is using conda (I actually start with miniconda and download what I need from conda-forge). It provides the needed isolation, you can get lots of packages without having to compile from conda-forge and it still works with pip for the odd cases where a given package is not directly available (as a bonus, it works for other native toolchains, not only Python, which is a huge plus for me). As a note, I personally use it with `conda devenv` to be able to replicate installs for a given project -- i.e.: https://conda-devenv.readthedocs.io/en/latest/ https://conda-devenv.readthedocs.io/en/latest/.

tyrion 6y ago
The only thing I never understood about conda, is why it does not support packages from pypi. I mean, the Python community has a standard repository for packages (pypi). You cannot even name a library $something if $something is not available on pypi. Why would I use something hosted by a private company that does not even interface with the rest of the community? This is not an attack on conda. I just cannot understand its rationale.
- fabioz 6y ago
  The real problem (which is solved by conda) is that pypi doesn't solve dealing with non-python packages well (say, compile scipy and make all related native packages communicate well). This is a huge issue for people dealing with scientific packages (and the main pain point which pypi being just python-focused on installing on site-packages doesn't solve well enough IMHO). Also, while it was initially done by a private company, I'd say it's definitely a community effort right now (it's also the reason I tend to use https://conda-forge.org/ https://conda-forge.org/, which is community driven and not anaconda). As for dealing with pypi, it does integrate well enough for me (given that you can just pip install packages on the python for which conda is managing the env), but yes, the other way around isn't true (conda solves a bigger problem than pypi up to the point that it's possible to even have non-python tools available -- one real use case example I have here is having innosetup binaries as a tool in the PATH in some conda env for doing builds). Note: I don't have any affiliation with any of that, these are just my preferences for managing python envs (when I'm developing pydevd, which is the debugger engine used in pydev/pycharm/vscode, many times I need to reproduce some weird env and before using conda that was pretty annoying).
- deleted 6y ago
  [deleted]

by fabioz 6y ago

tyrion 6y ago

The only thing I never understood about conda, is why it does not support packages from pypi. I mean, the Python community has a standard repository for packages (pypi). You cannot even name a library $something if $something is not available on pypi. Why would I use something hosted by a private company that does not even interface with the rest of the community? This is not an attack on conda. I just cannot understand its rationale.

fabioz 6y ago
The real problem (which is solved by conda) is that pypi doesn't solve dealing with non-python packages well (say, compile scipy and make all related native packages communicate well). This is a huge issue for people dealing with scientific packages (and the main pain point which pypi being just python-focused on installing on site-packages doesn't solve well enough IMHO). Also, while it was initially done by a private company, I'd say it's definitely a community effort right now (it's also the reason I tend to use https://conda-forge.org/ https://conda-forge.org/, which is community driven and not anaconda). As for dealing with pypi, it does integrate well enough for me (given that you can just pip install packages on the python for which conda is managing the env), but yes, the other way around isn't true (conda solves a bigger problem than pypi up to the point that it's possible to even have non-python tools available -- one real use case example I have here is having innosetup binaries as a tool in the PATH in some conda env for doing builds). Note: I don't have any affiliation with any of that, these are just my preferences for managing python envs (when I'm developing pydevd, which is the debugger engine used in pydev/pycharm/vscode, many times I need to reproduce some weird env and before using conda that was pretty annoying).
deleted 6y ago
[deleted]