Installation from source on Linux Mint fails when installing pyparsing

Issue #266 closed
Manuel Stumpf created an issue

Operating System: Linux Mint 17.3 When following the installation guidelines the command "pip install -e ." fails when it comes to installing pyparsing:

Collecting pyparsing<2.0.0,>=1.5.0 (from celery<2.3,>=2.2.5->kallithea) Using cached pyparsing-1.5.7.zip Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/denisa/cppWorkspace/Kallithea/kallithea-venv/local/lib/python2.7/site-packages/setuptools/init.py", line 12, in <module> import setuptools.version File "/home/denisa/cppWorkspace/Kallithea/kallithea-venv/local/lib/python2.7/site-packages/setuptools/version.py", line 1, in <module> import pkg_resources File "/home/denisa/cppWorkspace/Kallithea/kallithea-venv/local/lib/python2.7/site-packages/pkg_resources/init.py", line 72, in <module> import packaging.requirements File "/home/denisa/cppWorkspace/Kallithea/kallithea-venv/local/lib/python2.7/site-packages/packaging/requirements.py", line 59, in <module> MARKER_EXPR = originalTextFor(MARKER_EXPR())("marker") TypeError: call() takes exactly 2 arguments (1 given)

Comments (16)

  1. Mads Kiilerich

    I guess this is on the stable branch ... or what version?

    It seems to be a problem elsewhere. You can probably reproduce the problem with pip install --upgrade pyparsing==1.57 (and up to 2.0.2).

    But it seems weird that it should install that old version - I'm getting a bit lost in dependencies ...

  2. Manuel Stumpf reporter

    Yes it was the latest stable branch commit.

    Meanwhile I found a solution: Leaving away the "pip install --upgrade pip setuptools" command before "pip install -e ." solves the problem.

    Seems like the upgrade command pulls in a pyparsing version >= 2.0.0.

    Then thereafter it is not possible installing pyparsing 1.5.7.

    But 2.x.x is not accepted by at least one dependency ("celery 2.3" when I correctly interpret the error message posted earlier).

  3. Mads Kiilerich

    I guess we still have to "fix" it, even though it isn't our "fault".

    The workaround works ... but not with pip install -e . --upgrade . Waitress requires setuptools, and setuptools is thus also upgraded ... and then it fails again.

    A first problem is that setuptools==34 requires packaging>=16.8 which has an unconstrained requirement of pyparsing ... but actually pip with pyparsing==1.5.7 (which is required by celery<2.3) will fail early. Setuptools (via packaging) really requires pyparsing>2.1 ( https://github.com/pypa/packaging/issues/91 ) and is thus inherently incompatible with celery<2.3.

    Running pip with pyparsing>2.1 will try to downgrade pyparsing to 1.5.7 and thus fail as http://stackoverflow.com/questions/41827464/pythong-pycparser-setup-error . (Which IMO is an example of how all dependencies should assume "semantic versioning" and have an upper bound on major release number.)

    How about this fix:

    --- a/setup.py
    +++ b/setup.py
    @@ -37,2 +37,3 @@ is_windows = __platform__ in ['Windows']
     requirements = [
    +    "setuptools<34", # celery requires pyparsing<2 and setuptools==34 has an undeclared requirement of pyparsing >=2.1
         "waitress==0.8.8",
    
  4. Manuel Stumpf reporter

    Indeed my workaround does fail with pip install -e . --upgrade. Your proposed fix works with both pip install -e . --upgrade as well as pip install -e ..

    But it only works when leaving away the pip install --upgrade pip setuptools command before (which the documentation tells me to call). On my machine this command upgrades setuptools from 2.2 to 34.0.3 and then I see the same error as reported.

    Whereas when directly using pip install -e . --upgrade the installation works and I have setuptools 33.1.1, which obviously is the result of your one line fix.

  5. Mads Kiilerich

    Right. I think we should double fix that:

    The documentation should be updated to always use pip install --upgrade "pip" "setuptools<34" everywhere so we don't update to a version we don't need.

    Also, we should use --upgrade when installing Kallithea so it would also would fix a wrong setuptools version if it should be wrong.

  6. Lars Skjærlund

    I've been hit by this one as well - and I agree on the analysis.

    The main problem seems to be that Kallithea requires a rather old version of Celery - Celery has reached version 4.1, and yet Kallithea requires a version below 2.3. There's been a lot of releases since then.

    As Celery is an optional component in Kallithea, wouldn't it be an idea to remove it from Kallitheas requirements list? An optional component can hardly claim to be required, after all.

  7. Mads Kiilerich

    Celery has been upgraded to latest version on the development branch. We hope to make a release soon.

    Celery is optional, but it is very recommended for "serious" use. It is a Python package without other "special" dependencies so I think it make sense to make it "automaticly available". Now, weird things happened elsewhere and it broke. We should think about that, but I don't think we should jump to conclusions just because of that.

  8. Mads Kiilerich

    I hoped it would be solved elsewhere.

    install --upgrade "pip" "setuptools<34" doesn't work for you?

  9. Liganic

    It does work (weird, I could've sworn it didn't a while ago). The documentation doesn't reflect it though. I assumed using the old version explicitly will break things once I upgrade kallithea later.

  10. Log in to comment