And without ospath build flag as a consequence.
This is a temporary fix to build failures on the github CI for Windows
and OSX, which use too old a version of stack to support the nightly
ghc.
I have sent a patch to those workflows, and after it is applied, this
can be reverted.
However, filepath-bytestring is still in Setup-Depends.
That's because Utility.OsPath uses it when not built with OsPath.
It would be maybe possible to make Utility.OsPath fall back to using
filepath, and eliminate that dependency too, but it would mean either
wrapping all of System.FilePath's functions, or using `type OsPath = FilePath`
Annex.Import uses ifdefs to avoid converting back to FilePath when not
on windows. On windows it's a bit slower due to that conversion.
Utility.Path.Windows.convertToWindowsNativeNamespace got a bit
slower too, but not really worth optimising I think.
Note that importing Utility.FileSystemEncoding at the same time as
System.Posix.ByteString will result in conflicting definitions for
RawFilePath. filepath-bytestring avoids that by importing RawFilePath
from System.Posix.ByteString, but that's not possible in
Utility.FileSystemEncoding, since Setup-Depends does not include unix.
This turned out not to affect any code in git-annex though.
Sponsored-by: Leon Schuermann
While some RawFilePath and FilePath remain, this converts most of
git-annex to using OsPath.
(When built without the OsPath build flag, is falls back to using
type OsPath = RawFilePath.)
The goals are
1) improved performance by using OsPath end-to-end when possible
2) potentially avoiding memory use problems caused by pinned strict
ByteString, since OsPath uses ShortByteString
3) eventually eliminating the filepath-bytestring dependency so I don't
need to keep maintaining that library
(this doesn't get all the way, but close)
4) generally improved type safety, since OsPath is a newtype, while
FilePath and RawFilePath are just type aliaes.
This is the result of a type checker driven process. I started by
converting from System.Directory to System.Directory.OsPath, and from
System.FilePath to System.OsPath. Then I fixed all the compile errors,
which took 3 weeks of work.
Unfortunately, there are several test suite failures at this point.
Also, it only has been built on linux, on windows and OSX there are
probably ifdefs whose code still needs to be converted.
Note that there is a parallel line of commits, starting with
05bdce328d
which is the incremental progress as I worked on this. It will be merged
with this commit. In some cases, commits in that line explain in more
details the reasons for some specific changes.
Oops, in 0b9e9cbf70 I lost takeDirectory
in several places.
With this fixed, the test suite no longer utterly blows up, but still
fails in 7 places due to other bugs introduced in the OsPath conversion.
Sponsored-by: Graham Spencer
These are too widly used for other things to make sense to export OsPath
versions of them. And OsString also provides them and gets imported
qualified when needed.
The change of R.doesPathExist to doesFileExist I think fixes a reversion
introduced in commit 1ceece3108. Before
that commit, it was doesFileExist, and I assume to point is that this is
only supposed to return files, not any subdirectories that yt-dlp might
create while running.
Note that the additional use of System.FilePath.Posix likely fixes a
problem if this were used on windows. The AndroidPath uses / directory
separators. Before this, on windows, \ would have been used.
The change to newtype AndroidPath is only documentation.
If the filepath starts with something that is not valid utf-8, it would
have returned "". And if the filepath was all non-valid utf-8, it would
also return "".
Test suite is failing in windows in conflict resolution tests, where the
automatic conflict resolution adds in a .variant file. On windows, those
files are somehow missing. I don't understand why, and the test failures
only happen on appveyor and not in a local windows VM.
So, since replaceFile was recently changed to remove a windows specific
ifdef, put it back, to see if that is somehow causing these failures.
