[dragonsh]

We have moved our dependency management from pipenv to poetry and hasn’t been more happier than now working with and publish Python modules.

Now we use pyenv with poetry to run all our projects in Python with venv in project instead of decided by poetry default settings. We changed the settings with:

  poetry config settings.virtualenvs.in-project true

After this in hgignore or gitignore added .venv folder.

Now everything is the way we wanted, with Pipenv many times faced issues that the project worked with requirements.txt but not in Pipenv. Didn’t have this issue moving to poetry yet.

Also with emacs support and automated deployment tools the predictability of poetry made our team easy to work with and publish Python application modules.

[wp381640]

fwiw I believe

    poetry config settings.virtualenvs.in-project true

is now

    poetry config virtualenvs.in-project true

[ageofwant]

Nice. I do however much prefer keeping the venv out of the source tree where they do not interfere with `tree` and `grep` and whatnot. I'm curios what benefit you see with having the venv cluttering the work-space ?

[wp381640]

It took me a while to be convinced to switch to in-folder venv but the benefits are

* VS Code configuration so much easier as you can point to the correct env using a relative path in settings.json and check that in

* Predictable paths to execute tasks / build

* No outside of development tree vens that you forget to clean up or forget to deactivate

* No different to node_modules, .git or similar when it comes to "polluting" the local project tree as you can .gitignore it

[BerislavLopac]

> as you can .gitignore it

As well as ignore config in codecov, black, flake8, mypy and so on...

[dragonsh]

We setup systemd with gunicorn or uwsgi start in the project venv. So when they are created inside the project folders is easy to have the automated deployment for Python softwares easy with systemd services or local scripts.

Our developers use mac, windows and Linux for development and each one have different location of venv with poetry, if we start gunicorn or uwsgi they may make mistakes. With predictable venv location all can work the same way from within project directory.

[brettcannon]

If you use a grepping tool like ripgrep it will automatically ignore everything in your `.gitignore`, so at least for that specific case you're covered.

[delaaxe]

Your app is self contained in a single folder (not 2), run scripts are simpler (can use relative paths like ./venv/ Scripts/foo, no need to “activate”...