3 ms·

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

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?

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?