Fix/windows support

[BareninVitalya]

Fix: Improve Windows Compatibility

This PR addresses two key issues encountered when running the project on Windows:

---

1. Avoid --reload with uvicorn on Windows

When launching FastAPI with uvicorn --reload, Windows uses _WindowsSelectorEventLoop, which does not support asyncio.create_subprocess_exec.
This breaks functionality such as check_repo_exists, which depends on subprocess support.

Proposal:
Add the following note to the documentation (e.g., README.md or developer guide):

Note for Windows users:
Avoid using --reload when running uvicorn. The default event loop (_WindowsSelectorEventLoop) does not support subprocess creation, leading to runtime errors. Instead, use uvicorn src.server.main:app.

---

2. Automatically enable Git long path support

Git on Windows may fail when cloning repositories with deep paths:

Fix:
The ensure_git_installed() function was updated.
If the platform is Windows, the function now automatically enables long path support:

if sys.platform == "win32":
    await run_command("git", "config", "--system", "core.longpaths", "true")

[NicolasIRAGNE]

For point 2:

As a general philosophy, I think it is best to avoid setting any system / global git properties -- instead prompting the user to do so or emitting a warning.

I think just checking for the option and printing warn logs is a better way to handle this problem.

[cyclotruc]

This looks reasonable to me, would have to run some tests but I don't have easy access to a windows machine right now

[NicolasIRAGNE]

hmm im not sure why the test fails and I cant test on my windows PC atm, can you take a look @BareninVitalya ?
sorry for the delayed responses I have been a bit busy

[BareninVitalya]

hmm im not sure why the test fails and I cant test on my windows PC atm, can you take a look @BareninVitalya ? sorry for the delayed responses I have been a bit busy

CI fails because git config --system core.longpaths requires Administrator privileges on Windows runners. When this fails, a RuntimeError is raised, which causes many unrelated tests to fail.

I will update the function to print a warning instead of raising an exception if checking or setting core.longpaths fails. This will allow CI to proceed without interruption and avoid unnecessary test failures on Windows.

[BareninVitalya]

Fix: Gracefully handle Windows long path support check

Checking whether long path support is enabled on Windows turned out to be more complex due to Git’s configuration priority levels (local, global, system).

For Git to correctly support long file paths on Windows, the setting core.longpaths must be enabled specifically at the --system level. This requires Administrator privileges. Attempting to check or set this option without elevated permissions raises an error, which previously caused the application and tests to fail unexpectedly.

To avoid this, we now detect whether the current process is running with Administrator privileges before attempting to check the core.longpaths setting using --system. If the setting is enabled and the process has sufficient privileges, we proceed silently. If not, we display a clear warning to inform the user that Git clone operations may fail due to long file paths, and how to resolve the issue manually.

[NicolasIRAGNE]

Wait, I'm not sure I get it

Why do you check using --system?

Imo just checking git config core.longpaths is sufficient, as it will check if the option is enabled in any level, and does not require admin access.

[NicolasIRAGNE]

(I don't think warning on every non-elevated execution is desirable)

[BareninVitalya]

(I don't think warning on every non-elevated execution is desirable)

To clarify: when you run git config core.longpaths without specifying a level, Git defaults to checking the --global level. Unfortunately, this is insufficient for long path support to work correctly on Windows — even when running under an administrator account.

You can verify this with a simple test:

git config --system core.longpaths true
git config core.longpaths
# → still returns false (because this checks --global, not --system)

This behavior was reproducible on my local machine under both a standard and an admin user. Unless core.longpaths is set at the system level, Git operations on long paths will still fail (e.g., during repo cloning).

I agree that issuing a warning every time the app runs without elevation is not ideal. I need to think about how to approach this problem differently.

[BareninVitalya]

Here's what I propose as a balanced solution:

I keep the current admin check and the conditional system-level core.longpaths inspection only if the process is elevated:

if sys.platform == "win32":
    try:
        if ctypes.windll.shell32.IsUserAnAdmin():
            stdout, _ = await run_command("git", "config", "--system", "core.longpaths")
            if stdout.decode().strip().lower() != "true":
                print(
                    f"{Colors.BROWN}WARN{Colors.END}: {Colors.RED}Git clone may fail on Windows "
                    f"due to long file paths:{Colors.END}",
                )
                print(f"{Colors.RED}To avoid this issue, consider enabling long path support with:{Colors.END}")
                print(f"{Colors.RED}    git config --system core.longpaths true{Colors.END}")
                print(f"{Colors.RED}Note: This command may require administrator privileges.{Colors.END}")
    except RuntimeError:
        # Ignore if checking 'core.longpaths' fails due to lack of administrator rights.
        pass

This way:

• I don't raise a warning unnecessarily for non-admin users.
• I only warn when:
  • I can check --system (i.e., admin context),
  • And it's not set to true.

---

Alternative

I also considered catching the actual Git failure (e.g., Filename too long) during repo cloning, and displaying a friendlier message in the frontend instead of a full traceback.

However, this has drawbacks:

• It happens after the failure, which may confuse users.
• It’s harder to maintain and localize properly.

Let me know if this middle-ground solution makes sense to you.

[NicolasIRAGNE]

To clarify: when you run git config core.longpaths without specifying a level, Git defaults to checking the --global level. Unfortunately, this is insufficient for long path support to work correctly on Windows — even when running under an administrator account.

Are you sure? I was checking the documentation

[BareninVitalya]

I conducted extensive testing on two separate Windows 10 machines (different builds), using Git versions 2.46 and 2.50. Here's what I observed:

• By default, core.longpaths is absent from all config scopes (system, global, and local).
• Setting core.longpaths=true with --global alone is sufficient to enable long path support — unless there is a conflicting --system setting.
• If core.longpaths is set at the --system level, it takes precedence, and Git ignores the --global value.
• Removing the --system setting (via git config --system --unset core.longpaths) restores the --global behavior.
• This behavior suggests that Git evaluates the system config early during clone, possibly before --global or --local are loaded.

Now check:

stdout, _ = await run_command("git", "config", "--global", "core.longpaths")

This is enough if users have not configured core.longpaths before.

[NicolasIRAGNE]

Maybe I am missing something but why is
git config core.longpaths
not sufficient here? we don't need to check at which level the option is enabled, just that it is enabled

[BareninVitalya]

Maybe I am missing something but why is
git config core.longpaths
not sufficient here? we don't need to check at which level the option is enabled, just that it is enabled

You are right, for our case this is indeed sufficient and it behaves as expected without the need to explicitly check --global.
I'll change it now

[NicolasIRAGNE]

fine by me but I think one of your commits is unsigned and prevents merge

can you try to fix that?

[BareninVitalya]

fine by me but I think one of your commits is unsigned and prevents merge

can you try to fix that?

I tried to sign my commit using interactive rebase. As a result, other commits in the branch were rewritten and lost their original signatures.

Can I create a new PR with only my signed change to fix the issue?

[NicolasIRAGNE]

You could try rebasing again and only signing the 2 commits that are missing a signature I think, but yeah this is not very convenient

Also, instead of making a PR with only your signed changes you could just force push on this one

Let me know if you need help

I'll see what I can do to make it less of a pain in the ass

[NicolasIRAGNE]

Hmm feel free to add me on discord (jackylafrite) we can try and fix that history

[BareninVitalya]

Hmm feel free to add me on discord (jackylafrite) we can try and fix that history

Thank a lot. I think I was able to solve the problems.