4 ms·

The disadvantage of this approach is that you can't easily switch major Python versions per project. I use miniconda [1], and I'll create a conda env per projec

The disadvantage of this approach is that you can't easily switch major Python versions per project. I use miniconda [1], and I'll create a conda env per project, with the newest version of Python that is compatible with the dependencies. Also, conda doesn't just install Python packages, it can also install cuda drivers (e.g. for GPU accelerated pytorch/tensorflow [2]), it can also install ffmpeg, etc. The complaint in the article is true, that you do generally need to do a mixture of `conda install` and `pip install` depending on whether the package is in a conda package repository or not; but I've not found this too bad in practice - I look up whether the package is in a conda repo, and install from pip if it isn't. Also it would probably be better for conda to be automatically activated for a given project / folder, rather than needing manual activation via `conda activate <name>`, but you get used to it. [1] https://docs.conda.io/en/latest/miniconda.html https://docs.conda.io/en/latest/miniconda.html [2] https://pytorch.org/ https://pytorch.org/ <- conda is listed in pytorch installation guide

crabbone 3y ago
1. Anaconda tooling and PyPI tooling are just different things, you cannot substitute one for the other, so whether you had any success with Anaconda or not is really irrelevant to OPs problem. 2. How much more easier to you want this to be: python3.8 -m venv .venv38 python3.11 -m venv .venv311 This, at least for me, creates two environments with two different minor versions of Python. NB. I think, you meant "minor" version -- why would you want to switch between Python 2.X and Python 3.X today? Or did you actually meant that?
- montebicyclelo 3y ago
  1. Not sure what you mean? "is irrelevant to OPs problem" -> op advises to not use conda as a solution for Python packaging 2. This is easier than what you propose, because conda will install the python version for the env on the fly (including the patch version): conda create -n myproject python=3.9.4 conda activate myproject NB. if we're being pedantic, conda and anaconda are different Yep, should be minor, but I chose to use the same language as the article [1] [1] https://www.bitecode.dev/i/110377053/dont-install-the-latest-major-version-of-python https://www.bitecode.dev/i/110377053/dont-install-the-latest...
  - crabbone 3y ago
    OP's advise comes from not understanding of what Anaconda Python is (most likely simply never tried it). The problem OP is fighting is a complex of problems related to Python packaging the way PyPI sees it (i.e. Wheels, Eggs, PyPI index, dependency specification, versions specification as done according to PyPI). Anaconda Python ignores all of that. It distributes a different set of packages, governed by different rules. PyPI tools and Anaconda tools aren't interchangeable the way pyenv virtual environments are with, eg. venv virtual environments. On the other hand, if the user needs something from Anaconda world, then no PyPI tools are of any use to them. It's just a different thing, essentially, it's a different language. I mean, it's the same grammar rules and the interpreter binary is mostly the same, but everything else is different. It's kind of like advising someone having issues with error handling in GNU Emacs to not use Spacemacs. It's just irrelevant, although for the outsider might feel like it's somehow related. As for your conda example? -- so what? OP didn't want to use conda in the first place... why are you showing this to me?

crabbone 3y ago

1. Anaconda tooling and PyPI tooling are just different things, you cannot substitute one for the other, so whether you had any success with Anaconda or not is really irrelevant to OPs problem. 2. How much more easier to you want this to be: python3.8 -m venv .venv38 python3.11 -m venv .venv311 This, at least for me, creates two environments with two different minor versions of Python. NB. I think, you meant "minor" version -- why would you want to switch between Python 2.X and Python 3.X today? Or did you actually meant that?

montebicyclelo 3y ago
1. Not sure what you mean? "is irrelevant to OPs problem" -> op advises to not use conda as a solution for Python packaging 2. This is easier than what you propose, because conda will install the python version for the env on the fly (including the patch version): conda create -n myproject python=3.9.4 conda activate myproject NB. if we're being pedantic, conda and anaconda are different Yep, should be minor, but I chose to use the same language as the article [1] [1] https://www.bitecode.dev/i/110377053/dont-install-the-latest-major-version-of-python https://www.bitecode.dev/i/110377053/dont-install-the-latest...
- crabbone 3y ago
  OP's advise comes from not understanding of what Anaconda Python is (most likely simply never tried it). The problem OP is fighting is a complex of problems related to Python packaging the way PyPI sees it (i.e. Wheels, Eggs, PyPI index, dependency specification, versions specification as done according to PyPI). Anaconda Python ignores all of that. It distributes a different set of packages, governed by different rules. PyPI tools and Anaconda tools aren't interchangeable the way pyenv virtual environments are with, eg. venv virtual environments. On the other hand, if the user needs something from Anaconda world, then no PyPI tools are of any use to them. It's just a different thing, essentially, it's a different language. I mean, it's the same grammar rules and the interpreter binary is mostly the same, but everything else is different. It's kind of like advising someone having issues with error handling in GNU Emacs to not use Spacemacs. It's just irrelevant, although for the outsider might feel like it's somehow related. As for your conda example? -- so what? OP didn't want to use conda in the first place... why are you showing this to me?