'EmptyConstraint' object has no attribute 'min' with pytest and Python 2.7

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

OS version and name: macOS 11.1 Big Sur
Poetry version: 1.1.5
Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/nikmolnar/cc95e80d0cf6c9256b53294b759b3881

Issue

I've discovered a bug that arises when pytest is combined with Python ^2.7 in pyproject.toml. The Gist linked above provides a minimal example of this issue. Running poetry lock with the above file results in the following exception:

AttributeError

  'EmptyConstraint' object has no attribute 'min'

The error does not appear if either pytest is removed or the Python version is changed to ^3.6. I originally reported this as part of #2372, but then realized that that issue related to error handing in response to an error in pyproject.toml. As this error occurs in a correctly-formatted pyproject.toml, I believe it is a distinct issue.

We started seeing this same error yesterday as well. I'm guessing some dependency in the tree did a release recently that is somehow exposing this bug.

After some debugging I think I narrowed down the problem to a recent backports.functools-lru-cache package release. Changing the dev-deps to this still reproduces the problem:

[tool.poetry.dev-dependencies]
"backports.functools-lru-cache" = "*"

As a temporary workaround, you can pin this dependency back like this:

"backports.functools-lru-cache" = "1.6.1"

poetry seems to be tripping up on this line from their setup.cfg:

	pytest-mypy; python_implementation != "PyPy" and python_version < "3.10" and python_version > "3"

Thanks for the workaround, @Nitori- !

Experiencing the same thing with python = "^3.6". I tried adding "backports.functools-lru-cache" = "1.6.1" to my deps or dev-deps, but it didn't solve the issue. You can see the failure on this CI pipeline.

My suspicion is that there might be another dependency out in the wild that also exposes the bug. If you can get poetry onto a debugger that's how I found out that the lru-cache package was causing issues.

I patched Poetry's source to catch the exception and print the package name:

~/.local/pipx/venvs/poetry/lib/python3.9/site-packages/poetry/core/packages/__init__.py line 219

        try:
            dep.python_versions = " || ".join(ors)
        except AttributeError:
            print(name)

The output showed pytest-mypy. Oh well I see now it was mentioned in your comments 😩

If you jump up maybe 2-3 stacks, you'll see the package that was depending on pytest-mypy. That's probably the one that needs to get pinned.

@pawamoy

@pawamoy I did some digging and the issue you're seeing is from backports.entry_points_selectable. Unfortunately it looks like there is no release to pin back to, the very first release has the same problematic line as the other backports module I mentioned above. I think the only way to work around this one would be to find what's depending on this backports package and pin that instead.

Of course, all of this is just workarounds. It's still fundamentally a bug in poetry that can't seem to handle this dependency line:

	pytest-mypy; python_implementation != "PyPy" and python_version < "3.10" and python_version > "3"

Damn, I can't work on any project now, nothing will resolve 😅
I'll have to debug this first! Thanks a lot for your help @Nitori-!

I wonder if pytest-mypy; python_implementation != "PyPy" and python_version < "3.10" and python_version > "3" is valid though:

> "3" suggests strictly higher than version 3, and Poetry deduces >=4, which seems correct to me?
then < "3.10" makes it impossible

Poetry should maybe simply catch the AttributeError to re-raise an InvalidMarker exception that will make the parent function try again without the markers, or re-raise a ValueError instead, making it skip this dependency.

            try:
                # Attempt to parse the PEP-508 requirement string
                dependency = dependency_from_pep_508(req, relative_to=root_dir)
            except InvalidMarker:
                # Invalid marker, We strip the markers hoping for the best
                req = req.split(";")[0]
                dependency = dependency_from_pep_508(req, relative_to=root_dir)
            except ValueError:
                # Likely unable to parse constraint so we skip it
                self._log(
                    "Invalid constraint ({}) found in {}-{} dependencies, "
                    "skipping".format(req, package.name, package.version),
                    level="warning",
                )
                continue

> "3" could also be understood as > "3.0", in which case the inequality makes sense so perhaps that was the intent? I agree >= "3" makes more sense, though.

@dkasak

@dkasak maybe! However I think it's parsed as precision 1, entering this condition:

                    if parsed_version.precision == 1:
                        if op == "<=":
                            op = "<"
                            version = parsed_version.next_major.text
                        elif op == ">":
                            op = ">="
                            version = parsed_version.next_major.text

(and so it's changing it to >= with the next major version, which is 4)

I guess we'll need to read the spec to decide if it's correct or not!

OK, PEP508 says versions comparison is done according to PEP440.

And using PEP440 version parsing, it seems Poetry should not consider >3 to be >=4 since

>>> import packaging
>>> from packaging import version
>>> version.parse("3.6") > version.parse("3")
True
>>> version.parse("3.6") >= version.parse("4")
False

Poetry core has a 1.1.0a1 release that refactored all this, I'll try it and report back.
UPDATE: well no, it suffers from the exact same issue.

Ah, there's a related PR python-poetry/poetry-core#154

I've identified the package who recently released a new version depending on backports.entry_points_selectable: pytest-randomly v3.6.0: pytest-dev/pytest-randomly@3.5.0...3.6.0 (look at requirements.in)

I was able to fix that issue in CI with the following hack:

    - name: Set up Poetry
      # HACK: https://github.com/python-poetry/poetry-core/pull/154
      run: |
        pip install git+https://github.com/python-poetry/poetry
        pip uninstall -y poetry-core
        pip install git+https://github.com/pbzweihander/poetry-core@resolve-invalid-python-version-constraint

But I guess I should simply downgrade and pin pytest-randomly to 3.5.0 🙂

ci: Temporary fix

@sdispater

Thanks for the quick work on this, @sdispater et. al!

I would love to see this fix released, as it hits me really hard in all (>50) of my projects.

backports.entry_points_selectable: Autospec creation for update from …

py-backports.functools_lru_cache: updated to 1.6.4

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.

Navigation Menu

Repository navigation

'EmptyConstraint' object has no attribute 'min' with pytest and Python 2.7 #3862

Issue

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

'EmptyConstraint' object has no attribute 'min' with pytest and Python 2.7 #3862

Description

Issue

Activity

JennToo commented on Mar 31, 2021

JennToo commented on Mar 31, 2021

nikmolnar commented on Mar 31, 2021

pawamoy commented on Apr 1, 2021

JennToo commented on Apr 1, 2021

pawamoy commented on Apr 1, 2021

JennToo commented on Apr 1, 2021

JennToo commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

dkasak commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

pawamoy commented on Apr 2, 2021

nikmolnar commented on Apr 3, 2021

sobolevn commented on Apr 4, 2021

github-actions commented on Mar 2, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions