Poetry: Add a way to set a fixed Python version for a project

Created on 13 Nov 2018 · 8Comments · Source: python-poetry/poetry

[x] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Since this is an issue that has arisen before (see #522) and there is some confusion around which Python version Poetry uses, introducing a more explicit way to tell which Python version to use seems reasonable.

Before we go into more details of what it would look like, it's important to note that the default behavior (using the currently activated Python) will remain. This new feature will only make it more convenient for people to choose explicitly what they want to use.

So, with that being said, here is what a possible implementation could look like.

This requires the introduction of a new command which would accept a python executable as an argument. The argument must be a full path to a Python executable or a python command that is in the path:

poetry project use --python python
poetry project use --python python3
poetry project use --python /full/path/to/python

What this command would do is create a virtualenv like the ones currently created in the form {project_name}-py3.6, and write the association of the virtualenv and the project to a file so that Poetry knows what to use.

If the virtualenv already exists and it is not currently associated with the project, it will be associated. This makes switching between virtualenvs easier.

This will likely be implemented for the release of the first stable 1.0.0 release.

CLI Feature Setup

Source

sdispater

👍16

Most helpful comment

PR #731 is ready for review :-)

sdispater on 11 Dec 2018

❤2 🎉2

All 8 comments

Hi,
Happy to see some evolution about it.

About adding a new command:

Poetry has already many commands so adding new ones should be considered to not make the things to complicated. Why add a new command since we already have install, run config...

Since you propose to create the virtualenv with the project use command why not use the install command which already exists ?
poetry install --python python3.6 would do the job creating and linking or just linking to an existing venv and set a flag as default venv for the project.
Same thing for the run command : poetry run --python3.6 my_command : create/link the venv, then install and run the command.

About the way of switching between env I understand the idea of a project use command but at the end, it's nothing more than : install a new venv, link it to project and make it default venv for current project : poetry install --python other_python.

About the name of the new command

If we go anyway with a new command, I think one word should be better :
not project use but only use or set ?
The project word is not consistant with rest of the api. why would we have a projet use and not project add ?

About the virtualenv name :

Should we handle the micro version ?
Should we take care of project with same name ? maybe add a hash (path of project, author of project) in the name ?

About the per-project .venv

if the python version specified is different from current, we should manage to make poetry erase the current .venv and reinstall an new one.

About the multiplication of virtualenv in cache with this new option :

maybe we should add a command :rofl:
poetry clear remove the current flagged venv of the project
poetry clear --all remove all the virtualenv associated with current project

It was a bit long sorry, thanks for taking time to question our views, its cool

jgirardet on 13 Nov 2018

👍1

Since you propose to create the virtualenv with the project use command why not use the install command which already exists ?

No, because this is not the purpose of install which is only to install the dependencies.

Having a separate command makes the association of the current project with a specific Python version explicit.

About the name of the new command

Regarding the name of the command, it is not set yet and is just here to show the intended use case.

Should we handle the micro version ?

No, I don't think so. To me the minor version is the important one, not the patch version.

Should we take care of project with same name ? maybe add a hash (path of project, author of project) in the name ?

I wondered too but the cases where you have two Python projects with the same name are rare and do not warrant changing the current implementation.

About the multiplication of virtualenv in cache with this new option

This can be handled by the future env command. And now that I think about it, I think we can make the env command handle this feature (like a env use command).

sdispater on 13 Nov 2018

👍1

So if I understand your mind, poetry workflow will have two entry points:
poetry install : install using current python version
poetry env use whatever-version: install using custom version

I deduce :
poetry env use /path/to/python3.6 : check if venv exists, create if needed, flag this venv in a config file for this project, then install poetry.
then
poetry env use python3.5 : does same thing for python3.5 if python3.5 is in path or fail
then
poetry env use python3.6 or shorter poetry env use 36 : switch flag to 3.6
poetry env use 37 : fail if no python3.7 env installed
poetry env use python3.4: fail if python3.4 env not installed but succeds if python3.4 is in path.

We could add poetry env list or/and poetry env use {autocompletion showsavailable venv version}

jgirardet on 13 Nov 2018

I wondered too but the cases where you have two Python projects with the same name are rare and do not warrant changing the current implementation.

I run into this fairly often, and have started using the venv in dir setting to mitigate this issue. It's fairly often the case when I am trying to reproduce a poetry bug with a minimal example, or even when I am working on projects for myself and for my company where the two may have the same names.

bertjwregeer on 14 Nov 2018

👍3

I think this use case is not unusual :
you clone a repo : do somethings
you decide to fork it and then clone your fork
you got two project with same name.

jgirardet on 14 Nov 2018

👍4

I also have with some regularity wanted two different local envs of the same project. For example, if I'm playing around with different sets of dependencies for different work. I think taking the path into account somehow would be wise, probably via a hash or something. I know pipenv does something like that, though I'm not sure exactly what their algorithm is.