> What are we using now? > > Pip? Of course, for standard package installation. > Pyenv? Yes, if you need multiple Python versions available on the same sys

> What are we using now? > > Pip? Of course, for standard package installation. > Pyenv? Yes, if you need multiple Python versions available on the same system. > Pipenv? God no. https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/ https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-l... > Poetry? Hatch? Yes, for local environment management and library dependency configuration. > Conda? Not really, unless you're doing data science and are heavily invested in the rest of Anaconda ecosystem. I don't really understand where the confusion is coming from - Python is used in a wide number of use cases and scenarios, and it is no surprise that there are many different tools in the box, each solving a different subset of problems. The packaging issue has been all but resolved in recent years, with the advent of wheels, pyproject.toml and a number of other standards. > So now I have to hunt down whatever libraries gcc is complaining about. Which has nothing to do with Python.