Poetry installing dev/beta releases

I think this may be more to do with the way certain packages release on pip, in my case pytorch and tensorflow - I’ve not noticed this behaviour in other packages to date. Combined with neural nets being used to generate poetry, it’s tricky to google search for this so apologies if this is a duplicate.

Ubuntu 18.04 Poetry 0.11.5

Tensorflow toml

[tool.poetry.dependencies]
python = "^3.6"
numpy = "^1.15.0"
scipy = "^1.1.0"
scikit-learn = "^0.19.2"
tensorflow = "^1.10.1"
tensorflow-gpu = "^1.10.1"

  - Installing scikit-learn (0.19.2)
  - Installing tensorflow (1.11.0rc0)
  - Installing tensorflow-gpu (1.11.0rc0)
  - Installing ujson (1.35)

In this case this happens because I’ve specified numpy 1.15, only the 1.11 rc is able to work correctly. I’m not sure this is optimal behaviour - I shouldn’t get an alpha release in this case. Once I bump numpy to 1.14 I get 1.10.1 again.

In pytorch, it’s a bit different and I’m not sure what happens

[tool.poetry.dependencies]
python = "^3.6"
numpy = "^1.15.0"
scipy = "^1.1.0"
scikit-learn = "^0.19.2"
torch ="^0.4.1"
torchvision = "^0.2.1"

➜ poetry update
Updating dependencies
Resolving dependencies... (48.5s)

Package operations: 7 installs, 0 updates, 0 removals

Writing lock file
...
  - Installing pillow (5.2.0)
  - Installing torch (0.4.1.post2)
                                                                                                                                         
[VenvCommandError]                                                                                                        
Command ['pip', 'install', '--no-deps', 'torch==0.4.1.post2'] errored with the following output:                                       
Collecting torch==0.4.1.post2

Again doing pip3 install --user torch torchvision will install 0.4.1 while poetry tries to install the post2 release. I’m not sure what’s going on in this version tbh. I’ve worked around by setting equal for the time being.

[sdispater]

It has been discussed before and the decision remains: Poetry is not and never will be a Python management tool. This is something that tools like pyenv do really well and is not something a package/dependency manager should do.

And if you declare python = "~2.7 || ^3.4" which Python version should Poetry use?

Note however that with the next 0.12 release, the recommended installer will only need to be used once. The poetry tool will pick up the currently activated Python version and use it to create the virtualenv.

Basically:

$ curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
# Once installed you can just switch Python versions with tools like pyenv
$ pyenv install 3.7.0
$ pyenv local 3.7.0
$ poetry debug:info
Poetry
======

 * Version: 0.12.0a2
 * Python:  3.7.0


Virtualenv
==========

 * Python:         3.7.0
 * Implementation: CPython
 * Path:           /path/to/venv-3.7/


System
======

 * Platform: darwin
 * OS:       posix
 * Python:   /usr/local/var/pyenv/versions/3.7.0

$ pyenv local 3.6.5
$ poetry debug:info
Poetry
======

 * Version: 0.12.0a2
 * Python:  3.6.5


Virtualenv
==========

 * Python:         3.6.5
 * Implementation: CPython
 * Path:           /path/to/venv-3.6/


System
======

 * Platform: darwin
 * OS:       posix
 * Python:   /usr/local/var/pyenv/versions/3.6.5

[bertjwregeer]

The python version isn’t a dependency of poetry though, it is a dependency of the current project.

With

python = "^3.4"

You say that any python version, >=3.4.0,<4.0 will work, so installing into a venv that is version 3.5 is perfectly acceptable, even if your current Python is 3.7. If the venv already exists and was an older version of Python there is no issue with it.

However I think it would be awesome if poetry would recognise that the current active Python (for example using pyenv) does not match the venv, and create a new venv that matches that Python version that is currently active.

Do note that currently if you have Python 3.5 active for poetry, and no venv exists, even with something stating your project depends on python ^3.4 it will still create the venv using Python 3.5, not Python 3.7, so it doesn’t try to force the venv to the latest Python version.