4 ms·
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 pro
by 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 agoOP'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?