3 ms·

I go over the downsides in the article, but there is nothing fundamentally wrong with using pip and venv. It's just that if you've ever worked in other programm

I go over the downsides in the article, but there is nothing fundamentally wrong with using pip and venv. It's just that if you've ever worked in other programming ecosystems, it would be immediately apparent that things could be significantly simpler and more reproducible. Why does python need virtual environments? Why isn't it that you simply are in the correct environment when you're in your project folder? Why are there upwards of a dozen different config files for a project rather than just one standardized one? Why do you need to nuke your whole environment and recreate it just to remove one package? These things are silly. They get in the way of reproducibility. They are security liabilities. There is a better way

eesmith 2y ago
> Why isn't it that you simply are in the correct environment when you're in your project folder? I typically have several environments for my main project. Mostly I use a Python 3.12 version with the full set of optional third-party packages installed, but I also have a "clean" version with none of them installed so I can test error handling, as well as a Python 3.10 version as that is the oldest supported version for one of my third-party optional dependencies, plus a 3.8 version since I still support that version in my core system. In that way I can quickly test code against the typical deployment cases before committing. The project has about 500K lines of C code, mostly in one Python/C extension which takes over a minute to fully rebuild, but most changes are to Python code or other bits of Python/C or Cython code which are faster to rebuild, so I do editable builds for most of my work for the quick edit cycle. I don't know how to nominate one of these environments as "correct". (The full test suite against the various permutations of Python versions and 10 or so optional components is a mess. I've given up on testing all combinations as it wasn't proving worthwhile.)
- LarsDu88 2y ago
  Sounds like you may want to check out Hatch
  - eesmith 2y ago
    How would that help? At the end I'm still using setuptools to build the extension, right? So I'm stuck with the same core issues, but with a different front end? To add to the complexity, I distribute my software as source, and I am wary of telling my customers to install another package in order to run the commands to install my package.

eesmith 2y ago

> Why isn't it that you simply are in the correct environment when you're in your project folder? I typically have several environments for my main project. Mostly I use a Python 3.12 version with the full set of optional third-party packages installed, but I also have a "clean" version with none of them installed so I can test error handling, as well as a Python 3.10 version as that is the oldest supported version for one of my third-party optional dependencies, plus a 3.8 version since I still support that version in my core system. In that way I can quickly test code against the typical deployment cases before committing. The project has about 500K lines of C code, mostly in one Python/C extension which takes over a minute to fully rebuild, but most changes are to Python code or other bits of Python/C or Cython code which are faster to rebuild, so I do editable builds for most of my work for the quick edit cycle. I don't know how to nominate one of these environments as "correct". (The full test suite against the various permutations of Python versions and 10 or so optional components is a mess. I've given up on testing all combinations as it wasn't proving worthwhile.)

LarsDu88 2y ago
Sounds like you may want to check out Hatch
- eesmith 2y ago
  How would that help? At the end I'm still using setuptools to build the extension, right? So I'm stuck with the same core issues, but with a different front end? To add to the complexity, I distribute my software as source, and I am wary of telling my customers to install another package in order to run the commands to install my package.