I want to open up a discussion regarding the state of the Eco-System.
from over 1000 packages only a subset is actually useful.
Some are just plain broken since Julia is still introducing breaking changes.
Some are way under documented and thus not so useful, some are too specific to be a package.
Should there be a review process for new packages?
Related discussions:
And also
Pkg3 will bring namespaces, and we’ll likely have some kind of curated namespace for known-high-quality packages.
There are some real issues here around curation and discoverability of packages, but vetoing packages based on subjective worth isn’t the right solution, and it’s a bad route to go down. Some of those crappy packages will become the JuMP or DifferentialEquations.jl of the future, given a little encouragement.
However, some (very permissive) objective criteria could help, like removing packages from certain lists if the package has not passed unit tests for a year or more, or has not achieved some minimum level of test coverage (eg 50%). These could be automated, with advance notifications to the authors so they have time to react, etc. The point would be to remove abandonware, not to stifle work in progress.
I totally agree.
In addition:
There are a number of high quality packages that are both small, self-contained, and abstract in nature. I’ve noticed a few cases where larger packages reimplement functionalities that these small packages already include (or where literally made for). This code duplication probably stems from the fact this ecosystem is so new (e.g. I think IntervalSets.jl came after IntervalTrees.jl). But I feel like whenever one of these core packages pops up and matures a bit, package owners should reflect if they can make use of their functionalities.
This will allow us to have a slim Base and slim packages (because a bulk of the code will reside in those abstract packages).
Yeah, this is the two issues. On one hand, you need to let everything be open so that the ecosystem has a chance to evolve. But on the other hand, curated libraries where someone has made some subjective decisions about what’s useful can make a much more concise and manageable library. We need both.
I would be curious if there are a lot of libraries which are currently are outdated, but where the original authors had planned to restart post 1.0 (when they expect API stability and the general number of users to rapidly increase). Even if not, there may be people willing to take over the older libraries at that point. So having easy ways to find potentially outdated libraries is useful.
On another note, I spent a bunch of time over the last few weeks getting a sense of the ecosystem, and found it very hard to find functionality as opposed to just packages.
Kalman Filter which I expect has been re-implemented a million times - mostly poorly - and with incompatible state-space model specifications. There were a few obvious places which I had a strong prior might have the functionality, but it much harder than it had to be.To aid in this for the post-Pkg3 infrastructure, consider whether it is possible to have indexing of functionality below the level of package and its keywords? Maybe it is possible to have a bot to index docstrings in the repository, which could be used by a general package search engine from within the “curated” list? That way, if someone writes: "Algorithm taken from: Laub, “A Schur Method for Solving Algebraic Riccati Equations”, as in https://github.com/JuliaControl/ControlSystems.jl/blob/0ecafbcc8c05a87c98f7d5b55cb4368d9ecbd10e/src/matrix_comps.jl, someone searching would finding it for “Riccati” or Laub.
Nothing too elaborate is necessary, but would help make reusable code easier to find, and encourage loosely coupled packages rather than monolithic ones with repetition.
One way I like to search is through the big orgs. For example, for statistics I just go straight to JuliaStats and search there. Of course there’s good stuff not in orgs, but usually (the big) orgs have a testing and maintenance structure that keeps packages alive, while random single author packages tend to also be single maintainer (and single tester).
FastGaussianQuadrature.jl or just use ApproxFun.jl? This is a good example of something that gets asked a lot but seems hard to find I guess.
@ChrisRackauckas Thanks!
One way I like to search is through the big orgs. For example, for statistics I just go straight to JuliaStats and search there. Of course there’s good stuff not in orgs, but usually (the big) orgs have a testing and maintenance structure that keeps packages alive, while random single author packages tend to also be single maintainer (and single tester).
Thanks. The problem is that github doesn’t support (or I can’t figure out!) how to search code within an organization rather than searching in the repository itself. Maybe I just missed it. I ended up code searching in
FastGaussianQuadrature.jl or just use ApproxFun.jl? This is a good example of something that gets asked a lot but seems hard to find I guess.
Thanks. I didn’t find FastGaussianQuadrature.jl which is more directly focused on what I was getting at. I did figure out ApproxFun, but that was a perfect example of having a strong suspicion to look there because I knew about chebfun and suspected they would have to implement it internally… Too much knowledge required.
JuliaObserver.com
I didn’t know about this! If it is indexing the whole repositories, rather than just the README.md, then expanding, publicizing, and making it semi-official would really help people find packages.
If you go to the org main page and search, it’ll search all repos of an org.
I really do think it should be at least semi-official.
I think this should be no surprising, as time goes on, some packages will survive and become mainstream while the others will not. When I first started using R many years ago, I have to use a lot of different packages for a single project, but now my choice of tools have been quite narrowed down.
In addition, Julia has been incorporating some new features, some packages may not be updated at the same pace.