Isn't it what Scheme registry was about? Documenting features provided
by each Scheme *thing* available?

To me, the distinction between packages and libraries is regrettable,
but unavoidable. A library is an abstract thing, a package is a concrete
thing.

BLAS is a library, cblas, openblas, and ATLAS are all packages that
implement BLAS.

As far as I understand, languages do not have "package managers", it is
"distributions" that have package managers. (Same abstract/concrete
opposition.)

Documenting all available *libraries* for Scheme seems a huge piece off
work, although it should be possible to get an initial list of libraries
by parsing different package repositories. But I believe that should be
very error-prone.

Documenting all *packages* seems a Sisyphean labour as they change all
the time. However, it would have been nice if it was possible to agree
upon a certain html layout, so that different scheme distributions could
export their package list into, and packages.scheme.org could fetch
those once a night, and format a single page.

On 27/01/2021 06:49, Lassi Kortela wrote:
> It would be a good time to start experimenting with the grand unified
> index of Scheme libraries/packages. It'll be a long project, so best get
> going early.
>
> First off, should that be library or package?
>
> lib.scheme.org
> libs.scheme.org
>
> pkg.scheme.org
> pkgs.scheme.org
>
> Most languages have a _package_ manager, where a package is a collection
> of libraries (+ some auxiliary files). I don't know about others, but
> I've always found this two-layer approach confusing.
>
> R6RS and R7RS only talk about libraries, which are a logical and easily
> understood unit that ties neatly into the language semantics. By
> contrast, a collection of libraries is an administrative concern. If I
> want to import library (foo bar baz), do I really need to know which
> collection it comes from? If the library comes from a particular git
> repo or tar file, can't the package manager find that collection for me
> and figure out how to extract the library that I want (as well as any
> other libraries that it depends on).
>
> Package managers need to do dependency-chasing anyway in order to
> resolve packages that depend on other packages. It shouldn't be more
> work to do that on a library level as opposed to a package level.