Archive all clients except one official one

[MasterOdin]

There's been a lot of motion around clients in the last few weeks:

• PRs to the existing tldr-node-client, tldr-python-client, and tldr-c-client moving to various degrees of spec compliance
• The addition of the tlrc rust client
• The archival of the extldr elixir client since no one works on it, then unarchival since someone posted in element about wanting to work on it

Then there's to be the fact that installing "tldr" on different systems results in different things being installed (with varying degrees of "spec compliance"):

• On mac homebrew, it'll install https://github.com/tldr-pages/tldr-c-client (there is also separately tlrc)
• On debian/ubuntu, it'll install https://github.com/psibi/tldr-hs (last updated in 2021!)
• On fedora, it'll install https://github.com/tldr-pages/tldr-python-client
• On arch, it'll install https://github.com/tldr-pages/tldr-python-client
• On chocolatey (windows), it'll install https://github.com/isacikgoz/tldr (I think)

I think that tldr-pages should do two things:

1. Decide on a singular official client and put all resources towards that, archiving all others
2. Try to update all the different places people install tldr to use that one client so that the official face of tldr is unified

I don't think there's really any practical advantage of having 5 official clients given the nature of open source and how people come and go on things, as one or more will inventively fall into disrepair after the current big push to make them spec complaint, or fix all bugs or whatever. Additionally, the fact that depending on your platform, you'll end up with different things with some non "official" is creating confusion in the wild. We've already had many cases of people coming here for help with the haskell client, and is just creating a bad look for the org I think given it's essentially abandoned.

As a historical anecdote, I also remember that there was a conversation years ago on Matrix that someone had wanted to move their client under the tldr-pages umbrella and it was decided to not happen as the org didn't need more official clients maintained by one person, and that the wiki page was a sufficient place to list it. The addition of tlrc and extldr of course goes against that, and now it feels like "become a org member of tldr-pages, and then you too can have your own official client repo", which is just 🤷

[kbdharun]

Will check this again later (and maybe provide some additional insights too). Overall, I too agree with archiving some clients but disagree on a centralized one.

Just need to give an update about the Debian/Ubuntu package. I was in contact with the package maintainer a couple of months ago and the package has been marked transitional meaning it is being renamed from tldr to tldr-hs in the next Debian and Ubuntu LTS release, it has already been transitioned in interim versions of Ubuntu and Debian Unstable (Sid) , Experimental.

Checkout information about it here #10198, #10533

[MasterOdin]

Why do you disagree?

A side thing would be that do people meaningfully install from pip or npm directly for tldr, or do they mostly rely on their OS' package manager, and that the majority of end users really don't care what language the client is written in, they just want that it functions, it updates with their other OS packages, etc.

[sbrl]

I do disagree on a centralised client. We certainly can't anticipate all possible platforms. For example, we have tldr clients for the cli, browser, and Android in our ecosystem!

It is inevitable that people will come and go from the project, and having a single 'official' client - aside from the platform / environment issues - may fall to the same issues that the existing official clients are prone to I feel.

I do understand where you are coming from with the number of official clients though. We probably need some kind of long-term commitment for supporting a client to try to avoid official clients from being completely abandoned. Having said this, I should note that the ecosystem of tldr clients we do have is a valuable thing. It means that tldr is available in every possible environment and OS imaginable - a tall task for an official client to accomplish.

Ref packaging, we can definitely improve here. It would significantly help the user experience if we shipped an actively supported client for every distro that we currently have packages in.

[kbdharun]

"We", the tldr-pages organization, do not have an official client for the browser or Android. Perhaps there's interest in making one (cool), but on that same vein, there should only be one official browser client, one official android client, alongside the one CLI client.

We do have an official client for Android, that is the Python client with the official install method pip, I use the same in Termux and it works fine. I don't think a seperate repackaged one is necessary (maybe I will highlight this is Python client README, Clients Wiki).

Regarding, the browser client currently there is only one official client, the previous one has been archived. So I don't get the argument.

---

While, outfieldr and tealdeer are packaged natively. Termux suggests packaging applications for pip (and they won't accept it into their native repos if it is already packaged for pip, the other two community clients aren't written in Python, that's why they are packaged in the repo natively).

While you can install NPM client too, it has broken rendering in some places and isn't good on phone with the indexing after fetching archive. Also, Node versions aren't the recent one in their repos and often lacks security updates.

Ref image of Python client

[kbdharun]

Ideally, there'd be a strong link between making spec updates to the client updates. Given the worry about people coming and going, you'd ideally also chose a language that you would have a more broad appeal that would ideally always have a tldr-pages maintainer that works in that language. Like, while I think elixir is a cool language, I don't think it's a great fit given its relatively niche usage (atm). The client also shouldn't be that complex that I think it'd be hard for someone to pick up while learning a new language if need be.

I agree that elixir is a complex language and we barely have any other contributors, I would suggest retransferring extldr repo back to @ivanhercaz (and they can continue developement from there at their own pace) instead of archiving it in Org. If you notice, I still haven't updated it's status in Wiki from archived and that's intentional.

Regarding, tlrc I believe Rust is far more common and accessible to pick up for existing maintainers and new contributions.

[ivanhercaz]

I would suggest retransferring extldr repo back to @ivanhercaz (and they can continue developement from there at their own pace) instead of archiving it in Org.

As I commented in Matrix, I am just trying to return to the project, maybe writting some pages, maybe translating. Refactoring of extldr and compliance with the official clients spec is something that will happen, but I can't promise when and any deadline because at this moment it isn't a top priority for me.

But yes, instead of archiving it, please, transfer back to me, please.

[sbrl]

How would one pip install on Android without a terminal being supplied by default?

[kbdharun]

How would one pip install on Android without a terminal being supplied by default?

Currently, it's only possible to do this using Termux, but Android 16 is getting native Linux terminal support (first rolling out to first party devices like Pixels), so this should hopefully work by default in the future (by enabling Linux development environment from settings).

We can probably add a note/instructions to the Python client repo on how to run it on Android.

[ivanhercaz]

Just a note apart of my specific comment about the case of extldr but related with what I commented:

If the tldr-pages organization finally decided to not have under the organization all the currrent tldr clients, but just one, please, before to archiving it, first notice the original creators or more recent maintainer about this move, give the notice a deadline (1 month) to answer and decide. If they agree with archiving the repository, archive them under the organization. If they doesn't response, archive them under the organization. If they prefer to take back the repository under their ownership, transfer back the repository to the owner or the interested one in maintaining it.

I doesn't have many much to say about it, there is a long time I doesn't participate actively in tldr-pages, but I am totally agree with @sbrl's comment.

[cglong]

I actually came here to post something similar. As an outsider, I want to use tldr-pages, but I'm always stopped prematurely by the number of "official" clients. Given my lack of familiarity with the service, I'm unable to evaluate which one is "best", so I end up choosing none of them and don't use tldr-pages at all 🙁

[kbdharun]

Hi, thanks for expressing your opinion. As mentioned above, we don't intend to drop any of the currently active official clients as each of them are required for cross platform compatibility and serve unique purposes.

If you are in Windows, you can either install our Rust client using winget at winget install tldr or if you have NPM then npm install -g tldr. I am not sure why you aren't sure about choosing a client, while winget package isn't well known, we advertise the Node client as the primary official one in README.

Regardless of the client you use the base features are same. You can also use tldr without a client on the web using services like https://tldr.inbrowser.app, https://cheat.sh and https://command-not-found.com. If platform specific ones aren't for you, for commands you can directly check the markdown pages on the repo or through any web client/service.

[cglong]

Thank you so much @kbdharun! I do use Windows, so I'll be sure to look into these options next time I'm on that machine. However, the above feedback was written from the context of trying to use this on a Mac.

I generally install things with the heuristic of "if it can be installed using my system's package manager, go that route"; I like to manage my packages in one place, so I try to avoid npm install -g when possible.

So from that perspective, the README used to advise brew install tldr which installs the C client. Now the README's been updated to recommend the Rust client instead, even though the C one is still available too. And neither of these is the primary official one (Node)!

Based on your above response, it sounds like the Rust client should be "good enough" for my needs. But I do think newcomers on macOS might be confused as to why they shouldn't be accessing "tldr" using a package named tldr.

[spageektti]

What do you think about actually doing something about it? I don't think we should archive clients. Maybe we could just make them "unofficial" and focus on 1 or 2 main clients?