Thanks! I was not aware of this.
I think one issue here is how one defines "production ready". I wrote and use
struct-plus-plus extensively in my code. I'm aware of one other person who has used it, although I don't know how much or for what. Is this module 'production ready'?
Likewise, I am of the opinion that "when is the last time it was updated" is the wrong question. IMO, a module should cover its core use case and have tests and documentation. Once that's done, it should only be modified (A) for (bug | security | documentation) fixes or (B) when someone comes up with a genuinely new and useful feature. It's a bad idea to continuously twiddle the code in trivial ways simply to make it look more appealing to people who are using "has this been modified multiple times over the last N weeks" as a metric.
I feel the same, when I look at Python's list of libraries:
It takes a while to get used to a new eco system. That doesn't mean we can't improve of things - but any large project will take some time to get used to.
Since the line between language and library is blurred (non-existant?) in Racket, it might be harder than usual to see what's "standard" and what's "third party". To some degree that's the point: An Racket user has, due to the module and macro system, just as most power to tweek the language as the "language developers" have.
The best advice (repeated from above) is to search your local documentation first and then compare with the online one. I like to use the online documentation - sometimes you find just the package you need.
I think if you are doing that, you have much bigger problems than whether your code is production ready or not
By production ready I mean more along the lines of is it used in production and by who.
I remember looking for something about base64 https://docs.racket-lang.org/search/index.html?q=base64 It's difficult to realize which one is the official one. (probably the one from net/base64 ?) Perhaps add a "verified" checkmark next to the main distribution package? Perhaps be able to select to show "only-main-distribution" or "all-available-packages"?
Yeah, I thought I must not be the only person who has run into this - thanks
That was exactly my point. Using "has this been modified recently" as a metric for quality is a mistake. Likewise, twiddling your code in order to attract the gaze of people using "has this been modified recently" as a metric is also a mistake.
Why would you say 'production ready' if what you mean is 'in production'? Anyway, that pushes the question back a level: what's your definition of 'in production'? If I've written a Racket module that automates something on my local system, is that 'in production'? Does it count if I've shared it to a bunch of friends and they all use it? Does it only count if it's in use at a company? Does the size of the company matter?
I'm not trying to be difficult here, I'm trying to point out that you're asking the wrong questions. Lisp in general and Racket in particular has very little commercial presence, so if you want code that is in daily use at a major business, you're not going to find it here. If what you want is code that has a thorough test suite, thorough documentation, and general approval from the community then we can help you with that.
Insert Twitter joke here. :>
To slightly hijack, I can imagine a process for "graduating" into the inner rings. For some of the "pet"/"my-missing-functionality" libraries, I would imagine that process centered around making sure the added functionality interacts well with existing functionality in said inner ring. This would be useful for pushing some of the non-core "add missing functionality" libraries into racket itself, and/or having a list of "does not blend with X Y Z"
We are not trying to prove a mathematical theorem here so we do not need to be formal and too precise. I think software engineers generally agree on what is production ready - it is something that has come out of beta and is considered mature to be used in production by anyone. Sure, you can advertise your pet/hobby project (which is not ready) as production ready and people will try to use it and it will quickly be shown to be otherwise so that is on you. If a project is already being used by another (larger) project - well, it is already in production (and hence production ready). Yes, these are not precise/exact definitions but for me they suffice.
As for the second portion of the reply that there is little commercial presence - I get that - but on the other hand, I see all this work/time being spent on Racket and I cannot help but think that there is hope that the language would become more popular and used of things other than just academic experiments. I see languages like Scala that go from 0 to 100 in a few years and people are talking about them as if they are really something original or new and they get hyped up and adopt a serious following - so much so that the concept of a monad becomes an interview question that separates the wheat from the chaff and I cannot help but wonder - why can't racket be that language?
Finally, you go to the Racket docs website and you cannot really tell what's what - sometimes there are multiple implementations of the same functionality - how does one discern which one to use? They are all up there pretending they are at the same level of development and almost implying that they are "officially sanctioned" (whatever that means)
It seems like your personal definition is fairly balanced, so that's good to see.
The Racket ecosystem fairs better on these fronts. Most projects preserve a stable API for the long term. A large API change is typically done by creating an entirely new project. Most projects only use a few dependencies. The 2013 talk about the package system from @jeapostrophe is helpful context towards understanding the ecosystem's approach to stability. With all of this taken together, it's far easier for Racket projects to truly reach completion and live on successfully without needing further updates.
Assuming this is true - then the maturity/what to choose as a library is a presentation/organization problem, true? Which is kind of where I started when I asked this question - I am having trouble discerning (from the racket docs website) what is official, what is not, what is ready, what is not...
I have a very simple rule of thumb. If it is in the Racket distribution downloadable from https://download.racket-lang.org/ it is official and ready. This includes many languages, a good IDE, the web server, GUI/graphics framework, network libraries and much much more.
It is important to note that everything in the distribution has had extensive testing and apart from new features mentioned in the release announcement and months or years of real-world use.
If you have to use
raco pkg install <package-name> you should check the package to be sure it is something you are happy to install and use.
I’ll give an example. You can check 1d6 - you might be happy to use it for some dice rolling but as it lacks licence metadata you would want to check the LICENCE file before integrating it into your project.
Racket is different to some other languages in that you don’t just install the language, you get a huge set of libraries and tools and at least seven languages (probably more). I’m guessing this is necessary because university IT departments don’t like students (or professors ) installing software on lab computers, so the Racket distribution has to include everything they might need for anything from an introduction to programming class to a higher level course in programming language design & implementation.
I hope this helps,
A partial implementation of the Troll dice-rolling language in Racket.
Build status: ok passing tests missing license metadata
I have a PR that largely fixes this issue: https://github.com/racket/racket/pull/4510
Feedback is welcome.
I'm not sure if here is better to discuss or on the PR, but what is the precise criteria that lifts one package above another one in the pull request?
The PR might be better.
But to answer your question:
All search results are sorted according to their score. E.g., exact matches come before prefix matches. Prefix matches come before partial matches. (this behavior already exists in the current search)
Among search results with the same score, they are sorted according to the package status. Those from base come before those from main-distribution. Those from main-distribution come before everything else.
For equal score and equal package status, the original order from the current search is preserved (which IIUC follows lexicographic order, but I'm not totally sure).
Thanks. The reason I thought of raising it here is that giving precedence to some packages over others might be a contentious subject. But it is definitely the case that we're already doing that with main-distribution and, while I'd like to see us move away from emphasizing main-distribution, this change does seem more helpful than anything!
I'm a bit late to this thread, but, Jay, I thought Ring 0 was conceived (by you?) as broader than just the package
"main-distribution" and its transitive dependencies. In that documentation, 11 Future Plans says:
The official catalog server will divide packages into three categories: ring-0, ring-1, and ring-2. The definitions for these categories are:
- ring-2 — No restrictions.
- ring-1 — Must not conflict any package in ring-1 or ring-0.
- ring-0 — Must not conflict any package in ring-1 or ring-0. Must have documentation and tests. The author must be responsive about fixing regressions against changes in Racket, etc.
These categories will be curated by PLT.
Our goal is for all packages to be in ring-1, with ring-2 as a temporary place while the curators work with the authors of conflicting packages to determine how modules should be renamed for unity.
In contrast, the ring-0 category will be a special category that authors may apply for. Admission requires a code audit and implies a "stamp of approval" from PLT. In the future, packages in this category will have more benefits, such as automatic regression testing on DrDr, testing during releases, provided binaries, and advertisement during installation.
I like that definition of Ring 0 better than
I wrote some thoughts about
"main-distribution" relatively recently in two Github comments:
A lot of Racketeers believe, and the design of the package system tries to ensure, that
main-distributionis not and should not be special: it is just some Racket package, and
distro-buildcan be used to make a Racket distribution with any package or set of packages. This is usually my view, so obviously I find the reasoning persuasive. The main distribution includes a lot of things that are deprecated, and other things for historical or idiosyncratic reasons: because they were there before the package system existed, or, say, libraries for various textbooks, to simplify the first-day-of-class experience for students. It doesn't include some packages I consider gems of the Racket ecosystem, like Gregor or the S-expression syntax for
However, from another perspective,
main-distributionis special: it's what novice students will download, it's what distribution packages provide, and the examples on the https://racket-lang.org home page need it to run.
It's also worth noting that independently-developed packages like https://github.com/Metaxal/quickscript and https://github.com/RenaissanceBug/racket-cookies can later be adopted into the main distribution, while https://github.com/racket/raco-cross can be developed under the
racketorganization without going in the main distribution, and the documentation can point to independently-developed packages, as the documentation for
racket/datedoes with https://github.com/97jaz/gregor/.
Overall, I think the underlying concepts are sound, but the landing page at https://docs.racket-lang.org could certainly use more organization along several dimensions. I'd also be in favor for some sort of process for nominating trusted packages to Ring 0.
Not speaking for the other release managers, but from my point of view, I would think that, if ring-0 (as described above) were something that were working and we were all used to, we should probably distribute the ring-0 pacakges the way we're currently distributing main-distribution (i.e., we keep ring-0 and "what gets distributed" always meaning the same thing, via some mechanism, perhaps via a package called
ring-0 instead of one called
If that does seem like a goal we might head towards, we should probably revisit the definition of ring-0 from the view point of the release process steps and see if we need any additional requirements on it to make sure releases run smoothly (specifically, we'll need folks to be responsive at release time for each package to do various checks and participate in various discussions). Or if we feel like something along those lines is good, but ring-0 would have too much stuff, we might also want to do something to be more selective, too.
I'm on board with these suggestions, especially insofar as they foster a sense of ownership of the project among a larger set of community members.