How to count how many registered packages of Julia exists?

Hello, for some info about Julia I would like to know how many registered packages of Julia are out there.
https://pkg.julialang.org/ seems dead (“Last updated 2018-08-05”)

How can I know how many total registered packages of Julia exists? What about be version compatibility ?

Counting rows in https://github.com/JuliaRegistries/General/blob/master/Registry.toml ?

1 Like

Yes, that should be a good number.

Let Julia count:

julia> using HTTP

julia> p = String(HTTP.request("GET", "https://raw.githubusercontent.com/JuliaRegistries/General/master/Registry.toml").body);

julia> count(s -> occursin("{ name", s), split(p, '\n'))
2484
8 Likes

A better question would be, how many packages are installable for Julia v1. That would be 1,617 packages + stdlib. This assumes that every installable package does compile and makes no assumption if it production ready or works as intended. I am developing the code to automatically fork projects, get release branch and trigger Travis to get the reports à la PkgEval. Why are there less packages installable than registered? A few reasons include those haven’t been updated to be compatible, dependencies broke it, repository has been made private or deleted, a release has been made not installable, etc.

See JuliaEcosystem for a quick app.

It is required to fork the project and trigger Travis. Most of the project already have a Travis/AppVeyor badge in their README.md. Can’t you parse the README file, get the travis badge location and then decide whether it is installable in Julia v1?

The badge is usually not a CRON job and just means that the master (dev not release) or the latest release passed all tests at that point in time… This is now a standard at the time of registering a release to General (Github checks). Basically, before a release is made installable it is checked that it works. It doesn’t tell you whether the package is working after it was checked and that release merged. For example, some dependency changed and breaks your package or the API the package interacts with made changes and no longer works as intended, etc. For installable, the script I use checks whether all dependencies are available, compatibility requirements give a feasible solution, and the repository is accessible. The next step is to actually test the package and see if it works as intended then. In Julia 0.5 - 0.6 PkgEval used to do this every so often. The NewPkgEval isn’t live yet… still working something to replace that.


A side note on parsing repo / README and such. Things like license, author, description, tags, and such are somewhat available through that process, but I advocate actually having that metadata in the actual package Project.toml.

1 Like

Thanks for clearing my doubt :slight_smile: