Poetry: ipython can't be installed with python 2.7, even when an exact version is specified

[buriy]

• [x] I am on the latest Poetry version.
• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

Similar to #151 , but not sure how to resolve it at all.
The command "poetry add -vvv ipython" fails with a virtualenv on python 2.7 .

• OS version and name: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) x86_64 GNU/Linux
• Poetry version: 0.11.4
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/buriy/8db57876a178bb2a34095c1d9ca8d388

Issue

$ poetry update -vvv

[SolverProblemError]
The current supported Python versions are 2.7.9
Because no versions of ipython match !=6.5.0
and ipython (6.5.0) requires Python >=3.3, ipython is forbidden.
So, because myproject depends on ipython (*), version solving failed.

P.S.
Somehow "poetry update" works with exact version specified:
ipython = "5.8.0" but "poetry install" doesn't get it.

[jdraymon]

I did poetry add iPython=5.* which worked fine - though it'd be nice if the version could walk back to get something with compatible python when not specified

[buriy]

Yes, problem is not only with that last ipython for the user python version isn't detected correctly, but also that no user should get any cryptic or humiliating messages at all.
Right now the dialog looks like this:
-- install ipython
-- no, i won't, you're doing it all wrong.

[sdispater]

I agree that there is currently a bug preventing the resolver to backtrack to the proper ipython version.

However, fixing it will likely break some current projects.

Let's take an example. If you have set your python dependency to * then, currently, Poetry will accept ipython==6.5.0 since the resolver checks if the root package python dependency accepts any Python version specified by ipython.

This is obviously wrong and it should be the other way around: check if the ipython's Python constraint matches all Python versions specified by the python dependency of the root package.

However, this will break things if you have a package that declares being compatible with Python >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.* like pytest, because >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.* does not match * and, as such, pytest would be declared as incompatible.

So, there are two options here:

• Forbid the use of * for the python dependency and force users to use a proper constraint: >=2.7 or ~2.7 || ^3.4.
• Transparently mapping * for the python dependency to >=2.7 since previous version are no longer supported.

I am leaning towards the second option since this is the one being the less breaking.

[buriy]

@sdispater
Hm, the patch looks good, but it seems it doesn't completely fix this specific issue:
I set python = "~2.7" in my pyproject.toml file, and debug:resolve ipython gives me "... - ipython (5.8.0)", but poetry add --dev -vvv ipython command still generates ipython="^6.5".

```$ poetry add --dev ipython
Using version ^6.5 for ipython

Updating dependencies
Resolving dependencies... (0.0s)

[SolverProblemError]
The current supported Python versions are ~2.7
Because no versions of ipython match >6.5,<7.0
and ipython (6.5.0) requires Python >=3.3, ipython is forbidden.
So, because wnmanage depends on ipython (^6.5), version solving failed.
```

The only way to resolve is to use poetry add --dev -vvv ipython="*"

Option 1) Add a message to recommend that? Like this:
Failed to add ipython >= 6.5 for your Python version 2.7. Please try again with poetry add ipython="*" if you need _any_ good version of ipython, not the most recent one.
Option 2) Change poetry add to look up the _latest good version for the user platform_, instead of just _latest version for any platform_, matching what poetry debug:resolve does do.

[sdispater]

@buriy I see what you mean. I agree we should improve the behavior of the add command and select a constraint that satisfies the current project Python constraint.

[sdispater]

Closing this as the initial issue has been fixed.