Add language-family support, group packages into umbrellas, and record build platforms in catalog#93
Merged
Merged
Conversation
These are new fields in "info.rkt" at the package level.
A package "P" is under umbrella package "Q" if: * "P" is "Q-lib", "Q-doc", "Q-test", or "Q-exe" * "P" declares "Q" as its `umbrella` via "info.rkt" Note that it would also make sense for "Q" to be an umbrella for "P" if "Q" `implies` "P" via "info.rkt". However, that would let "Q" adopt` "P" without necessarily having the author of "P" agree, so that's why `implies` does not create umbrellas. On the main package listing, only an umbrella package is shown by default. A turn-down arrow in the umbrella package has the contained packages listed next to it and exploses the details for all packages under the umbrella. Umbrella organization is based on the packages actually listed, which might be limited in a search result. However, "this package needs documentation" is now also sensitive to umbrellas (a package is considered documented if anything in its umbrella is documented), and that's independent of the listed packages. Umbrellas are not meant to be nested, and the display mechanism doesn't surrently support nesting beyond a single layer.
The top of the package-list page now shows the language families found for packages. Selecting a language family changes the default sort to have matching packages first, and non-matching packages get a gray background. A `langfam=<family>` query parameter can initialize the family choice. This commit also repairs umbrella groups when sorting by table columns. That involves using a newer fork of tablesorter that provides direct support for child rows.
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The backend changes here record
language-families,umbrella, andbuild-platformsfrom a package "info.rkt" so that they are reported in a catalog.The package-list display shows each package's families, and it indicates a "current language family" for the overall package listing. The default package-list sort shows packages matching the current family first, and it shows non-matching packages with a gray background.
Unrelated, but something that has long seemed like a good idea: Groups of packages that follow the
-lib,-doc,-test, and-execonvention are combined into one row, and a turn-down arrow can show rows for individual packages. Theumbrellafield of "info.rkt" allows a package to declare that it falls under an umbrella package in the case that the umbrella is not inferred. (For example, the "actor-lint-lib" package should probably declare "actor" as its umbrella package.) It would make sense to infer umbrella relationships based oninfersin "info.rkt", too, but (1) umbrellas are meant to cover things not normally implied, such as-testpackages, and (2) a package could addinfersto hide (somewhat) another package without that other package's author's consent.The package server does not itself use
build-platformsinformation. The intent is to have that information readily available to the pkg-build server by recording it in the catalog.