Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python command line client for tldr #147

Closed
felixonmars opened this issue Mar 5, 2014 · 11 comments
Closed

Python command line client for tldr #147

felixonmars opened this issue Mar 5, 2014 · 11 comments

Comments

@felixonmars
Copy link
Collaborator

https://github.com/felixonmars/tldr-python-client

Just wrote an initial version, rather simple, but it works :p

Will add some highlighting feature soon.

@danzimm
Copy link

danzimm commented Mar 5, 2014

@felixonmars this is a great idea (a python client). This appears to work fine but it doesn't follow the new model that we are using. It would be nice to keep a similar model across all clients. Our model is as follows: cache all the remote pages and then render from your local cache. The client you made doesn't appear to cache whatsoever which would be a bit misleading going from the node client over to the python client. Anywho, thanks for contributing!

@felixonmars
Copy link
Collaborator Author

Hmm, my bad, I still keep a very old copy of tldr to write as reference.

Just took a look at the new model, seems a little bit complex, but I'll try, thanks.

@danzimm
Copy link

danzimm commented Mar 5, 2014

@felixonmars No problem mate, I love all the help we can get. If you wouldn't mind, I can help out with that part (I wrote the caching stuffs in the node client)!

@felixonmars
Copy link
Collaborator Author

@danzimm That will be great :) I'm still trying to understand the directory logic in the current version of node client.

@rprieto
Copy link
Contributor

rprieto commented Mar 5, 2014

Hey @felixonmars, very nice one!! I'm tempted to add it to the README already, it's great to have a choice of clients.

Regarding functionality, consistency would be nice, but at the same time people have very different ideas and requirements. I've heard the Node client was too small / too big / too many dependencies / should have a build time conversion process / etc.

I think it's easier for each client to decide on its features and implementation. This will also encourage new features and ideas.

For example @nguyenchr has an idea for an OSX "screensaver" client showing commands of the day. This would definitely have its own way of working, and might or might not do local caching, or update on its own schedule.

@danzimm would that be ok?

Regarding the page structure though, we're in between 2 models right now. Maybe @felixonmars you can give us your opinion as well, as we need something that would work for most clients.

Current model

pages
  |__ common
  |   |__ tar.md         # gnu command everyone should have
  |   |__ ssh.md         # gnu command everyone should have
  |   |__ npm.md         # just a tool that could be installed on any OS
  |__ linux
  |   |__ emerge.md     # clearly a linux-only tool
  |__ osx
      |__ ssh.md         #  OSX has a different version with different flags

This has worked so far, but the split feels a little arbitrary, and it can be hard to find where a command lives.

Proposed model

pages
   |__ tar.md
   |__ ssh.md
   |__ ssh.osx.md
   |__ emerge.md
   |__ npm.md

By default, we can display <command>.md, but <command>.<os>.md should have precedence if available. This means the clients would let OSX users query Linux commands, but after all why not, they might just be curious about it. And the description for emerge could say "for Linux" or "Gentoo specific".


TLDR: nice work on the Python client! Would the new folder structure be easier for you?

@danzimm
Copy link

danzimm commented Mar 5, 2014

@rprieto Sounds good to me! I said what I said because I figured he was trying to emulate the node client completely, otherwise feel free to implement how you want!

@felixonmars
Copy link
Collaborator Author

@rprieto Yeah, the proposed model would really made functionalities like "--random" or "--list" easier. However, I'm still trying to use only one HTTP call (or maybe two in parallel, in the worst case) to the logic "get a platform-specified or common page as fallback".

For the caching part, if I want to keep the client really simple, maybe I can cache only the list itself in temp file. Otherwise, maybe I'd bring in package managers of platform itself (so pages will be stored under /usr/share/tldr in Linux, and managed only in package, for example), or try to keep compatibility with the node client.

@rprieto
Copy link
Contributor

rprieto commented Mar 5, 2014

Awesome!

We'll probably start migrating the pages soon. Only thing is that it breaks backwards compatibility, but it's early-on enough that it's probably OK.

@edgurgel
Copy link

@rprieto 👍 for the new structure.

Once it's changed I'll updated my Elixir client (https://github.com/edgurgel/tldr)

@rprieto
Copy link
Contributor

rprieto commented Apr 22, 2014

@edgurgel thanks! I added your client to the README.

I'll open a separate issue to track the change of structure.

@rprieto rprieto closed this as completed Apr 22, 2014
@edgurgel
Copy link

@rprieto, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants