GSOC 2026 introduction

1

Hi everyone!

I’m Ameen, a SDE currently working at BlackBuck.
I’m interested in contributing to the vscode-fortran-support project for GSoC.

I’ve started exploring the repository and would love to work on the
Python environment manager idea.

Looking forward to learning and contributing!

1 Like
2

Hi @gnikit

I specialize in Typescript, javascript, python, react, spring, springboot, Gen AI. I’ve been exploring the Modern Fortran VS Code extension codebase as I’m interested in contributing to the Python Environment Manager project for GSoC.

From what I understand, the goal is to provide a reliable way to install and manage Python-based tools like fortls, fpm, and findent while respecting the user’s existing Python setup (system Python, venv, conda, etc.).

While going through the extension architecture, I started wondering about the environment resolution strategy.

Question:
How should the environment manager determine the preferred Python environment when multiple environments are available (for example: system Python, an active virtualenv, a Conda environment, or the Python interpreter selected in the VS Code Python extension)?

Would the expectation be to:

  • Respect the Python interpreter selected by the VS Code Python extension

  • Automatically detect active environments in the workspace

  • Maintain a dedicated extension-managed virtual environment

  • Or implement a priority-based fallback strategy

I’m particularly curious about this because the choice could affect tool reproducibility, dependency isolation, and user experience across different setups.

I’d really appreciate any insight into the current design direction or constraints for this environment manager.

Looking forward to learning more and contributing to the project!

Thanks!

2 Likes
3

Hi @gnikit @Pranavchiku :waving_hand:

I’m working on my proposal for the Python Environment Manager project. I’ve gone through the codebase and I understand the current approach in tools.ts.

findAnyPython() triespython3/py/pythonnaively, and
pipInstall() always uses--user(which breaks inside venvs).

My plan is to use the @vscode/python-extension API to detect the user’s active Python environment when the MS Python extension is installed. However, I have a question about the fallback behavior when the Python extension is NOT installed:

  1. Should we do smart detection (check VIRTUAL_ENV/CONDA_PREFIX env vars, scan for ./venv/ folders in the workspace)?

  2. Or keep it simple and just improve the current PATH-based approach with better error messages?

  3. Is there any preference for supporting pipx as an alternative installation method for CLI tools like fortls?

I want to make sure the scope is right for the 175-hour timeline.

4

Hi @mohammed_ameen,

I believe this issue is mostly resolved now. Haven’t heard any complaints since the last implementation (see full discussion on feat: better handling of Python packages and environments · Issue #1273 · fortran-lang/vscode-fortran-support · GitHub).

As for GSoC this year, I won’t be taking any students since I won’t have enough time to properly supervise and I don’t think that makes a good experience for the students. Maybe there are some other projects in Fortran-lang that interest you.

5

hey @gnikit @Pranavchiku can u tell me is this project open right now
vscode integration with fpm (vscode-fortran-support). as the python package manager is solved.
if ur not taking this can u please assign other mentors for this task.