Summary: The makeRelativeToProject call in importQGLDocument should be removed.
Detail:
importQGLDocument is using the function makeRelativeToProject internally which implies that the parameter to importQGLDocument should be a relative path. However in at least one of the examples the path passed is implied to be an absolute path due to the explicit makeRelativeToProject call:
makeRelativeToProject "src/Server/API/simple.gql" >>= importGQLDocument
In the case above, makeRelativeToProject ends up getting called twice; this works by coincidence because the project root usually resolves to "./".
But in multi-component projects this is not the case and the extra makeRelativeToProject will cause problems. In my case this was compounded by a bug in Haskell Language Server which is returning an incorrect root for multi-component projects; the internal call to makeRelativeToProject made the HLS bug even harder to work around.
So, that's why I think makeRelativeToProject should be removed from importQGLDocument. The exact call I'm talking about is here. I also see a usage in readWith; that should probably go too.
Summary: The
makeRelativeToProjectcall inimportQGLDocumentshould be removed.Detail:
importQGLDocumentis using the functionmakeRelativeToProjectinternally which implies that the parameter toimportQGLDocumentshould be a relative path. However in at least one of the examples the path passed is implied to be an absolute path due to the explicitmakeRelativeToProjectcall:In the case above,
makeRelativeToProjectends up getting called twice; this works by coincidence because the project root usually resolves to "./".But in multi-component projects this is not the case and the extra
makeRelativeToProjectwill cause problems. In my case this was compounded by a bug in Haskell Language Server which is returning an incorrect root for multi-component projects; the internal call tomakeRelativeToProjectmade the HLS bug even harder to work around.So, that's why I think
makeRelativeToProjectshould be removed fromimportQGLDocument. The exact call I'm talking about is here. I also see a usage inreadWith; that should probably go too.