Looking for Ideas for the Package Overview Page on OCaml.org

It’s great to see energy being put into this @sabine :slight_smile:

I’m sympathetic to this view. However, how could you signal that a package is broken and unmaintained? I’ve stumbled upon one recently, which simply translated into wasting my time. I’d like to avoid that as much as possible. The last published date, however imperfect as a metric, at least gives a hint that “someone is working on this”.

I agree with prior comments: I expect a README to be a TLDR, that should help me assess and try the package. If I want to dig further, then I read the documentation.

Slightly off-topic but I like golang’s concept of “runnable examples”, equivalent to the idea that “a picture is worth a thousand words”.

If you could somehow have an influence on making that happen, while making this idea the center point of documentation (and so its display), I wouldn’t be surprised if that’d impact documentation as whole pretty significantly

1 Like

@sabine I suggest you go with a self assessment. When we write our annual report at INRIA we are asked to evaluate our software along the following two axes:

  1. Maturity. Specify the current level of maturity of the software.
    • Demos: Demos work, rest not guaranteed, loose documentation, no real
    • Basic usage: Basic usage should work, terse but usable documentation, some software engineering, basic bug fixes done from time to time
    • Well-developed software: Well-developed software, fairly extensive documentation, reasonable software engineering and testing, attention to usability, dissemination, bug fixes, and user feedback
    • Major software project: Major software project, strong attention to functionality and usability, extensive documentation, strong software engineering, systematic bug chasing, and regression testing
    • High-assurance software software engineering: High-assurance software, certified by an evaluation agency (Common Criteria, DO- 178, etc.) or formally verified
  2. Evolution and maintenance. Detail which kind of evolution and maintenance are planned.
    • No real future plans: No real future plans
    • Basic maintenance: Basic maintenance to keep the software alive
    • Good quality middle-term maintenance: Good quality middle-term maintenance, with persistent attention to users
    • Long term support: Well-defined and implemented plan for future maintenance and evolution, making it possible for users to use the software without risk for important projects, organized users group
    • Commercial quality maintenance: Commercial quality maintenance

For instance I have a package memprof-limits which is intended to be well-developed software, long -term support at this stage. But I expect it to take some time to pick-up steam. For instance, we want to use it in the Coq Proof Assistant, but this will not happen before the minimum supported OCaml version is old-enough (and other factors such as available workforce). As such it does not have reverse-dependencies yet. Also it does not need to evolve much so I do not expect to release updates very often (I find it striking that @dbuenzli’s example of xmlm had two releases after 2013 that were only needed due to breaking changes by the OCaml compiler). I would not care as much about not showing weekly downloads and last published date, if I could offer the self-assessment alongside.

I have another package on crates.io that was only a prototype until recently but which has been having a crazy numbers of downloads (maybe due to CI scripts for reverse dependencies).

4 Likes

@sabine you talk about opam packages, right? I consider opam and ocaml two separate things and am a bit confused what they are to do on ocaml.org.

1 Like

Both changed. Thank you.

Indeed, it’s about opam packages. The current plan here is to retire opam.ocaml.org and integrate its functionality into ocaml.org - making that a one-stop shop for everything.

4 Likes

sigh. Whenever I do such, it improves into a fine mess. I liked the subdomain a lot. And I like hyperlinks.

Is it possible to show index.mld if it is available, otherwise just show README.md? For projects where I vend both a library and an executable, the content will be very different.

For example, the README for GitHub - diskuv/diskuvbox: Basic, cross-platform set of commands to manipulate and query the file system, and OCaml library. goes into detail about installing the executable and using it for various tasks. People knowing nothing about OCaml can use it. But I would expect only 5% of that to be in the package overview … no exaggeration. I’d expect to see a index.mld describing the library API. (Side-note: I haven’t written an index.mld yet because I haven’t stabilized the library API.)

3 Likes

I understand and sympathize with this sentiment, but it is factually incorrect. Churn is an inescapable dynamic in software, in every domain (even strictly algorithmic libraries, due to all sorts of incidental factors), and always has been. To the extent that any given library goes quiet for a long time, it indicates a problem more often than not. The key part is how one defines “long time” — it surely depends greatly on the domain of the library — and that’s something individual actors can decide for themselves. Taking pains to obfuscate such a useful metric because of the few exceptional libraries that manage to remain unbroken and usable N years after their latest publishing is IMO unhelpful in the present context.

6 Likes

2 concrete suggestions:

  1. allow url like https://ocaml.org/p/ppxlib.0.26.0 (could be simply a redirect to https://ocaml.org/p/ppxlib/0.26.0)
  2. it would be nice to be able to view the publish date for each version when selecting the version to see. e.g. adding publish date for each entry in this list:

1 premature idea:

  • it would be a good idea to have a “security advisories” section, but I have no concrete idea about how this should/could be implemented
2 Likes

Include last published as a relevant metric unless the package’s version is bumped to 1.0.0.or above If people are happy with the state of their software, they should just set it to 1.0.0 to make a certain ripeness visible. Otherwise I think the last published is a very relevant metric. Certain software I do not trust if it hasn’t been touched in years.

2 Likes

As a package author I prefer to use the README.md as the content of the landing page. That way I have 1 main place to keep up to date and it is consistent between GitLab/GitHub and the docs site. We could use better tooling around executable Markdown files, mdx is great but has limitations when integrating with CI/odoc/source code. Additionally I could imagine using an index.mld to generate a suitable README.md and landing page for the docs.

I really like the crates.io package documentation eg https://crates.io/crates/tokio. It clearly shows what the project is, gives an overview, plus links for API documentation and tutorials. I would prefer it didn’t mention the last published metadata, I agree with @dbuenzli it is a poor proxy for the question “Is this project maintained?” “Is it established enough to rely on?”. For me the reverse dependencies count gives some of the popularity information but nothing about whether it is maintained. The current ocaml.org documentation site feels like it uses more blank space when showing the same information as crates.io, which I don’t personally like. The use of categories is interesting, we have tags in opam files that could be used for that but are not commonly used.

The area available for dependencies / reverse dependencies is a bit squashed, if I’m looking for that information I’d like to see everything and not have to scroll. Perhaps a tab or some other UI element is more suitable, and the main page could just show a count or some other summary.

4 Likes

I think this is a great idea. crates.io has a great link to “Try on Rust Playgrounds” that could be a really nice way to try out a package.

3 Likes

To echo the pro-.mld crowd, my index.mld files are where I lay out how to use my libraries and point to the API, examples, etc. The readme usually only gives a brief blurb about the library itself before sections linking to the generated docs and detailing other logistical concerns which I don’t think are as useful to have on a splash page for the package.

1 Like

I see people arguing for readme vs .mld files. Why not both? I would suggest looking at my earlier comment again: preview of the readme in a collapsed, expandable section at the top, followed by the top level docs of the package. If it has a top-level .mld file, that will be part of the odoc-generated output anyway.

3 Likes

Oh no, I actually meant to talk about “testable examples” :slight_smile:

As a documentation tool, see here: Testable Examples in Go - The Go Programming Language

You can see one in action on the redis package doc linked by @yawaramin.

Runnable examples are the icing on the cake though :wink:

See the documented function “Handle” from golang’s http library here: http package - net/http - Go Packages

But may require infrastructure which seems less reachable than obtaining testable examples AKA doctests first

1 Like

BTW is there a way to generate a badge (like almost every other package repository does) for an OPAM package that you can put in your README file? If not yet, I personally think it would be a great feature.

2 Likes

The problem is that, in the current state of affairs you will likely get redundant information and irrelevant contextual information. I’d rather have that as a separate link.

Having a lot of published packages (~40) I faced quite early the problem of redundant information to specify and can’t afford spending time on churn – which is only concomitant to the software practice if you decide to accept it. Just to give an idea these “oh it’s just five minutes of your time on your package” become 3h of soulless work for me.

So in the scheme I designed for topkg’s release process, later reused by dune-release. The idea was the following, if you don’t specify an opam synopsis and/or description yourself it is derived from your README as follows (atx headings or asciidoc are also supported):

$(NAME) $(SEP) $(SYNOPSIS)
--------------------------

$(DESCRIPTION)

# First header of any level

Now that works very well for opam.

However the thing is that in $(DESCRIPTION) may want to link in your package docset. This desire extends more generally if you try to use your README as your documentation (personally I don’t think that’s the place, simply have a link to your package docset in there).

The problem is that you can’t make this to work both on github and other documentation generation context – and I urge people to devise their docs so that are perusable in any documentation context, for reasons that go from offline perusal (e.g. air-gapped settings, retreats, etc.), to accessibility, to the possibility of having docset generated locally only for those package you use in your project, etc.

Since I couldn’t reuse $(DESCRIPTION) in my .mld, most of my index.mld start with slightly tweaked versions of $(DESCRIPTION) – I may try in the future to be more subtle about that but on the other hand since in index.mld the OCaml context is established there’s stuff like “this is an OCaml package” that would feel redundant.

I ended up having that little redudancy which you can witness for example in brr where the readme preamble is sligthly tweaked to this in brr’s index.mld with links in the docset. Having both README and index.mld here would just result in stuttering on the package page.

So I would rather suggest to have this (which is almost what odig has been doing for the past six years, I could tweak it to match it):

If there is an index.mld file, just use that. If not then use the opam description (which as a package publisher you can derive from your README, see above) followed with one section per library containing an automatically generated module index ({!modules:} directive) – ideally we would have a {!library-modules lib} directive but since that concept doesn’t exist in the toolchain we are left with hacks for now.

4 Likes

Having a structured way of signalling the expected maintenance structure of a package would be a good use of opam package metadata. I can imagine one field serving multiple purposes:

  • on publish, for the maintainer to signal the expected maturity of a particular release (from mature to alpha).
  • upon subsequent breakage, for the opam repository (or other) maintainers to modify the metadata for a released package to indicate that external changes (such as a compiler release) means that it needs maintainence, even if the original releaser has since dropped off the radar.
  • for sole-maintainer packages, signal the need for additional maintainers, and that they are (or are not) welcome to apply.
4 Likes

Is a little stuttering really that bad? If you take a look at my earlier link–most of the readme is actually hidden in a collapsed section. Scrolling past it will take like one swipe. Most people would likely read the top summary and then use the left navigation panel to jump to the section they’re interested in.

I am thinking the simpler we keep things, the easier it is to get something working out the door, then it can be iterated later.

1 Like

Yes.

Not sure what you found complicated in my proposal. This has been implemented in odig for ages.

1 Like

I’ve seen some GitHub README badges that indicate the percentage of the codebase that is documented. I’ve heard people complain that many OCaml libraries lack documentation besides type signatures. Could there be a way to display “percent documented” on the package page to incentivize people to document their APIs?

4 Likes