Closed BinderDavid closed 11 months ago
Also #221 seems to have introduced a dependency on os-string which is not reflected in the cabal file. The appveyor CI reports this error for my #223
https://ci.appveyor.com/project/Mistuke/win32-5ec4k/builds/48620220/job/414ddky2omugv629
System\Win32\WindowsString\Types.hsc:41:1: error:
Could not load module `System.OsString.Windows'
It is a member of the hidden package `os-string-2.0.0'.
Perhaps you need to add `os-string' to the build-depends in your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
41 | import System.OsString.Windows
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
System\Win32\WindowsString\Types.hsc:42:1: error:
Could not load module `System.OsString.Internal.Types'
It is a member of the hidden package `os-string-2.0.0'.
Perhaps you need to add `os-string' to the build-depends in your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
42 | import System.OsString.Internal.Types
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
System\Win32\WindowsString\Types.hsc:43:1: error:
Could not find module `System.OsPath.Data.ByteString.Short.Word16'
Perhaps you meant
System.OsString.Data.ByteString.Short.Word16 (needs flag -package-id os-string-2.0.0)
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
43 | import System.OsPath.Data.ByteString.Short.Word16 (
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
Error: cabal.exe: Failed to build Win32-2.13.4.0
I think this repo might also be missing branch protection for master? Ping @hasufell : You recently also worked on this repo.
Also #221 seems to have introduced a dependency on os-string which is not reflected in the cabal file.
It does not. You simply have to depend on filepath < 1.5.
That said, this library has to be updated to work with filepath >= 1.5.
It does not. You simply have to depend on filepath < 1.5.
Does this mean that in the meantime we have to add an upper bound on the filepath dependency? Because the failure occurs in the CI of this repo, not in some project of mine.
It does not. You simply have to depend on filepath < 1.5.
Does this mean that in the meantime we have to add an upper bound on the filepath dependency? Because the failure occurs in the CI of this repo, not in some project of mine.
Yes
It does not. You simply have to depend on filepath < 1.5.
Does this mean that in the meantime we have to add an upper bound on the filepath dependency? Because the failure occurs in the CI of this repo, not in some project of mine.
I think we can ask a hackage trustee to modify the bounds so CI and projects don't break.
I think we can ask a hackage trustee to modify the bounds so CI and projects don't break.
As a package maintainer you should have the rights to do metadata revisions yourself.
I think #221 introduced some code which generates "unused-imports" warnings when compiled with GHC. This leads to the fact that the submodule within GHC cannot be updated, since -Werror is enabled. I observed this in the following pipeline: https://gitlab.haskell.org/ghc/ghc/-/jobs/1722073