`fortls` 2.2.6 upgrade difficulties

[JHenneberg]

Hi
Updating from 2.2.5 to the newest Version is causing some troubles:

Win 11
VS Code 1.65.1
Python 310

[gnikit]

Hi @JHenneberg thanks for reaching out. So I was under the impression that this should work on Windows. Does installing something else like this work? e.g. python -m pip install numpy --upgrade.

As for the Modern Fortran error, it would indicate that some of the arguments passed in fortls are not supported. Would you mind posting your arguments here (both settings.json and .fortls, if any)

[gnikit]

I also just realised that the installation seems to be completing successfully, which is odd. From what I can tell the command line arguments are not interpreted correctly by the windows command-line shell

[JHenneberg]

In general I update my packages like this including fortls. Before I did not had any iusses. But I realised right now when I am updating pip itself I get the same error. So propbably this is a general problem and not a fortls specific one (-ortls just put me on the wrong track I guess).

Concerning the second error I just have one setting "fortran.fortls.notifyInit": true. I downgraded to 2.2.5 then the error does not appear.

[gnikit]

Concerning the second error I just have one setting "fortran.fortls.notifyInit": true. I downgraded to 2.2.5 then the error does not appear.

That is strange, I had a look at the Windows tests and they seem to be correct. I was also unable to replicate on my Linux machine. The only two things that v2.2.6 did was add the autoupdate functionality and deprecate --variable_hover.

If you install again v2.2.6, you might want to try and see if the binary is working, i.e. fortls -v and fortls -h yield any output, and then on a simple fortran file do something like fortls --debug_filepath yourfile.f90 --debug_rootpath . --debug_parser

[JHenneberg]

for 2.2.5:
fortls -v -> 2.2.5

for 2.2.6:
fortls -v ->

Traceback (most recent call last):
  File "C:\Users\He\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\He\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Users\He\AppData\Local\Programs\Python\Python310\Scripts\fortls.exe\__main__.py", line 4, in <module>
  File "C:\Users\He\AppData\Local\Programs\Python\Python310\lib\site-packages\fortls\__init__.py", line 12, in <module>
    from .langserver import LangServer
  File "C:\Users\He\AppData\Local\Programs\Python\Python310\lib\site-packages\fortls\langserver.py", line 17, in <module>
    from packaging import version
ModuleNotFoundError: No module named 'packaging'

[gnikit]

Awesome, that is unfortunate, I was hoping that I wouldn't have to manually update my dependencies and find would just work, but I guess not. You can solve the issue by installing manually https://packaging.pypa.io/en/latest/index.html e.g. pip install packaging

I will fix it in the next release.

[gnikit]

what's really puzzling me about this one is that it is a dependency in setuptools so it should be present for all installations. Anyhow, I have gone ahead and fixed it. I will release a version soon. Need to sort out some other things for conda first

[bilderbuchi]

what's really puzzling me about this one is that it is a dependency in setuptools so it should be present for all installations.

Maybe the pip packaging machinery makes a distinction between build time and run time dependencies (similar to like conda does)?

[gnikit]

I think you are right, but I also think I was wrong saying that packaging was included in setuptools. The SO post I saw must have been mistaken. That is simply not true. venvs come with pip and setuptools but not packaging