09:07 <fluxm> recently I used filename iP.mli. yes, it's an eyesore in the filesystem, but so nice in the module system!

09:09 <zozozo> fluxm: you know that is also works if the file is named IP.mli ?

09:10 <fluxm> doesn't it cause a warning from some build systems 🤔

09:10 <zozozo> not to my knowledge

09:11 <fluxm> I guess dune doesn't complain. I had different recollection about it.

09:11 <fluxm> ah, nice filename is back :)

09:44 <d_bot> <colin> is there an easy way to get ocamldoc to work with dune

10:06 <d_bot> <Vaush> Did u try reinstalling it?

10:23 <d_bot> <colin> It works on its own, I just wonder if there's a well-defined way to have it traverse a project that's `executable` with a bunch of `library` subfolders and produce (linked) documentation.

11:27 <d_bot> <lubega-simon> Well, is there any strong reason you wouldn't want to use `odoc`, it works well with dune under `dune build @doc` command (https://dune.readthedocs.io/en/stable/documentation.html?highlight=odoc#generating-documentation)

11:39 <d_bot> <colin> Yes, I find `odoc` impossible to use. It seems to require more information than `dune` needs to build my project - which seems pretty bizarre if I just want to quickly output some HTML (and not have to incorporate `.opam` files such that `public_name` begins to work - `dune build @doc-private` generates separate folders that isn't navigable from a source index file). It also doesn't allow you to output documentation for `executable

11:40 <d_bot> <colin> It seems to me either I'm completely clueless about how this all works or `dune build @doc` is like 1/10th of the story when it comes to using `odoc` successfully.

13:31 <d_bot> <jonludlam> @colin odoc's primary use case is for documenting libraries in packages, and that's what dune's rules are intended to support. While it can be used more generally than that, doing so is 'off the beaten path' so it's going to be more tricky

13:32 <d_bot> <jonludlam> also, dune's not particularly picky about the contents of those odoc files, so just creating them with 'touch' is sufficient to allow 'quick' doc generation

13:35 <d_bot> <jonludlam> what is the use-case you have in mind for this?

13:36 <d_bot> <colin> documenting private libraries used within an executable project without lifting it to an opam package

13:37 <d_bot> <colin> I'm just used to documentation generation tools that are more simplistic; they just recursively traverse and produce whatever they can and then linked it all together by maintaining the breadcrumbs/path of how they got there in order to produce a suitable navigable index

13:37 <d_bot> <colin> so using odoc is like an ordeal in comparison

13:43 <d_bot> <jonludlam> who's the intended audience of the docs? you and people working on the executable?

13:44 <d_bot> <colin> yes

13:44 <d_bot> <colin> admittedly, I wouldn't mind packaging it using opam, I just don't know how to do that in a way that plays with the odoc

13:45 <d_bot> <jonludlam> right, so easiest for now is to make it a public library - add a (public_name) stanza and touch an opam file in your project root

13:46 <d_bot> <colin> I will try that again, I'm sure I got an error with it, I'll make an example project and report back

13:46 <rks`> (FTR. the distinction between private and public library comes from dune, so it's unclear that you'd be better off if dune used ocamldoc instead of odoc)

13:46 <d_bot> <colin> well, the distinction is meaningless to me as they're all private, public is just a formality to get odoc to play nicely an not generate stuff with broken links

13:48 <d_bot> <jonludlam> right, the private lib docs stuff definitely needs some work 🙂

13:49 <d_bot> <jonludlam> do you have an opam file for your executable?

13:50 <d_bot> <colin> yes, so then, do I somehow add `public_name`'d libraries to this `opam` file?

13:50 <d_bot> <colin> or do I end up putting an opam file in the root of the library

13:50 <d_bot> <colin> I get "Error: The current scope doesn't define package "foo"."

13:51 <d_bot> <jonludlam> normally all the opam files go at the root of the repository - it's all one repo I presume?

13:51 <d_bot> <colin> oh, so you have an opam for the executable root _and_ for each library (define in a subfolder of the executable's code)?

13:52 <d_bot> <jonludlam> you don't _need_ to have different opam files for libraries and executables

13:52 <d_bot> <colin> https://cdn.discordapp.com/attachments/436568060288172044/854720160471973898/2021-06-16-145223_814x490_scrot.png

13:52 <d_bot> <colin> I've never really used opam before

13:54 <d_bot> <Cyclomatic Complexity> Are there recursive module types in OCaml?

13:54 <d_bot> <jonludlam> right, you've declared your package to be called 'example' by making example.opam

13:54 <companion_cube> there's recursive modules but they're, hu, ugly

13:54 <companion_cube> imho

13:54 <d_bot> <jonludlam> so your public_name needs to be related to that

13:55 <d_bot> <colin> is there a way to have like multiple packages

13:55 <d_bot> <colin> such that if there was more than 1 library

13:55 <d_bot> <Cyclomatic Complexity> recursive module types, rather recursive modules

13:55 <d_bot> <colin> odoc would be forced to generate documentation with an index page that links to each library

13:57 <d_bot> <colin> oh, so if I made more than 1 opam, and the `name.opam` referred to a sub-folder `name/` that had a dune library project

13:57 <d_bot> <colin> it will all be collated from `dune build @doc`

13:57 <d_bot> <colin> ?

13:58 <d_bot> <jonludlam> yes, dune builds an index page linking to each package

13:59 <companion_cube> Cyclomatic: recursive module types are also a thing yes

13:59 <d_bot> <Cyclomatic Complexity> companion_cube: i can't find docs about them, and i get syntax errors on `module rec type` and `module type rec`

13:59 <companion_cube> hmmm

14:00 <d_bot> <Cyclomatic Complexity> indeed

14:00 <companion_cube> Drup uses them I think? or something like that, to avoid writing signatures twice

14:00 <companion_cube> I personally never use recursive modules

14:00 <d_bot> <Cyclomatic Complexity> i could homogeneize all types and use objects

14:00 <d_bot> <colin> ahh, so that's how it works, thanks jon, that's fixed my issue, I should probably RTFM next time :P cheers

14:00 <d_bot> <Cyclomatic Complexity> but i like the idea of keeping track of which objects can interact with which objects in the type system

14:01 <d_bot> <jonludlam> glad to be able to help 🙂

14:01 <Drup> there are no recursive module types

14:01 <Drup> only recursive modules, that can contain module types

14:01 <companion_cube> ah, well, my bad then.

14:02 <d_bot> <Cyclomatic Complexity> a

14:02 <d_bot> <Cyclomatic Complexity> aaa

14:04 <d_bot> <Cyclomatic Complexity> so, you can substitute a type in a `:=` substitution for a module type

14:04 <d_bot> <Cyclomatic Complexity> epic

14:05 <d_bot> <Cyclomatic Complexity> so i'll just write my module type in a polymorphic manner, and substitute it everywhere i need it

14:05 <d_bot> <Cyclomatic Complexity> hmmmmmmmmmmmmm

14:07 <d_bot> <Cyclomatic Complexity> doesn't work, because `Error: invalid package type: only module type identifier and 'with type' constraints are supported`

16:12 <d_bot> <EduardoRFS> technically recursive module types are possible, just that each access layer requires a transformation

16:16 <d_bot> <EduardoRFS> or if you like stackoverflow on the typer

16:25 <neiluj> Hello! Is there a way to specify a specific repository for a library in the dependencies of dune-project?

16:26 <neiluj> For instance, a gitlab repository.

16:26 <companion_cube> no, dune doesn't fetch dependencies for you

16:27 <neiluj> thanks, so maybe use an opam pin?

16:28 <companion_cube> yep

16:28 <companion_cube> oh wait, you mean, in the description in dune project

16:29 <neiluj> yes, the dependencies field

16:29 <companion_cube> https://dune.readthedocs.io/en/stable/dune-files.html#package I don't see anything related to pinning, only version constraints

16:31 <neiluj> all right, opam pin is fine.

16:36 <d_bot> <NULL> Maybe constraining to a version which should not be accessible by the opam repo (eg "~dev"), a pin would be the only possible way a user might satisfy these dependencies ?