We just hit 7000 packages (it’s IsotopicCalc.jl) and 49 more waiting in the package pipeline. Would be good to get relevant sites updated, Julialang.org, JuliaComputing.com; and Modulecounts.com which shows a blank line plus “0/day”.
9 Likes
Package 8000 is:
A 1000 new packages from one JuliaCon to the next is great!
one intriguing registered recently:
It would be interesting to have a bit of stats regarding these 8000 packages. How many are still maintained? How many are compatible with the last Julia version? How many are working on all platforms? How many of them are really used?..etc
Personally, I 'd rather have 10 high quality packages than 1000 poor quality packages hence the reason of having a bit of stats on the julia package ecosystem would be interesting…
9 Likes
I agree with this sentiment, and this idea was mentioned earlier in this thread. But how would be such a thing?
Some interesting facts I would like to see about each package would be the following:
Metric: Quantity
Active: Time of latest commit
It would be pretty cool to see a histogram of all the packages with respect to their time of latest commit. I’d probably expect a flipped bell curve. Not sure tho.
Impact: Number of packages that depend on this package (caveat this discounts user facing packages)
Reliance: Number of packages it depends on
If we are looking at the outneighbors of a package might as well look at the inneighbors, seems like an interesting metric (maybe not particulary useful tho)
idkwhattocallthis: Ratio of open PRs to open Issues (like a contribution to complain ratio?) I think this ratio can provide a bit of information on “activity” as well
Popularity: Stars on Github (this is to account for mature, but inactive packages like Calculus.jl, and also accounts for user facing packages. End users are more likely to star the direct package they are using than a lower level dependency.)
So I think overall the metric usefulness can be a function of impact and popularity
The metric activity could be a function of active and the “PR to issue” ratio.
And what will happen when we reach the 500.000 packages? Will they all still be in regestries\General? Now General.tar.gz~4.8 MB but the dir expands to ~28.800 files and 190 MB. Still manageable but is this going to be multipliable by 10, by 100?
the good news is that the tarball doesn’t need to be expanded, and at long as Julia doesn’t grow significantly faster than Moore’s law, we’ll be fine.
But it is expanded.
Not by default from Julia 1.7. If you are using Julia 1.7 or later and have an unpacked registry and don’t want that, just remove it, e.g. with
using Pkg
Pkg.Registry.rm("General")
Yes, I have Julia 1.7 (and aboves). But what that did was to remove the tar ball and left the directory, which is marked with an icon by turtoisegit meaning that is being version controlled.
Well, do Registry.rm twice in that case. There are three possible registry representations; git clone, unpacked tarball, and tarball. Apparently you had both of the first two at once.
1 Like
OK, running it twice deleted everything but a posterior ] up brought back that tarball only. Let’s see how it behaves.
Thanks.
1 Like
For some more numerology, Julia’s number of GitHub stars hit 40 K today. It was displayed as 39.9 K yesterday, but now it’s at 39.95 K and gets rounded up to 40 K in the display.
4 Likes
Julia has now over 900 packages registered, and package nr. 9000 is @ChrisRackauckas’
It (like other similar packages) seems intriguing.I THINK it does actually have nothing to do with SciML, just put under that umbrella, despite the ODEProblem example.
I don’t know much Ruby, but I still posted such code in my comment there to get the current count (using wget), can anyone help make a PR there (and maybe more idiomatic Ruby code, without wget…):
We’re up to 48% the size of the CRAN (R) package system.
We’re likely the 14th largest package ecosystem of any language, and not like we can’t use packages from others, e.g. Python.
It would be great to get modulecounts.com working again, some time ago we were fastest growing package system (according to Reddit thread). Would be interesting to know if still true. By new packages (or even new versions).
Package 9300 is HorizonsEphemeris.jl and if I recall the exiting new PrecompileTools.jl at 9296, I had to scroll through a lot of pages to find the number (i.e. over JLL packages), it’s great so see how many new versions are registered, even in just one day.
3 Likes