Poetry: Ignore in project virtual environment

[ADR-007-SoftServe]

Hi!

I propose to add config settings.virtualenvs.ignore-in-project true flag to make it possible to use .cache/pypoetry/virtualenvs rather than .venv.

Use case:

1. build a Docker image: poery creates .cache/pypoetry/virtualenvs/*
2. link project root to Docker: poetry tries to use in poroject .venv that going from local machine

[hangtwenty]

Use .dockerignore

[ADR-007-SoftServe]

.dockerignore works for build only. Not for --mount

[ADR-007-SoftServe]

There no way to mount without subdirectories

[hangtwenty]

You can effectively mount without subdirectories if you are using docker-compose (
https://stackoverflow.com/questions/29181032/ )

[hangtwenty]

You need to explain your use-case and what you have tried (in more detail). It is not clear why you have a .venv folder yet want to ignore it. You are in control of your venvs and Poetry’s config, and it’s not clear why you can’t handle this with existing features.

[ADR-007-SoftServe]

Do you mean this https://stackoverflow.com/a/37898591 ?
It will not work. You still have .venv. It just will be empty.

[ADR-007-SoftServe]

I have a project that have several subprojects which have its own pyproject.py.

On my local machine, I would like to use config settings.virtualenvs.in-project true because PyCharm can find it automatically.

I have .dockerignore that ignores .venv.
I install dependencies for each subproject by cd subproject_a && poetry install

I use docker run --mount type=bind,source="$(pwd)",target=/app ... cd subproject_a && poetry run python something.py. On this step I have an error because poetry tries to use local .venv.

I understand that each project should have its own Dockerfile and we will fix it later.

[hangtwenty]

That helps to clarify!

What is insufficient about doing ‘config settings.virtualenvs.in-project false’ inside of the Docker image?

[ADR-007-SoftServe]

poetry run tries to use .venv even if ‘config settings.virtualenvs.in-project false’

[hangtwenty]

Huh. That surprises me, wondering if it’s something subtle about having
multiple projects - poetry config.toml can be per-project or global

[ADR-007-SoftServe]

Short example:

cd /tmp
mkdir tmp
cd tmp

poetry config settings.virtualenvs.in-project false
poetry init
poetry add requests

poetry run python -c 'import requests' # OK

mkdir .venv
poetry run python -c 'import requests' # Error

[hangtwenty]

@ADR-007-SoftServe so this is why!

https://github.com/sdispater/poetry/blob/c99ae5f96c6227491d36477657a1c82157567c7c/poetry/utils/env.py#L164-L166

There's special handling of .venv. Maybe you knew that.

I think the simplest change, which would also not require a new config flag, would be to make it so that handling of .venv only happens if the user has done poetry config settings.virtualenvs.in-project true (so in your case since that is false inside Docker it would not have the issue anymore) ... Or maybe as you originally suggested there could be a new config flag. But to me that is not worth having another bit of cognitive overhead for a newcomer.

[hangtwenty]

@ADR-007-SoftServe

If you look at create-env function as well, you can see that it does not have hardcoding to .venv and uses a config setting settings.virtualenvs.path. Which can be relative or absolute.

https://github.com/sdispater/poetry/blob/c99ae5f96c6227491d36477657a1c82157567c7c/poetry/utils/env.py#L216-L224

So your issue will be immediately resolved if you set it to something besides .venv. Then even if it's in-project true on your local (for PyCharm as you mentioned - my use case too!) -- and even if that venv gets copied in when you do your Docker mount -- Poetry will _not_ be picking it up automatically inside of your Docker container.

I actually think (small) documentation update is all that has to happen at first. then maybe the switching of the behavior for .venv activation, to respect in-project false, however that would be a breaking change for some people so perhaps it should be deferred as a second changeset...?

What do you think

[ADR-007-SoftServe]

It is about env activation. cwd / ".venv" hardcode here:
https://github.com/sdispater/poetry/blob/c99ae5f96c6227491d36477657a1c82157567c7c/poetry/utils/env.py#L163-L168

[rphes]

I'd very much like this fixed as well. In the meantime, assuming you don't strictly need a virtualenv in you docker container, you can use

export VIRTUAL_ENV=/usr/local

or wherever your system python resides, to make poetry use your container's system python.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing this issue automatically because it has not had any activity since it has been marked as stale. If you think it is still relevant and should be addressed, feel free to open a new one.

[lvkswrks]

Hi,
I'm also bitten by this. I have a similar use case as reviously mentioned.
The workaround suggested by rphes does not work anymore. Additionally, you need to delete the envs.toml.
I had the expectations, that if virtualenvs.in-project false and virtualenvs.path set to a path, poetry would ignore the local .venv folder. Treating local .venv differently is imho surprising in this scenario.
Would be great, if you could reconsider.

[finswimmer]

Hello @lvkswrks ,

this behavior is also discussed in https://github.com/python-poetry/poetry/issues/1770

fin swimmer

[lvkswrks]

Hi @finswimmer thanks for referring!