I made a package browsing tool called julia observer.
My goal was to make a website like ember observer, but for Julia.
Let me know what you think and feel free to leave an issue on github.
17 Likes
I’ve been looking at this now and again for a few days. ''Tis really cool and well-made. Tim Holy’s lead is unassailable, I reckon. 
Life goals. 
Really cool stuff. <20 char>
Nice! Could it also pick up unregistered Julia packages that are starred?
(it could at least look for packages that end in .jl, as that is the convention for Julia packages, even if they are not yet registered)
I’m completely open to this, I just want to know the use case.
Would people really want access to unregistered packages?
For example, I’ve got 16 stars on my https://github.com/ScottPJones/StringUtils.jl package, which is unregistered.
There are a number of other useful packages out there that I’ve used, which are not registered.
We used for a long time @johnmyleswhite’s https://github.com/johnmyleswhite/Benchmarks.jl package, which has 48 stars (which would mean that it would be ranked around 105 out of almost 1300 Julia packages by Juliaobserver, if it had been included)
(it has now been superceded by the registered GitHub - JuliaCI/BenchmarkTools.jl: A benchmarking framework for the Julia language package, but that has only gathered 39 stars so far).
Often packages are unregistered while they are still “WIP”, but they can still be quite useful, if you can find them.
I think it makes sense to limit to METADATA packages. Or at least have a toggle to enable / disable non METADATA packages.
4 Likes
It would be interesting to see whether registered packages are the majority, or just the tip of the iceberg…
1 Like
I think there are a lot of different metrics that can be used to rank Julia packages, both registered and unregistered, that would be nice to be able to see in Juliaobserver (I’ve been having a great time using it!).
It already has a few ways, by the # of stars, by newness, sorted alphabetically, and “hotness” (I’m not sure what the criteria are yet for that one!).
Just because a package is registered, doesn’t mean that it even works anymore with the current release (or with master), so one metric might be whether the package has been updated since the current release came out (or since the first RC of the current release came out), or if the current release is less than a couple months old, the previous release.
I do know there are quite a few useful unregistered packages out there, and Juliaobserver seems to be a wonderful tool for package discovery, so it would be good IMO if those were also included, no matter whether they are the majority or not.
How bout I make a toggle in the navbar’s dropdown?
Then store the boolean in a cookie that’s used to show/hide unregistered packages
edit: maybe drop a line in issue#5
it’s up to you guys to determine if the cookie should start by showing/hiding them
The tool is really useful for discovery. Thanks!
2 Likes
I seem to have run into a bug. I typed something into the search field and viewed the results… after wards I erased the search word and clicked on the ‘NEW’ button and the search word appeared again in the search field I tried the same with the other buttons and the same word keeps appearing preventing me from using the interface.
The only way i found to make it function properly is to select a category from the right side.
Good work, though.
@TravisA9, thanks for finding this!
Could you file it as an issue on github?
edit: also, i think it’s working as expected.
- when you search something, you’re making a server request (i.e. when you press enter)
- when you erase the search query, you’re doing it client-side (i.e. just on your laptop)
client side updates don’t go to the server (unless you click enter).
when you click “New”, “Top”, “A-Z”, or “Hot”, you’re making another server request with w/e query was attached to the current page.
i agree that I could link the 2 forms, but I think that’s just as confusing.
A better solution would be to inform the user that there’s a query present and give them a way to remove it (for example, a big red X)
// sorry for the wall of text. i usually save this for github
Oh my god this is so awesome!
Something that is not explained and I have a question about: How are the categories made?
Another edit: I am asking to understand on which category will my package be (DynamicalBilliards)
1 Like
Fair question.
Right now they are made purely from organizations that have:
- published Julia repos
- Julia in their name
After we got some more users, I wanted to get community feedback on how best to generate and populate categories.
Sorry if this is an inadequate answer 
Also, feel free to post an issue to get the ball rolling.
// edit: as @FemtoTrader pointed out, maybe topics are the way to solve this: pkg topics
I concur!
The new system of topics that Github offers would aid greatly in categorizing packages.
Just a heads up…
You can now view unregistered packages from github, as per issue#5
Please let me know what you think and don’t forget to file any issues you find
to view unregistered packages,
- click dropdown in navbar
- select settings
- click checkbox with “Include Unregistered Packages” next to it
- click “Save changes”
tada, you can now view almost all 3000+ living Julia packages.
4 Likes
Really cool site. Do you have access the amount of Downloads? I think it would be a nice information to share. Something like these Atom packages have, here one as an example: linter-julia See the cloud symbol with arrow down in the right upper corner.