Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: fortls discovery on Windows #957

Open
1 task done
michaelkonecny opened this issue Aug 2, 2023 · 2 comments
Open
1 task done

feat: fortls discovery on Windows #957

michaelkonecny opened this issue Aug 2, 2023 · 2 comments

Comments

@michaelkonecny
Copy link

michaelkonecny commented Aug 2, 2023

Is there an existing request for this?

  • I have searched the existing issues

Feature Request

On Windows, pip install --user fortls installs fortls into %appdata%\Python\PythonXY\Scripts, which is typically not in PATH.

I'd like the extension to be able to discover fotrls in this location as well, as one could then just install the extension, accept the suggestion to install fortls and start working. This is currently not the case.

At the same time, I don't want to break anything for existing users.

I would suggest using this logic:
If the the configuration value of fortls.path is equal to the default value, then:

  • try if fortls is callable globally
  • if not and we're on Windows, try to look into the %appdata% python scripts folder mentioned above

If the value of fortls.path is not default, then follow the logic we have currently (if path is absolute, use it. if it is relative, try to resolve it relative to the document/workspace/home folder).

One think I am hesitant about is whether the default value of fortls.path should remain fortls. It makes complete sense for the current logic and linux/mac, as the value mimic the way you would run fortls from bash.
But if the server is run from the %appdata% scripts folder, it seems nicer to me to have the default value be an empty string and maybe add a little explanation somewhere on where fortls is run from on each of the platforms.

@gnikit what do you think?

I will prepare a PR, but I don't want to rush things until we agree...

Note to self: issue #773 (lookup of formatters) is related and should be dealt with after this.

@gnikit
Copy link
Member

gnikit commented Aug 4, 2023

So I had a chat a while back with the folks over at ms-python.python and afterwards I went ahead and started with PR #824 (very deceptively named), which allows for what you are requesting and a lot more, virtual environments, multiple python configs, etc.

I had to stop with the PR because I realised there were violations with the Single Responsibility, which lead me down to libraries in TypeScript that allow for easy dependency injection/inversion.

@dnwillia-work
Copy link

dnwillia-work commented Sep 20, 2023

FWIW I always use a virtual environment locally in my source tree and install all the necessary Python packages for Modern Fortran into that. For instance, you could do this:

cd FortranSource
%appdata%\Python\PythonXY\python -m venv venv

and then install fortls, findent etc... into that

pip install fortls
pip install findent
...

then activate it

./venv/Scripts/activate # windows

and then make sure to select that virtual environment in VS Code. It's helpful to spin up VS code right from the cmd window you create the virtual environment in. It's definitely working fine so I'm not sure why you need #824.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants