Raku
modules.raku.org should be deprecated
One of the older Raku websites, is https://modules.raku.org. Started in 2009, it is based on Perl and Mojolicious, for the simple reason that Raku was not capable of providing the necessary functionality then.
In the past year, it has basically not been maintained at all. But before that, maintenance was already pretty minimal, and mostly because of the name change.
Since early 2021, https://raku.land has been serving the need to be looking at the Raku module ecosystem very well, and has now become the de-facto place to get informed about modules in the Raku ecosystem.
It feels like it is therefore time to put the modules.raku.org web site to rest, and to make referrals to https://raku.land the official way of referring to Raku modules.
I think that 'raku.land' is very nice to work with and that the older one, 'modules.raku.org', can be removed.
I like the domain name:
https://modules.raku.org/
It's a quick edit away from https://raku.org/ and the "modules" prefix tells you what you'll find there.
How to re-direct "raku.land" content so it propagates to the https://modules.raku.org/ domain?
I think we'd first want to do it the other way around: redirect modules.raku.org traffic to raku.land ?
I think we'd first want to do it the other way around: redirect modules.raku.org traffic to raku.land ?
Why? If modules.raku.org is the designated domain name for our module search (and I'd personally like that as the name is much more descriptive and it's part of the "official" raku.org thing) all we'd have to do is take down the current app, point the domain at the server that runs raku.land and redirect from raku.land to modules.raku.org.
The current app is a. still under development, and b. the person responsible for it, might not want to give up on it?
Clarification: I wasn't suggesting abandoning or transitioning away from https://raku.land/ , but rather "saturating the market" so that users landing on https://modules.raku.org/ would see https://raku.land/ content.
(That, and I like the modules.raku.org domain name).
So if we rename to r.l to m.r.o we'd need another set of redirects to redirect old m.r.o content to it's location on r.l (which would now be m.r.o). To that end we might want to wait until r.l has feature parity, things like source code viewing it doesn't yet do.
As for the name, I find the confusion around modules vs distributions vs libraries a little confusing. I went will calling them dists on r.l as it was my understanding that a dist contains multiple modules/libraries, but I might have that completely wrong.
If nothing else I do intend to add more features to r.l since there's been an uptick in feature requests, but as with everything, there's only so much tuits on the world. PRs would be gladly welcome! I plan to add author search soonish. And a recent request for dark mode shouldn't be too tricky, even with my poor art skills (actually that's a place where I would appreciate any help, just needs someone to suggest a palette).
Also I'd like to hear what @jjatria thinks as he's the co-creator of Raku Land.
I'd also note that metacpan never inherited the branding/name of cpan when it replaced it, redirects were just setup and that was a long time after it became a suitable replacement.
I welcome the community embracing our work in raku.land and join in on the effort. I think both @JRaspass and I agree that the aim of the project was always to support at least all the (good) features in modules.raku.org, so we'll be happy to get to that point. I think any deprecation of the old site should probably use that as a milestone.
As far as the domain goes, I've never been a fan of modules.raku.org, to be honest. It feels long and, as I understand it, a little misleading since it has never hosted anything that indexes modules: both the existing site and raku.land index distributions (although we have thought about how to index individual modules, a little like MetaCPAN does).
I'm also not entirely sure we need the directory to live under the language's domain. Off the top of my head, the only languages I can think that do it are Go, Haskell, and R, but they're in the minority: Rust, Node, Perl, Python, Ruby, PHP, TeX, Swift... they all have their directories in some other domain, and I think I for one like this model: it means that if / when a better version comes up the change is transparent in the URL (= since the domain changed, it communicates that the site is different).
I would personally vote for making modules.raku.org redirect to raku.land, maybe with some deprecation notice, and we can change it to point instead to $fancy-new-site.$tld when that one comes around.
As I was checking the modules.raku.org website for pointers regarding how it works, I noticed for the first time that it was a much better site I assumed it was, and especially with regards to being "the official thing" of the Raku community - which I think is seriously lacking in raku.land.
In the past year, it has basically not been maintained at all. But before that, maintenance was already pretty minimal, and mostly because of the name change.
Now that I'm re-reading this issue, it points out exactly what I feared while looking at the content: the site was drastically abandoned during the changes in 2019.
I might be too optimistic but I see no reason why the Todo, the Most Wanted page or the Citation page couldn't be revived in some form. In particular, the Citation index seems so great, I never knew there was something like that. It doesn't only look awesome but it's very intuitive feedback on the status of the ecosystem both to developers and potential users. I wonder what Richard Hainsworth thinks about it. If there is no technical barrier and nobody wants to continue it, I am willing to take over it, I consider it A tier marketing/management content.
I haven't checked all the sites @jjatria linked but it's interesting to see how it aligns with what I wanted to say before checking this issue again. raku.land is like npmjs.org, in the sense that by design, it seems somewhat distant from the underlying language. modules.raku.org seemed like an official site for Raku modules, and I like this approach - actually, this is the approach of 2 of the listed 3 languages having their package registry frontend on their own domain. I think the Go site does this really well but even the Rust site which lives in its own domain can be a good example of what I miss from raku.land currently.
Other than the Todo, the things that you mention are not really part of modules.raku.org: the citation page is a link to an external Github Page, and the Most Wanted is a link to a document hosted in Github itself. As for the to-do, which of the features mentioned there are particularly interesting?
Would you be able to explain a little more in detail what you mean by raku.land being "somewhat distant from the underlying language [by design]", in opposition to modules.raku.org? A lot of the design decisions that have gone into raku.land (like the separation between distributions and modules, and the way that auth is managed, etc) are very much because of the language it targets: they wouldn't make much sense if this were not a site for Raku.
I don't think there's anything wrong with the modules.raku.org site itself, apart from the fact that it's not written in Raku and that it's largely unmaintained and difficult to revive (in part because of the first point). Well, and I guess the search bar is a little frustrating...
The language choice might seem cosmetic, and in most cases it would be, but in this one I think Raku would greatly benefit from being dogfooded.
More generally, if you can be more explicit about the things you miss from raku.land, I am pretty sure you won't see any blockers from us.
First off, I definitely agree that dogfooding in this case is very much desirable. I think the general points made by @lizmat were very accurate and overall it's a good idea to "give the upper hand" to raku.land. I just realized that modules.raku.org actually had positives that I would miss if a redirection happened today.
Other than the Todo, the things that you mention are not really part of modules.raku.org: the citation page is a link to an external Github Page, and the Most Wanted is a link to a document hosted in Github itself.
That's right but I think it's much more important where they appear than where they are hosted. Without checking modules.raku.org, I wouldn't have an idea these things can exist, and I do think they improve the cohesion within the community. They are both useful and appealing.
Would you be able to explain a little more in detail what you mean by raku.land being "somewhat distant from the underlying language [by design]", in opposition to modules.raku.org?
I think if you check the Go site as opposed to the Npm registry (which I'm not even comfortable calling "the Node site"), you will have a lot of pointers. The Go site has a complete header and footer all about Go itself and the visuals shout "this is a dedicated and official Go site". The Npm site is also really nice but it barely mentions Javascript, let alone Node.js. The Npm registry 1. assumes you know JS and Node in and out 2. tries to be a brand on its own. To some extent, this holds for Packagist, PyPI and even CPAN, crates.io being the counterexample: it communicates that it is tightly integrated with the Rust community, both by its motto and the footer structure.
Putting it into perspective: modules.raku.org links several Raku sites in the menu - I admit it may be a bit on the bloated side of things, however I think the general aim is good. Again, what is linked matters, over what is owned/maintained by the site.
Linking to the "most wanted" list gave purpose to the "most wanted" list. Likewise the Citation Index, which apparently died with the site, despite not being a part of it technically. (I think it's so nice and useful that I definitely don't want to give up on having something like that, now that I now it existed once.)
For the Todo... well, I think that one feels a bit like a draft. Maybe (? big question mark) besides doing something like "fez checkbuild", there could be a way to signal todo's or "help wanted" in the code, if only by convention?
This is a recurring thought of mine that we have bigger deficiencies on the presentation and communication side than content-wise - and actually this might be easier to improve.
Summing it up and putting it into the context of raku.land:
- I'd advise to add a "raku.org-ish" footer (not necessarily by look but by content)
- I would consider finding a place for linking content that can be saved/recycled from the "philosophy" of modules.raku.org
- bonus: the search bar might require some changing for raku.land as well :P