Fix file+noindex URI usage on Windows

[jasagredo]

This PR fixes the parsing of URIs for file+noindex repositories when using Windows paths. As suggested by @phadej in #10703 we now use (and specify in the docs) //./C:/... paths on Windows.

QA

In Windows, one can now specify //./ paths in file+noindex repositories. To check, create a simple package, then cabal sdist, move the tar.gz to some directory and in a different project declare the following stanza:

repository my-local-repo
  url: file+noindex:////./C:/path/to/repo

It might still fail because of #9891

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!) fixing other tests failures seems like a good enough test for me

[jasagredo]

The key point of this PR is this call to normalise.

ghci> readFile "//./C:/some/path"
*** Exception: //./C:/some/path: openFile: does not exist (No such file or directory)
ghci> readFile $ normalise "//./C:/some/path"
"The contents of the file in C:/some/path\n"

[jasagredo]

Notice this was broken on Windows #10095 (comment), see how the paths in the output do not have a C: component, because of what I described in the first code block of #10703

[ulysses4ever]

Thanks! I wonder if we can pull in some of Andrea’s PRs after this fix…

[ulysses4ever]

The changelog says “can”, but docs says “has to”. These are different things, right?

[jasagredo]

I meant to say that now they can use local+noindex repos, previously they couldn't. And if they want to use it they have to use that syntax.

Isn't the wording right?

[ulysses4ever]

Yes, the "if" part that you say here (if they want to use it they have to use that syntax) is not in the docs. The docs just say "has". Could you add the "if" part?

[philderbeast]

The docs don't recommend direct comparison but to use isPathSeparator instead.

Rather than using (== pathSeparator), use this.

[jasagredo]

Im fine using isPathSeparator but keep in mind that

> Windows.isPathSeparator Posix.pathSeparator
True

[philderbeast]

I saw that too. I'm OK either way. Maybe a short comment attached to your choice?

[philderbeast]

I don't see any added tests with this pull request. Would it be possible to add some? How about a doctest example attached to the haddocks of asPosixPath?

[jasagredo]

I can do that for asPosixPath. The tests in PackageTests now pass without the hack in the output normalizer, I consider that sufficient enough proof for this small change.

[philderbeast]

Can you point me to a failed CI run or test before this fix?

[jasagredo]

Would this be what you are looking for? https://github.com/haskell/cabal/actions/runs/12402807907/job/34625090748?pr=10647 It stopped failing when a hack was put in place, the lines I remove in the OutputNormalizer

Also you might want to look at this comment and above in the Cabal matrix channel https://matrix.to/#/!YWYQDCuIpuQHzGrLzd:matrix.org/$TFlqqD7_hY3361aMFALPvP4Yzr3Ib7zMTNlu-_x0q-I?via=matrix.org&via=kf8nh.com&via=tchncs.de

[jasagredo]

(On the other hand, asPosixPath is so trivial that I don't see a huge benefit adding doctests, but if you insist I will do it)

[ulysses4ever]

Suggested change

	and is the only syntax for DOS paths fully supported by the `network-uri` package.
	and is the only syntax for DOS paths fully supported by the `network-uri` package,
	which Cabal uses to handle paths.