-
Notifications
You must be signed in to change notification settings - Fork 710
haddock-project support public sublibraries #9821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f9874c3
to
898ff64
Compare
I am getting a lot of test failures of this sort:
on my dev machine, I use cabal's support for |
31b34fa
to
0bd944e
Compare
Try removing ~/.cabal maybe. |
291e98b
to
223839d
Compare
I think the |
btw, I don't have |
7ed8b05
to
f13915c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd appreciate if you wrote QA notes to ensure that this PR does for others what you expect it to.
Otherwise I don't see anything blocking. :)
LSubLibName sublib_name -> | ||
prettyShow (packageName pkg_descr) ++ "-" ++ prettyShow sublib_name | ||
_ -> prettyShow (packageName pkg_descr) | ||
-- TODO: how Hackage should deal with sublibraries? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we resolve this question? Do you want to ask gbaz?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this needs to be considered.
I see two choices:
- each sublibrary is available from it's own page;
- All public sublibraries are available on the main library page
The former might be cumbersome (since making a revision of each sublibrary will need to make a revision of all of them).
For the latter one might be able to use cabal haddock-project --hackage
maybe with some modifications to write a directory containing haddocks of all sublibraries which can be served by hackage. This might be not only more ergonomic but also the simplest way to support public sublibraries on hackage.
desclaimer: I have never contributed to hackage
so please take my word with a grain of salt 😄.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ ping @gbaz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The former might be cumbersome (since making a revision of each sublibrary will need to make a revision of all of them).
What do you mean by "revision" in this sentence? A cabal file revision on Hackage is a package-level thing so it would affect all package's libraries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean package revisions Hackage. I was considering if a sublibrary is exposed on its own, e.g. hackage.com/package/mypackage-sublibrary
while the main library is served from hackage.com/package/mypackage
.
But if we publish sublibraries as part of the package, e.g. hackage.com/package/mypackage/sublibrary
then it will be more consistent. Also finding sublibraries of a package will be simpler if links to them will be rendered on the package page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think mypackage/sublibrary
is the correct option here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@coot what's the final word on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't changed it from mypackage-sublibrary
to mypackage/sublibrary
. We'll need to pass a different --base-url
for sublibraries, but I already do that for test components and executables, so it's doable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@coot cool, I'd love this to be documented somewhere so that we don't forget it exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I adjusted the paths, but there's more work either on cabal
side or hackage
side. If we have a LIB
with a sublibrary SUBLIB
, then LIB
docs will be placed under LIB-0.1.0.0/doc/html/LIB
and the documentation of the sublibrary will be placed under LIB-0.1.0.0/l/SUBLIB/doc/html/LIB/SUBLIB/
.
There are various options from here to get sublibrary support on hackage:
- use
haddock-project
on hackage - this might require some changes tohaddock-project
; - copy the sublibrary documentation to the right place;
- as above, but let
cabal
do that. This might require changing the directory layout ofdist-newstyle
to be consistent (e.g. drop thel/t
subdirs).
I think the first option is the best one - but this is outside of this PR anyway.
@Kleidukos I added the QA Notes: and checked that it works as expected 😄. Do you know who else could review this PR? |
It might be worth noting that in an earlier version of this PR I experimented using
Maybe it's worth to use the |
9a5b6a7
to
320b408
Compare
As always I am late to the party. Looking at |
@andreabedini it's the whole point of this experimental command: To generate the haddocks of a whole cabal project (1 or more local packages) to a single documentation artifact |
Of course, but it's a cabal-install command, not a Setup.hs command. While |
7008c7d
to
2be7de9
Compare
@Kleidukos I addressed your comments regarding hackage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, let's get this merged. :)
I'm excited to use it and see which bugs we've missed. ❤️
Thanks for the work @coot
The main library must use the package name rather than `UnitId`, otherwise the links from other sublibraries will not work.
This commit makes haddock-project handle sublibraries. The commit changes how `cabal haddock` works, changing the layout in the `dist-newstyle` folder. With this change `haddock` subcommand will install `package:sublib` component in a directory `package-sublib` under `l/sublib/doc/html/`.
When running haddock-project `extra-doc-files` should be copied to a subdirectories of the `argOutputDir` corresponding to the component. This doesn't affect `haddock` command.
Haddock should know the sublibrary name rather than just the package. For sublibraries `package_name:sublib_name` is used. The name is recorded in the `.haddock` file and used when haddock creates the `index.html` file, e.g. when called by `haddock-project` command.
`--use-unicode` is added to `cabal haddock` and `cabal haddock-project`. One cannot simply use `--haddock-option="--use-unicode"` because it makes haddock to fail when building indexes.
Link test suites & benchmarks from the index.html; Provide the right `--base-url` flag for them.
2be7de9
to
fb68bc4
Compare
I cleaned up the commit messages and updated the changelog entry. |
fb68bc4
to
b118edb
Compare
Should this have closed #9577? |
@geekosaur I think so |
QA Notes
Running
cabal haddock-project
on a package with multiple public sublibraries should create./haddocks
directory which contains thepackage:sublibrary
haddocks in./haddocks/package-sublibrary
directory. All cross-references will be resolved to files inside./haddocks
directory../haddocks
directory should also contain both indexes:html
andquick-jump
index. Both indexes should contain references to identifiers from all public sublibraries.When using
cabal haddock-project --hackage
the cross-references between sublibraries will be resolved to hackage (as described in #9852).