search

lexi-lambda / functional

Functional interfaces and datatypes for Racket
ISC License
42 stars 9 forks source link

[request] break circular dependencies #16

Closed xgqt closed 2 years ago

xgqt commented 2 years ago

functional-lib depends upon collections-lib and collections-lib depends upon functional-lib.

This is not a problem for raco but for manual installations or from another pkg manager this is a problem called circular dependencies and it (as far as I know) cannot be resolved by most pkg managers (other than raco).

Could one of functional-lib or collections-lib be split so that the libraries that they both depend upon are available as a separate package and do not cause circular dependency problems?

lexi-lambda commented 2 years ago

I don’t think this could easily be done in a backwards-compatible fashion. I think the dependency on collections-lib was, in retrospect, a mistake, but it’s too late to change it now.

As you say, raco handles circular dependencies just fine, so I don’t really think this is a problem worth spending much thought on. If there’s a concrete issue you’re running into, then I’d be more amenable to coming up with some solution, but otherwise I don’t see why it’s worth bothering.

AlexKnauth commented 2 years ago

Can it be done by creating a 3rd package that both depend on?

xgqt commented 2 years ago

Can it be done by creating a 3rd package that both depend on?

That's what I originally proposed.

Also, if new dependency is introduced the required versions of dependencies can be increased and all should remain consistent.

xgqt commented 2 years ago

If you are interested why I would like to have this resolved - I have created a package repository [1] for Gentoo (a source-based GNU/Linux distribution) [2]. The package compilation and installation is carried out the the Gentoo package manager - Portage [3] which suffers from the issue I described above.

[1] https://gitlab.com/src_prepare/racket/racket-overlay [2] https://www.gentoo.org/ [3] https://wiki.gentoo.org/wiki/Portage

lexi-lambda commented 2 years ago

Circular dependencies are already quite common in Racket documentation packages. For example, racket-doc depends on an enormous number of documentation packages that, in turn, depend on racket-doc. So these libraries are not really unusual offenders in that regard, except in the sense that they’re not just documentation.

Perhaps you don’t care about documentation packages, only implementation ones. But it’s not just documentation: even base is part of a circular dependency! base depends on racket-lib, and racket-lib depends on base. So I think any solution is necessarily going to have to either handle the circularity, or somehow treat strongly-connected components in the dependency graph as a single unit.

xgqt commented 2 years ago

But the pkgs from main-distribution are installed at once via the racket package, so there is no problem there.

treat strongly-connected components in the dependency graph as a single unit.

This is what I might have to do if I see lots of pkg authors "cause" circular dependencies.

xgqt commented 2 years ago

But the pkgs from main-distribution are installed "at once" via the racket package, so there is no problem there.

What I'm saying is that the method of installing the main Racket distribution is other than those off-distribution packages.

lexi-lambda commented 2 years ago

I understand, and I do sympathize a bit, but probably not enough to rearrange things in this case just to make Gentoo packaging a little easier. Sorry.

xgqt commented 2 years ago

I had managed to come up with a solution and it is now implemented in Collector2 (tool used to automatically generate ebuilds form Racket Catalogs).