Use non-default python when creating virtualenv

[Suor]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

I want to use non-default python for virtualenv, my current workaround:

mkvirtualenv -p python3.7 app
poetry install

It would be cool for poetry to do two things:

• check if python specified in pyproject.toml is available and use it
• provide -p path/to/python switch

Now it just fails with a confusing message.

[jacebrowning]

check if python specified in pyproject.toml is available and use it

Poetry will likely never become a Python version manager, see #439 (comment).

provide -p path/to/python switch

I believe that functionality is available in the 1.0 alpha releases: #731

[Suor]

I don't suggest managing python versions, I only suggest using appropriate python if it's already available in PATH. As far as I see poetry env use creates virtualenv, so am I supposed to execute:

poetry env use python3.7
poetry install

to use system Python3.7?

[Suor]

My logic behind this feature request is - one should be able to supply python when creating virtualenv, which poetry install does, thus -p switch. But if python version is defined in pyproject.toml and we have needed python available in PATH we should not require manual -p use.

[cjw296]

What works for me:

pythonx.y `which poetry` shell
poetry install

Would that work for you?

[changeling]

But if python version is defined in pyproject.toml and we have needed python available in PATH we should not require manual -p use.

I'd like to second this request. I suspect I'm not alone in encountering Poetry, reading the docs, and being surprised when:

[tool.poetry.dependencies]
python = "~3.6"

Didn't lead to a Poetry created venv based on that declaration, but:

[RuntimeError]
The current Python version (2.7.10) is not supported by the project (~3.6)
Please activate a compatible Python version.

When the docs state:

When you execute the install command (or any other "install" commands like add or remove), Poetry will check if it's currently inside a virtualenv and, if not, will use an existing one or create a brand new one for you to always work isolated from your global Python installation.

I assumed that:

To create the virtualenv for the current project, Poetry will use the currently activated Python version.

Simply meant that, in the absence of a pyproject.toml, this would be the behavior, but that if it was declared, that would be used to create the venv..

I'd really love that to be the case, but if it isn't, second-best would be to more explicitly address that in the docs.

Though given the frequent plugs for pyenv, perhaps integrating that as a dependency and handling pyenv transparently in the event of a .toml python declaration wouldn't be a bad idea.

[changeling]

Poetry will likely never become a Python version manager.

And nor should it! I completely agree with that thinking.

However, since a virtualenv is already being created, checking the path for a [tool.poetry.dependencies] declared python version or alternatively, and likely ideal given potential issues with the dependency declaration, an entry in [build-system] for the preferred virtual environment python version. If that check fails, issue a warning and fall back to the established behavior.

[build-system]
requires = ["poetry==0.12.11"]
preferred_python = ["~3.6"]
build-backend = "poetry.masonry.api"

Given how many projects and teams are now implementing Poetry and beginning to depend on it to provide a common environment, and the fact that Poetry already creates a virtual env, this seems like a reasonable feature to expect.

Not at all a step towards package management nor python management. Simply an attempt to used a declared python version, if it exists, when creating the virtual environment that Poetry already creates.

[Suor]

I probably should clarify my use case: I use system pythons and virtualenvwrapper and try to swap the latter to poetry. I never used pyenv nor I want to.

[exhuma]

Additionally, having the Python version explicitly in the command ensures that it is used for that one execution only. If all you want to do is run a one-shot command it is cumbersome to do:

> source env/bin/activate
> python run-my-comand
> deactivate

instead of

> ./env/bin/python run-my-comand

This is especially true for automated CI pipelines where one job is not necessarily running in the same context as another. Having the ability to add the env-path as a command-line argument makes this explicit in the job definition and it also helps the reader of the CI definition file.

[geryogam]

@Suor:

It would be cool for poetry to do two things:

• check if python specified in pyproject.toml is available and use it
• provide -p path/to/python switch

I completely agree.

@sdispater solved the second point, by introducing a new poetry env command in the merged PR #731, which allows users explicitly creating virtual environments with a specified Python interpreter before running the previous commands. This great feature will be released in Poetry 1.0.0.

However he did not solve the first point, the implicit way is still broken. In the absence of an activated virtual environment, Poetry should implicitly create a built-in virtual environment with the Python version specified by the tool.poetry.dependencies.python property of the pyproject.toml file, not the Python version resolved by the #!/usr/bin/env python shebang line of the ~/.poetry/bin/poetry script.

[stale]

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.

[exhuma]

This is still relevant.

[sdispater]

This has been fixed in the latest beta releases of the 1.0.0 version.

[matthijskooijman]

As mentioned in #988 (comment), I think half of this is fixed by #731. The other half is the subject of #1386, so maybe this issue should be closed and discussion continue there?

[sdispater]

@matthijskooijman #1386 has been addressed in #1477

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.