Actually, that’s already in place for JuliaPro users.
1 Like
It sort of is, but I don’t know that the selection criteria have been published, nor whether there are any guarantees/statements of code quality that have been made about the included packages.
In any case, the Pkg system is flexible enough to handle all of these use cases. To date, we have not really needed to stretch these muscles, but given the sudden influx of “one-function packages” in the current PR queue, we should probably start thinking about a good way of handling these.
2 Likes
I don’t know of published selection criteria either, but there is a code quality statement in their website: https://juliacomputing.com/products/juliapro
(taking “us” as Julia Computing, I suppose.)
It may be nice to have an open, curated registry as well; but I suppose it’s a matter of the balance between necessity and resources needed to maintain it. As soon as necessity overweights the effort, probably organisations or user communities will set up alternative registries - with other inclusion criteria, times for approval, restrictions to compat bounds, or whatever other aspects that somebody might dislike of the General Registry.
2 Likes
The Debian model of stable, testing, unstable, experimental is pretty useful. Things start in experimental, and then when they work for someone, they move to unstable… If they last in unstable long enough without a ton of bug reports, they move to testing. Every so often testing is converted en-mass to the new stable.
Most people I know who run Debian do so in “testing” because it gives the best mix of recent packages but not major breaking bugs every few days. Having a tiered set of repos like this might be a good idea.
2 Likes
Actually, these issues (README, test suite, documentation) could be useful. If not as strict requirements, it could be suggested in the message that the JuliaRegistrator shows.
5 Likes
This discussion has been very useful to me. I’m working on a package and thought that a README, test suite, and documentation were required and the three days wait was there so somebody would have time to look it over. I am very happy with the status quo and could easily understand if three days is increased as the workload of the people who have to look at these things goes up.
Anyhow, I will not even fantasize about trying to register my stuff until README, test suite, and documentation are in good shape and a few experts in my field have had a look. Just getting testing, CI, and documenter going as a complete novice was a good character-building experience for me.
16 Likes
As long as “Documentation” in this case is broadly construed - some packages are really useful and simple enough that their docs fit in the README - I would totally be on board with this.
Yeah, just to be clear, my intent was to make this as flexible as possible: either a good README or some integrated docs/, or both, but at minimum, a README that has sufficient documentary content. (This is subjective but as a first objective criterion we could simply check word count.)
3 Likes
One reason 3 days is not arbitary is that means in a normal week, at least 1 of those days will fall on a work day.
People who wish to keep a close eye on the registry for what ever reason, should not be expected to work weekends.
And frankly people who are keeping an eye on the registry are doing a service.
E.g. someone normally notices when people put in a problematic package name.
Like I wish someone had pointed out when we registered FDM.jl that this would not ever be found by a google search, and also that it begs confusion as there is a related but different well known family of methods commonly called FDM.
9 Likes
From @christopher-dG on the Slack GitHub - crev-dev/crev: Socially scalable Code REView and recommendation system that we desperately need. See http://github.com/crev-dev/cargo-crev for real implemenation. : Scalable, social, Code REView and recommendation system that we desperately need (language agnostic and stated plans to include Julia Pkg / General registery).
4 Likes
That link 404’s for me.
Sorry, trailing : . Should be good now.
“Stated plans” are just the fact that I started noodling around at GitHub - non-Jedi/Crev.jl a few weeks ago without making a whole lot of progress. Support is only “planned” if I or someone else pushes it through to completion.
@StefanKarpinski and @dilumaluthge seem to be open to helping out from the Slack conv. Might be cool to coordinate.
I don’t believe any of this is behind closed doors:
7 Likes
This is true. I think the reason is that we’ve avoided, as much as possible (with the exception of naming, perhaps), subjective criteria for registration.
I think the pushback you’re receiving on your two packages comes from the fact that they’re literal translations of very small NPM packages, and some of us have been campaigning for a long time against “ecosystem fragility” – you can see my (very yellow-tinted; those of you presenting from iDevices this year, remember to turn off night mode) talk at JuliaCon last year for some background on what this is and why it can be problematic. For some of us, NPM epitomizes the fragile ecosystem we’re trying to avoid.
4 Likes
Most of the time, things just tend to work until they don’t. But here we are presented with an interesting opportunity where we all generally knew what we we think a good and bad idea, but normally that was used on the author’s end to just not register things they thought weren’t registerable. Now we’re presented with a case to really look at that is somewhat on the line where people disagree.
We know that NPM’s fragility is something that we (and nobody really) want. Here is a case of leftpad style packages with not too difficult to demonstrate issues. This raises a question for us as a community: what should we do? It is fairly difficult to put a correct criteria on what package is too trivial or too low quality to register, but I think the interesting thing about this case is that probably in almost any criteria we could choose, these packages would not be allowed.
So what do we do? Well, there’s a few options:
- The package manager is “anything goes”, a free-for-all. It’s too hard to say what is good and what is bad in a black and white way, so don’t say it at all. The pro of course is that there’s no arguments about what’s allowed. The con is that we could be building towards a NPM-like problem.
- The package manager is “anything goes” but we put a strong discouragement against this kind of package. Basically, we cannot find a good criteria, so it can slide, but we encourage people to not do things like this and as a community encourage people to avoid using or depending on these kinds of packages. It’s a little bit kludgy, but it would avoid the issue of a leftpad explosion while not really have to take black and white approach since everyone could make the subjective decision themselves on where the cutoff is. The downside is that the namespace would still be polluted, but that’s not all that bad.
- We try and nail down what the right cutoff is and enforce it. This would be nice, but the cons are we need to find a good rule (which can be hard), and we need to find out who wants to spend time enforcing it (which is also hard).
Thinking about it, I kind of think that we have to go with (2): the “please don’t but okay fine… but please don’t…” approach. It’s the easiest to manage and the most decentralized while avoiding most of the issues. And there’s enough names that I don’t think we need to worry about namespace pollution all that much. Maybe it’s the right compromise.
12 Likes
Just to echo some of the side discussion in slack: I made a proposal that we come up with some objective criteria that mirror what I posted above, and then, for new packages, if the criteria aren’t met, the PR is flagged for review and automerge extended by some period of time (proposal: 7 days). If the guidelines are met, we have a 3-day expedited review.
Would just like to re-up the tiered approach… what if there were an Experimental repository where anything goes, and then an Everyday repository where things that have been in experimental long enough and get some votes go… and then a Reliable repository where stuff that is considered very high quality goes?
1 Like
Wouldn’t it help to remind ourselves of the purpose of registering packages?
I believe that it is to (a) produce a reasonable vetting of packages to guarantee a modicum of quality, and (b) facilitate the use of the package so that people can use the package manager with the least amount of typing and web browsing. (Did I forget anything?)
Adding packages by the URL already provides a very reasonable approximation of what “experimental” repository would do. I don’t see any reason for changing the current modus operandi.
EDIT: Note however that the vetting is NOT curation (curation & trust (registries are not the answer) · Issue #1856 · JuliaLang/Pkg.jl · GitHub).
3 Likes