Environment Markers + Poetry Issues

[adithyabsk]

Simple base project created using:

$ poetry new test

Poetry
Version: 1.0.0a2
Python:  3.6.5

Virtualenv
Python:         3.6.5
Implementation: CPython
Path:           /Users/adithyabalaji/Coding/GeorgianPartners/test/custom
Valid:          True

System
Platform: darwin
OS:       posix
Python:   /Users/adithyabalaji/.pyenv/versions/3.6.5

[tool.poetry]
name = "test"
version = "0.1.0"
description = ""
authors = ["Name <email@email.com>"]

[tool.poetry.dependencies]
python = "^3.6"
tensorflow = "^1.13.0-rc1"

[tool.poetry.dev-dependencies]
pytest = "^3.0"
tox = "^3.5.0"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

[tool.tox]
legacy_tox_ini = """
[tox]
isolated_build = True
envlist = py36

[testenv]
whitelist_externals = poetry
commands =
    poetry install -vvv
    poetry run pytest
"""

Error:

  AttributeError: module 'enum' has no attribute 'IntFlag'

Issue

After many hours of trials and tribulations, I am unable to coerce tox to work with poetry. As suggested in the latest poetry and tox documentation, I am using the isolated_build parameter in the tox ini and have found that for some odd reason, tox seems to be using the wrong python version (ie enum34 becomes active) when executing. I have found the same issue when building the project from scratch using poetry using custom virtualenv (pyenv) causes the enum34 error whereas a venv using standard python does not which makes me think the bug is on poetry's end as opposed to tox but I am not sure. I have cross posted the bug report to both projects to hopefully get some help to track this one down.

[gaborbernat]

This is nothing to do with either projects, grpcio pulls in enum34 that breaks your interpreter effectively by shadowing the true enum package https://github.com/tox-dev/tox/issues/1163#issuecomment-462284316

[adithyabsk]

Following up on this issue from poetry's end it seems that poetry finds the wrong dependencies for grpcio (ie enum34). Output of poetry lock -vvv:

...
   1: fact: grpcio (1.18.0) depends on six (>=1.5.2)
   1: fact: grpcio (1.18.0) depends on futures (>=2.2.0)
   1: fact: grpcio (1.18.0) depends on enum34 (>=1.0.4)
...

poetry debug info:

Virtualenv
Python:         3.6.5

Shows that poetry is recognizing the correct python version (in the "install" virtualenv), nevertheless. @sdispater any ideas as to a direction to take to debug this?

[adithyabsk]

Upon further trawling through poetry's issues this seems related to https://github.com/sdispater/poetry/issues/844#issuecomment-458178991 Will follow up with grpcio. In the meantime, is it possible to blacklist a package in pyproject.toml to prevent it from being added to poetry.lock? Every time I run poetry update, enum and futures get added back. I have tried setting the python major version to less than 3 for enum34 but no dice still.

[adithyabsk]

@mehrdada It seems that this was addressed and reverted in https://github.com/grpc/grpc/pull/16235. Did the macos python 3.4 build fail by chance because of a less than operator being used in the python environment marker as opposed to a less than equal?

INSTALL_REQUIRES = (
    "six>=1.5.2",
    "futures>=2.2.0 ; python_version<'3.3'",
    "enum34>=1.0.4 ; python_version<'3.5'"
    'six>=1.5.2',
)

[mehrdada]

I wouldn't know. Pinging @ericgribkoff who's in charge now.

[adithyabsk]

@mehrdada Thanks for pinging the right person! Look forward to your a resolution to this as it is a huge hassle to projects that are trying to simplify to pyproject.toml

[adithyabsk]

Seems like grpcio fixed this in https://github.com/grpc/grpc/issues/18013. Might this be worth adding to a FAQ as it seems to be a common problem?

[funkyfuture]

i'd say it isn't common enough for the faq. given that the problem is fixed, it will also decease to occur.

[adithyabsk]

Thought I'd update the title so that people could find the issue and resolution easier.

i'd say it isn't common enough for the faq. given that the problem is fixed, it will also decease to occur.

@funkyfuture I'm not sure I'd agree. From https://github.com/sdispater/poetry/issues/844#issuecomment-472252717 It seems that using sys.version_info is a fairly common pattern. As it's not the recommended pattern as per PEP508, it might be worth documenting that one would run into issues using that pattern for poetry users somewhere

[github-actions[bot]]

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.