cuducos / getgist Goto Github PK

Something like a ls for gists. For example:

$ getgist cuducos
  .bash_profie
  .vimrc (from Gist: MacVim setup)
  .vimrc (from Gist: NeoVim setup)

For example:

  Gist               File           URL
-----------------  -------------  -------------------------
README.md           My Gist #2      https://gist.github.com/…
anothe_file.md      My Gist #2      https://gist.github.com/…
file.md 🔒          First Gist 🔒    https://gist.github.com/…

Maybe 🔒 is not a good idea because it makes it more difficult to use withe grep (user has to input the emoji in the command, e.g.: lsgists cuducos | grep 🔒).

Replace
geymy <file name>
with
getmy <file name>

For example:

$ putmy Downloads/colors.py                                                                      cuducos@thomas
  User cuducos authenticated
  Fetching https://api.github.com/gists
  Sending contents of Downloads/colors.py to https://api.github.com/gists
  Could not create Downloads/colors.py
  POST request returned 422

(One might try the same for other commands, such as getmy ~/.vimrc for example)

This package has a poor design.

Both getgist.github and getgist.local (the core modules of the package) abstracts two things, making then coupled: they act as an adapter to systems (GitHub and local file system, respectively) and as a manager output information (formating, asking for confirmation, etc.). We need to decouple these responsibilities.

I suggest a huge refactor in which we end up with:

• GitHub class with methods to handle GitHub related actions:

  • .read(name: str) returns the contents of the gist
  • .write(name: str, contents: str, private: bool) writes the Gist and returns its URL
  • list() return a list of all the Gist files for a given user
  • plus “private” methods needed for the internals

• Local class with methods to handle local file system actions, but… to be honest, we might just inherit from Python's native pathlib.Path adding one or other method or wrapper to better fit our use case (and, yes, we can drop support for Python 2.7):

  • pathlib.Path.read_text() to read the contents of a local file
  • pathlib.Path.write_text(…) to write contents to a local file
  • plus “private” methods needed for the internals

• A logger/output object to replace existing GetGistCommons that would be able to:

  • write to stdout or stderr without raising errors when running as CLI
  • raise custom GetGist errors when using in a script (as in #14)

like can use wildcard character or options in getgist i think

http://click.pocoo.org/5/testing/

Awesome tool!

The lsgists command lists all gists including those in subfolders. Like unix ls, it would be better if it only listed the top level gists, That is also the way the gists.github.com site works.
Look at my gists at https://gists.github.com/osiristerje . You can see I have a history folder (that comes from Visual Studio Code sync settings, so it is automatically updated). Using lsgists the content of this folder is listed along with the few top level (16) gists I do have.

One could additionally add an option to list content in subfolders, using the same syntax as the UNIX ls.

In case people want to use it as part of their file scripts.

For example, to read the contents of a Gist:

getgist = GetGist("init.vimn")
content = getgist.github.read_gist_file(self.gist)

We can refactor the internals for a better API — I mean, it would make more sense to:

getgist = GetGist("init.vim")  # throws an error if (a) not found or (b) multiple files found with the same name
contents = getgist.contents

Shortcut for lsgists $GETGUST_USERNAME (just as getmy file is a shortcur for getgist $GETGIST_USERNAME file).