-lib packages still show with TODOs for docs

[jackfirth]

For a set of packages named foo, foo-lib, and foo-doc with the first implying the others, the foo and foo-doc packages don't have a TODO for docs but the foo-lib package does.

[jeapostrophe]

foo (A) gets its docs from foo-doc (B) because A implies B and B has docs.

B just has docs.

For foo-lib (C) to have docs, then C should imply A or B, right? Maybe I'm crazy?

[jackfirth]

Yes, since the catalog uses the 'implies field the foo-lib package would have to imply the foo-doc package. But that's not how a lot of packages in the catalog are currently structured, nor do I think they should be.

What about an info.rkt field that could be added to foo-lib to explicitly declare that it's documented by the foo-doc package?

[jeapostrophe]

Why do you think that foo-lib should NOT imply foo-doc? (Imply means that an update to one should update the other.)

If we're talking about changing package files anyways, then I think not introducing a new piece of data is preferred.

[jackfirth]

Because then depending on foo-lib depends on foo-doc, increasing installation times. Isn't avoiding heavyweight dependencies the reason packages are split up into -lib, -doc, and -test variants in the first place?

[jeapostrophe]

It doesn't need to depend on it to list it as implies

[jackfirth]

Currently it does, or an error is thrown when the package is installed. The docs for 'implies state "Each string refers to a package listed in deps and indicates that a dependency on the current package counts as a dependency on the named package". If that's no longer going to be true, then wouldn't we be using 'implies to mean two different things? I'd rather have a new info.rkt field with a well-defined meaning in that case.

[jeapostrophe]

'docs-from ?

'tests-from ? (We eventually want this)

Or maybe leave 'implies as-is but have the package server compute the flow in both directions?

[jackfirth]

'docs-from and 'tests-from sound like good ideas to me. I'd rather not make the 'implies link too strong because there are some packages that imply others but don't document them, typically because the implied package used to be part of the implying package and now is its own package.

[jeapostrophe]

I'm scared about that requiring too much bookkeeping and annotation for authors.

[jeapostrophe]

Let's think about it more, particularly about the package server computing in both directions option. Let's see if @mflatt @tonyg or @samth have opinions.

[SuzanneSoy]

@jackfirth had suggested [here https://gist.github.com/jackfirth/9ebfe333540ee7e244c932324ae99502] that foo, foo-lib, foo-test and foo-docs all bear the tag foo, to indicate that they are part of the same metapackage cluster.

We could also add a 'metapackage field in info.rkt, which would contain "foo" for all four packages.

I feel that the issue is that we are using 'implies as a poor man's metapackage/cluster, but 'implies can also be used with other semantics.

EDIT: A 'metapackage annotation would also help reliably hide the -lib, -test and -docs from the package list. A hidden tag on https://pkgs.racket-lang.org would also work well for this case.

[jeapostrophe]

I like the idea of 'metapackage, although I'm not totally crazy about the name.

[jackfirth]

Maybe 'subpackage-of?