Internal libraries break stack haddock
#3989
Comments
|
I've been following links to issues between projects and the long chain eventually led me to #3955 which is merged. But this issue is still occurring (as of |
|
Thanks for the report, I was able to reproduce and I'll try to solve it (I think it's close to a solution for #3996) |
|
@mihaimaruseac Trying to build pandoc, for what it's worth. I'm sure there's a simpler minimal reproducible case. |
|
There is, I reproduced it from the example in #3996 (although there is no documentation there to be generated) |
|
Does anyone know of a workaround? Should revert to |
|
Sorry, I stopped working on it to get HCAR out. I'll restart working on this after Tuesday/Wednesday when i hope to get HCAR public. |
|
@mihaimaruseac certainly. Most appreciated. I'm just a bit surprised that I couldn't find an obvious way to get around this. Usually in stack if something goes wrong it's worst-case nuke the .stack-work directory. |
|
I just bumped into this problem as well. I haven't found a workaround. |
|
@mihaimaruseac, any luck? |
|
Not yet, still working on it. |
|
@afcowie, do you recall which version of Pandoc exercised this bug? I tried it now with the latest but it no longer has internal libraries so it works for me. |
|
I found a workaround: with the fix in #4033 and if the internal library is not a dependency of the main library, I'll keep looking into this, but so far it seems that both in the case when the sublib is a dependency of the main library and not, Stack calls |
The one in resolver with |
|
Oh, I |
|
Related issue pointing to why the Stackage curator doesn't run haddock on haddock-library. commercialhaskell/stackage#3236 Seems to be a bug in Cabal, not in Stack. I'll be trying the rest of today to get a workaround, but I don't know how many chances of success I have. |
|
Tried making Stack run the steps suggested by haskell/cabal#4969 (comment) but it fails due to I'm going to put this on the back of my mind and work on something else for a while and maybe I'll get more ideas in meanwhile. Or maybe cabal gets updated to make the new-build commands the default and then Stack can pick it up and adapt. Sorry for not being able to solve this :( |
|
I think this could be fixed by linking the Setup program with the recent Cabal library (2.3.0.0+), but can't find any way to do it with Stack. |
|
Or by disabling haddock for some packages. |
|
@mihaimaruseac should #4111 fix this? |
|
I don't think so. I'm going to test it later today or tomorrow, but I'm almost confident it doesn't as this is blocked on calling Cabal in a totally different way than Stack does. |
|
Checked now, this is still an issue. |
Also changes the repo to Github since syncing to the `git.oscoin.io` mirror is unreliable. We need to disable building the haddocks temporarily because of commercialhaskell/stack#3989
More specifically, what file do I need to touch (ie create zero size) so that stack doesn't think that it needs to build haddock content for haddock-library. I'd be happy to use that as a workaround for now. AfC |
|
I don't think it's Stack. Stack just calls Setup.hs to build the haddocks, so probably it's a question for Cabal/GHC |
|
It looks like this Cabal problem was fixed in version 2.4.0.1, at least I got |
|
For what it's worth, pandoc 2.5 depends on haddock-library 1.7.0 which has dropped the troublesome internal (vendored?) dependency on attoparsec. So the problem is going to go away for people like me when that version hits Stackage. Which is great for me, but soon I won't have a clear idea if the underlying problem is fixed. I hope @qrilka's report is correct. |
|
|
|
The underlying problem most likely isn't fixed, it's just that haddock-libary devs were convinced to not use internal deps. Didn't get a chance to investigate the underlying problem yet, I'm too far back on open source work :( |
|
@mihaimaruseac why do you think it's not fixed? |
|
Try haddock-library 1.4.5 |
|
works fine as well - https://gist.github.com/qrilka/88f785ad331f577043c355fddd8690fa |
|
No, it doesn't: https://gist.github.com/mihaimaruseac/8eb45ef4ba223c6c801c8cd6d99000e8 You might have some env or binary in path which made it work, but it doesn't on a fresh install of HEAD of Stack. |
|
I see "ghc-8.2.2" in you gist @mihaimaruseac - how do you get it with LTS-13.0? I guess that's why you have that problem. BTW I still have old stack-1.7.1 on by $PATH by default, the problem isn't about Stack, it's about the change in how Cabal works. |
I was under the impression that this is a Cabal internals issue that Stack needs a work around for. |
|
Oh, missed that line, sorry, from a couple of Cabal issues I've read it looks like Stack could have some workaround even with some previous Cabal versions (though I'm not sure how) but it appears that now we don't need to :) |
|
Even manually switching to the LTR-13.0 resolver doesn't work |
|
@mihaimaruseac I think I have found was causes this for you: see special hack which was added exactly for this library - https://github.com/commercialhaskell/stack/blob/v1.9.0.1/src/Stack/Build/Execute.hs#L1328 |
|
I added that, in #4111 as it was solving other issues with internal libraries. |
|
Oh, but it looks like the error changed from the beginning of the issue, so maybe there's some chance of fixing this. If I get some time I'll investigate. |
|
One final point as to why this is not solved yet: I got a container with stahck-1.7.1 and, while |
|
I completely forgot about the docs themselves. I see docs for the internal library getting generated: But it looks like main library index doesn't include them (it overwrites the one from the internal library). |
|
I am still experiencing this issue. We have a large monorepo that still fails I get: You can find the offending Any idea when the fix in #4596 will be released? |
|
That change will be released with Stack 2. You can see the blog post for more details, but the earliest release date is May 29. In the meanwhile, you can try using the prerelease version. You can try |
|
Thank you. I was able to build correctly on the Git build of Stack, so looks like we'll just have to wait until the update. |
There's a bug in stack 1.9.x and `stack haddock` breaks when there's an internal library. For now, we're trying a newer version of stack where this bug should be fixed. commercialhaskell/stack#3989
The issue reported in haskell/cabal#4969 appears not to be fixed in stack: building haddock documentation for a package with internal libraries causes an error while resolving dependencies of the main library. The resolution proposed there, to use
cabal new-haddock, has no obvious stack equivalent.The text was updated successfully, but these errors were encountered: