# Fixing Package Fragmentation

**URL:** <https://discourse.julialang.org/t/fixing-package-fragmentation/98712>\
**Category:** Community\
**Created:** [May 12, 2023, 2:13am UTC](https://discourse.julialang.org/t/fixing-package-fragmentation/98712 "2023-05-12T02:13:26Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [May 12, 2023, 2:13am UTC](https://discourse.julialang.org/t/fixing-package-fragmentation/98712/1 "2023-05-12T02:13:26Z")

</div>

Taken from a Slack discussion:

> I’ve had colleagues comment that fragmentation is currently the only really bad thing of the Julia ecosystem. They miss the numpy/scipy monolithic approach.

> Now for most package ecosystems the bus factor probably follows some kind of power law, but the vibe I get with Julia is that the relationship between bus factor and popularity (and package complexity, cf. NPM micro-packages) is a lot weaker

> I do think one actionable thing might be to more loudly mark certain packages as legacy / unmaintained. some of these “15 competing standards” for various niches haven’t really been updated in years, but they still add to the cognitive overhead when googling “julia package for X”

> I thought about that, and what tools do we have beyond archiving GitHub repos / modifying readmes with big warnings? Can we add deprecation warnings to the General Registry?

> I feel like we almost need a “Consolidation czar” for Julia whose job is just to set standard packages and merge ones that do the same thing

> Maybe a good first step towards consolidation would be a slightly higher bar for registering packages. And if one of the maintainers of overlapping packages says “good idea, let’s add it to my package” the registration would be put on hold [temporarily].

> Sometimes it’s hard to impossible to understand what’s different between similar packages. I had to make a few issues at different packages, sometimes got no answer at all ([Difference from other packages · Issue #10 · qntwrsm/ProximalMethods.jl · GitHub](https://github.com/qntwrsm/ProximalMethods.jl/issues/10) and [Differences from StructArrays · Issue #8 · m-wells/LazyTables.jl · GitHub](https://github.com/m-wells/LazyTables.jl/issues/8)), sometimes got some response but still not totally clear ([Differences from StructArrays · Issue #106 · JuliaData/TypedTables.jl · GitHub](https://github.com/JuliaData/TypedTables.jl/issues/106)).

> Yeah, thats annoying and dissipates work effort.

> Besides that problem, there’s the related problem of “Tiny packages that should be in base.” Why is InvertedIndices not in Base

So I thought I’d create a thread for proposals on fixing [this problem.](http://www.winestockwebdesign.com/Essays/Lisp_Curse.html)

---

_[View the full topic](https://discourse.julialang.org/t/fixing-package-fragmentation/98712)._