Email list hosting service & mailing list manager

Libraries at scheme.org? Lassi Kortela (26 Jan 2021 22:49 UTC)
Re: Libraries at scheme.org? Vladimir Nikishkin (27 Jan 2021 01:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 07:27 UTC)
Re: Libraries at scheme.org? Vladimir Nikishkin (27 Jan 2021 01:34 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 07:46 UTC)
Re: Libraries at scheme.org? Arvydas Silanskas (27 Jan 2021 08:25 UTC)
Re: Libraries at scheme.org? Marc Nieper-Wi├čkirchen (27 Jan 2021 08:36 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 08:51 UTC)
Re: Libraries at scheme.org? Arvydas Silanskas (27 Jan 2021 10:34 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 13:17 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 14:07 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 16:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 17:34 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 18:09 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 19:54 UTC)
Re: Libraries at scheme.org? Lassi Kortela (29 Jan 2021 13:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 08:37 UTC)
Re: Libraries at scheme.org? Duy Nguyen (28 Jan 2021 10:29 UTC)

Re: Libraries at scheme.org? Duy Nguyen 28 Jan 2021 10:29 UTC

On Wed, Jan 27, 2021 at 7:56 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
> 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.

You may not care where library A comes from, but that library may
depend on B and only work with B versions >= 1.2.0 (perhaps it's a
bug, maybe it's some missing features...). This information has to
come from somewhere. Or we're left with frustrated users who have to
analyze the problems and chase down until they find the right version.
A similar scenario is you want a specific version of a library because
you kno some other version does not work.

Also, whatever package/library definition you come up with, please
think about ffi libraies. Things could get increasingly complicated
for ffi of large libraries (think gtk+). At least leave the door open
for ffi possibilities in the future.

PS. That ffi thing was about versioning only. I don't think we can
handle extract/install ffi libraries portably at this point.
--
Duy