[wyuenho]

Set up direnv, and then:

  cd /your/project && echo "layout python" > .envrc && direnv allow

Give it a go then tell me what the point is for any of these poetry/pipenv/hatch/flit/pdm/pyflow thingy if neither you or your teammates work on Windows.

[Tainnor]

That will only take care of setting up and loading the correct virtualenv. Which you may prefer to "poetry shell" or "poetry run", since it's more automatic, but that's not the main reason for using poetry.

The main reason to use poetry is sane dependency management the way it exists for most other ecosystems (bundler, cargo, npm, maven, gradle, ...). In particular, that includes lockfiles.

[wyuenho]

Use direnv to take care of the virtualenv part of functionality poetry offers, use pip-tools to deal with the dependency management/reproducible build part. Or if you like, straight up pip freeze.

Use pyenv to install all the different python versions you need.

Ideally, all of these functionality should bundled in one tool, but the only thing that's available is pyflow, which don't stop blowing up with an exception for me.

[Tainnor]

Then you're not recommending direnv as a poetry replacement, you're recommending direnv + pip-tools + pyenv. That's a different matter.

[wyuenho]

The hardest packaging problem in Python is not resolving dependencies or pinning down dependencies. Pip has it largely solved a some years ago. Literally every Python packager using some parts of pip underneath. The messiest part is literally packaging and how to install and isolate the packages.

How you install multiple Python versions doesn't really matter as long as the binaries are on your PATH. You can use Homebrew or Macports or Pyenv or whatever. The only remaining problem is how to manage your virtualenvs. You can use virtualenv or venv directly, but you will have to manage where to put them and remember to activate them before you install dependencies and dev tooling. But if you use direnv, it's fire and forget, once you have direnv setup and one line of directive in a .envrc file, or perhaps a few gitignore, you don't have to think about where to put the virtualenv or remember to activate it again.

So yes, I'm actually just recommending direnv if you want to keep it simple.

[Tainnor]

> The hardest packaging problem in Python is not resolving dependencies or pinning down dependencies. Pip has it largely solved a some years ago.

I really disagree, and I think so does everyone who uses Poetry, pipenv, pip-tools, etc.

[skrtskrt]

Yeah im a huge poetry fan for dep management but i never use “shell” or any of its virtualenv management features

[barefeg]

When your project depends on a module version and that module depends on another one (sub dependency), it’s very common that re-installing the same module version in a new environment will cause something to break because the sub dependency was updated. This is not something that direnv solves therefore those other tools are still needed.

[wyuenho]

pip freeze > requirements.txt

[barefeg]

Then you lose track of which are actual dependencies and which are sub dependencies

[wyuenho]

It doesn't matter. Pinning means pinning every dependencies and sub dependencies.