hubugs
¶
Warning
I don’t really use GitHub anymore, so this package is somewhat orphaned. It
should still work and I will fix bugs when they’re pointed out, but
hubugs
is frankly quite a low priority for me.
hubugs
is a very simple client for working with GitHub’s issue
tracker from the command line.
It is written in Python, and works with Python 3.5 and newer. hubugs
is
released under the GPL v3
- Git repository
- Issue tracker
- Contributors
Contents¶
Background¶
GitHub provide a great issue tracker for small projects. It is simple, light and fast. There’s only one problem for me, I prefer command line tools for these tasks.
Luckily, the issue tracker exposes your data via a thoroughly documented API, so alternative interfaces are only a SMOP away.
The requirements¶
I live at the command line, data that isn’t easily manageable from there may as well not exist in my eyes. Therefore:
A simple command line interface is priority one.
It is nice to customise the views of data, and improve the look and feel of a view over time. Therefore:
Views must be customisable via simple templates
Data display must be fast, and require the minimum possible network access. Therefore:
Network data must be cached and compressed where possible
Installation¶
You can install hubugs
either via PyPI or
from source.
Using PyPI¶
To install using pip:
$ pip install hubugs # to install in Python’s site-packages
$ pip install --install-option="--user" hubugs # to install for a single user
To install using easy_install:
$ easy_install hubugs
From source¶
If you have downloaded a source tarball you can install it with the following steps:
$ python setup.py build
# python setup.py install # to install in Python’s site-packages
$ python setup.py install --user # to install for a single user
hubugs
depends on following packages, all of which are available from
PyPI:
click an excellent package for building command line tools in Python
configparser for configuration file handling
html2text is used formatting HTML for the terminal
httplib2 for HTTP communications
Jinja2 for templating
misaka is used for converting issue text to HTML
Pygments for syntax highlighting in template output
Configuration¶
Before hubugs can operate on issues you must generate an OAuth token. hubugs provides functionality to do this:
▶ hubugs setup
GitHub user? [JNRowe]
GitHub password? <password>
Support private repositories? (Y/n) y
Configuration complete!
Note
You can revoke the generated token at any time from the GitHub settings page.
If you wish to set the authorisation token from the command line you can use the
HUBUGS_TOKEN
environment variable. For example:
▶ HUBUGS_TOKEN=xxx hubugs open
Usage¶
The hubugs script is the main workhorse of hubugs
.
Let’s start with some basic examples:
▶ hubugs list # List the open bugs for the current project
Id Title
5 Handle some GitHub markdown extensions [feature]
6 Sphinx documentation tree [task]
7 Support per project templates [feature]
3 open bugs found
▶ hubugs search markdown # Search for bugs matching markdown
Id Title
5 Handle some GitHub markdown extensions [feature]
1 open bug found matching markdown
▶ hubugs show 6 # Show bug number 6
Id: 6
Title: Sphinx documentation tree
Labels: task
Created: yesterday by JNRowe
Updated: yesterday
State: open
Comments: 0
Pull request: No
This project deserves some real user documentation, not just a few notes in
`README.rst`.
▶ hubugs comment 6 # Comment on bug 6 using your editor
▶ hubugs comment -m"New comment." 6 # Add comment from command line
Options¶
-
--version
¶
show program’s version number and exit
-
-h
,
--help
¶
show program’s help message and exit
-
--pager
<pager>
¶ pass output through a pager
-
--no-pager
¶
do not pass output through pager
-
-p
<project>
,
--project
=<project>
¶ GitHub project to operate on
-
-u
<url>
,
--host-url
=<url>
¶ host to connect to, for GitHub Enterprise support
Note
You can set a default value for the --pager
and --host-url
options by
defining hubugs.pager
or hubugs.host-url
respectively in your git
configuration files. Both global and project local settings are supported,
see git-config(1) for more information.
Commands¶
setup
- Generate a new GitHub access token¶
hubugs.py setup [-h] [--local]
-
--local
¶
set access token for local repository only
list
- List bugs for a project¶
hubugs list [-h] [-s {open,closed,all}] [-l label]
[-o {number,updated}]
-
-s
<state>
,
--state
=<state>
¶ state of bugs to operate on
-
-l
<label>
,
--label
=<label>
¶ list bugs with specified label
-
-o
<order>
,
--order
=<order>
¶ sort order for listing bugs
-
-p
<number>
,
--page
<number>
¶ page number
-
-r
,
--pull-requests
¶
list only pull requests
search
- Search bugs reports in a project¶
hubugs search [-h] [-s {open,closed,all}]
[-o {number,updated}]
term
-
-s
<state>
,
--state
=<state>
¶ state of bugs to operate on
-
-o
<order>
,
--order
=<order>
¶ sort order for listing bugs
show
- Show specific bug(s) from a project¶
hubugs show [-h] [-f] [-p] bugs [bugs …]
-
-f
,
--full
¶
show bug including comments
-
-p
,
--patch
¶
display patches for pull requests
-
-o
,
--patch-only
¶
display only the patch content of pull requests
-
-b
,
--browse
¶
open bug in web browser
open
- Open a new bug in a project¶
hubugs open [-h] [-a label] [--stdin] [title] [body]
-
-a
label
,
--add
label
¶ add label to issue
-
--stdin
¶
read message from standard input
comment
- Comment on an existing bug in a project¶
hubugs comment [-h] [--stdin] [-m MESSAGE] bugs [bugs …]
-
--stdin
¶
read message from standard input
-
-m
<text>
,
--message
=<text>
¶ comment text
edit
- Edit an existing bug in a project¶
hubugs edit [-h] [--stdin] [title] [body] bugs [bugs …]
-
--stdin
¶
read message from standard input
close
- Close an existing bug in a project¶
hubugs close [-h] [--stdin] [-m MESSAGE] bugs [bugs …]
-
--stdin
¶
read message from standard input
-
-m
<text>
,
--message
=<text>
¶ comment text
reopen
- Reopen a previously closed bug in a project¶
reopen [-h] [--stdin] [-m MESSAGE] bugs [bugs …]
-
--stdin
¶
read message from standard input
-
-m
<text>
,
--message
=<text>
¶ comment text
label
- Perform labelling actions on an existing bug in a project¶
hubugs label [-h] [-a label] [-r label] bugs [bugs …]
-
-a
<label>
,
--add
=<label>
¶ add label to issue
-
-r
<label>
,
--remove
=<label>
¶ remove label from issue
milestone
- Add an issue to a milestone¶
hubugs milestone [-h] milestone [bugs [bugs …]]
milestones
- Manage repository milestones¶
hubugs milestones [-h] [-o {due_date,completeness}] [-s {open,closed}]
[-c milestone] [-l]
-
-o
<order>
,
--order
=<order>
¶ sort order for listing bugs
-
-s
<state>
,
--state
=<state>
¶ state of bugs to operate on
-
-c
<name>
,
--create
=<name>
¶ create new milestone
-
-l
,
--list
¶
list available milestones
Templates¶
Output is produced from templates using Jinja. Before writing your own templates you should read the awesome Jinja template designer documentation.
Note
If you create some cool templates of your own please consider posting them in an issue or pushing them to a fork on GitHub, so that others can benefit.
Template locations¶
Templates are loaded from directories in the following order:
If it exists,
${XDG_DATA_HOME:~/.local/share}/hubugs/templates
Any
hubugs/templates
directory in the directories specified byXDG_DATA_DIRS
The package’s
templates
directory
For information on the usage of XDG_DATA_HOME
and
XDG_DATA_DIRS
read XDG Base Directory Specification.
Note
For OS X users there is a fallback to ~/Library/Application Support
,
if XDG_DATA_HOME
is unset.
Precedence¶
The first name match in the order specified above selects the template, so a
view/list.txt
in $XDG_DATA_HOME/hubugs/templates
overrides
the view/list.txt
provided in the hubugs
package.
Template sets¶
You can specify the template set to use by defining a hubugs.templates setting in your git configuration files. For example:
▶ git config --global hubugs.templates my_templates
You can also set project specific template sets by editing a repository’s config. See git-config(1).
Naming¶
Templates are separated in to two groups. The first group, view
, is for
templates used in directly producing consumable output(such as from the list
subcommand). The second group, edit
, is for templates used to generate
input files for editing text(such as in the open
subcommand).
view
group templates currently include:
issue.txt
for formatting a single buglist.txt
for formatting list output
edit
group templates currently include:
default.mkd
for general use, such as in commenting on a bugopen.mkd
for opening(or editing) bugs
Data¶
The following variables are available for use in templates
View group¶
-
columns
(int)¶ The width of the current terminal window
list.txt
data¶
-
project
(Repository)¶ The current project’s repository data. See Repository objects.
-
bugs
(list)¶ Contains the sorted list of bugs to display, if any. See Bug objects.
-
id_len
(int)¶ Set to the maximum length of the bug IDs to display
-
state
(str)¶ The bug states being searched/listed
-
order
(str)¶ The display order
-
term
(str)¶ The search term being listed, if any
issue.txt
data¶
-
project
(Repository) The current project’s repository data. See Repository objects.
-
bug
(list)¶ Contains the sorted list of bugs to display, if any. See Bug objects
-
comments
(list)¶ When displaying a single bug this contains the list of comments associated with a bug, if any. See Comment objects
-
full
(bool)¶ True, if the user provided the
hubugs show -f
option
-
patch
(str)¶ The content found at the location in
Bug.patch_url
, if the user provided thehubugs show -p
option
-
patch_only
(bool)¶ True, if the user provided the
hubugs show -o
option
Edit group¶
-
comment_char
(str)¶ The character to use for comments in templates, defaults to
#
. Seecore.commentchar
in git-config(1)
All groups¶
Jinja templates support object attribute and method access, so an individual
bug
object’s created_at
attribute can be called with a
strftime()
method for custom date output. For example,
{{ bug.created_at.strftime("%a, %e %b %Y %H:%M:%S %z") }}
can be used to
output an RFC 2822-style date stamp.
If you’re authoring your own templates and you find you need extra data for their generation open an issue.
Filters¶
hubugs
defines the following filters beyond the huge range of excellent
built-in filters in Jinja:
Note
If you write extra filters that you believe could be of use to other
hubugs
users please consider posting them in an issue or pushing
them to a fork on GitHub, so that others can benefit from your work.
colourise
¶
This filter applies a colour to text, if possible.
For example, to show a bug’s title
attribute in red:
{{ bug.title | colourise('red') }}
or to display black text on a red background:
{{ bug.title | colourise('black on red') }}
Note
This filter is also available under the synonym colorize
.
highlight
¶
This filter highlights text using Pygments. You can specify the lexer to be used, and also the formatter.
For example, to highlight a chunk of text as Python:
{{ text | highlight('python') }}
To do the same using the 256-colour mode of Pygments:
{{ text | highlight('python', 'terminal256') }}
See the output of pygmentize -L for the list of available lexers and formatters.
markdown
¶
The purpose of this filter is to convert the Markdown formatted text from a GitHub issue to html. The excellent misaka package is used to provide the conversion.
In the default templates it is used to render bug bodies:
{{ comment.body | markdown | html2text }}
Note
We ping-pong the conversion from Markdown to HTML as it produces a prettier text representation of the comment. We benefit from uniform newline usage and clean word wrapping of the output.
hubugs¶
Simple client for GitHub issues¶
SYNOPSIS¶
hubugs [option]… <command>
DESCRIPTION¶
hubugs
is a very simple client for working with GitHub’s issue tracker.
It allows you to perform all the issue related tasks you’d normally perform from
the command line.
OPTIONS¶
- --version
show program’s version number and exit
- -h, --help
show program’s help message and exit
- --pager <pager>
pass output through a pager
- --no-pager
do not pass output through pager
- -p <project>, --project=<project>
GitHub project to operate on. You can supply just
<project>
if you wish to work on one of your own projects, or<user>/<project>
to operate on another user’s repository. Default is derived from thehubugs.project
setting in the git config or the current repository, if possible.- -u <url>, --host-url=<url>
host to connect to, for GitHub Enterprise support
COMMANDS¶
list
¶
List bugs for a project
- -s <state>, --state=<state>
state of bugs to operate on
- -l <label>, --label=<label>
list bugs with specified label
- -o <order>, --order=<order>
sort order for listing bugs
- -p <number>, --page <number>
page number
- -r, --pull-requests
list only pull requests
search
¶
Search bugs reports in a project
- -s <state>, --state=<state>
state of bugs to operate on
- -o <order>, --order=<order>
sort order for listing bugs
show
¶
Show specific bug(s) from a project
- -f, --full
show bug including comments
- -p, --patch
display patches for pull requests
- -o, --patch-only
display only the patch content of pull requests
- -b, --browse
open bug in web browser
open
¶
Open a new bug in a project
- -a label, --add label
add label to issue
- --stdin
read message from standard input
comment
¶
Comment on an existing bug in a project
- --stdin
read message from standard input
- -m <text>, --message=<text>
comment text
close
¶
Close an existing bug in a project
- --stdin
read message from standard input
- -m <text>, --message=<text>
comment text
reopen
¶
Reopen a previously closed bug in a project
- --stdin
read message from standard input
- -m <text>, --message=<text>
comment text
label
¶
Perform labelling actions on an existing bug in a project
- -a <label>, --add=<label>
add label to issue
- -r <label>, --remove=<label>
remove label from issue
milestone
¶
Add an issue to a milestone
milestones
¶
Manage repository milestones
- -o <order>, --order=<order>
sort order for listing bugs
- -s <state>, --state=<state>
state of bugs to operate on
- -c <name>, --create=<name>
create new milestone
- -l, --list
list available milestones
CONFIGURATION¶
You can specify the template set to use by defining a hubugs.templates
setting in your git configuration files. For example:
▶ git config --global hubugs.templates my_templates
You can also set project specific template sets by editing a repository’s config. See git-config(1).
You can set a default value for the --pager
and --host-url
options by
defining hubugs.pager
or hubugs.host-url
respectively in your git
configuration files.
BUGS¶
None known.
AUTHOR¶
Written by James Rowe
RESOURCES¶
Home page, containing full documentation: http://hubugs.readthedocs.io/
Issue tracker: https://github.com/JNRowe/hubugs/issues/
COPYING¶
Copyright © 2010-2016 James Rowe.
hubugs is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
hubugs is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with hubugs. If not, see <http://www.gnu.org/licenses/>.
Frequently Asked Questions¶
Do you accept template contributions?¶
Yes, if they are somewhat general. And, it is a great way to have me maintain template compatibility for you in case something changes in a future version.
Why is the wrapping broken in comments I make?¶
Unfortunately, GitHub have crippled the newline behaviour of Markdown. If you wrap your comments for readability then you’ll be creating new paragraphs with every single line. There is very little that can be done locally to fix this.
The easiest way to workaround the issue is to disable wrapping in your text
editor for template files. The files hubugs
creates are easy to match for
automating this within your editor, just use $TMPDIR/hubugs-*.mkd
.
How do I create headlines when lines beginning with #
are scrubbed?¶
Markdown syntax supports two different heading formats, and only one of them
requires a #
at the start of a line. Using the alternative setext format
is simple:
Heading
=======
Sub-heading
-----------
The other possibility, although not recommended, is to set a custom value for
core.commentchar in your git
configuration settings. program:hubugs
will honour the set value, and strip any lines that begin with that character.
You should note however that this is a recent addition to git, and other tools
may not work correctly with it set to a non-default value.
I don’t like your choice of template language¶
[It isn’t really a question, but it has come up a couple of times.]
The use of Jinja should only be an issue if you wish to author your own templates, if you’re using the built-in templates you shouldn’t notice Jinja at all. That said…
The use of Jinja seems to be an entry barrier to some people, but it isn’t going to change. For the same – invariably pointless and religious – reasons people prefer other templating engines I prefer Jinja.
Note
With all that said, I probably wouldn’t be opposed to accepting patches supporting additional optional engines ;)
Alternatives¶
Before diving in and spitting out this package I looked at the alternatives below. If I have missed something please drop me a mail.
Both the ghi
and github-cli
packages listed below are very useful, and
quite usable, clients for GitHub issues. You should definitely try them out
before making a decision on what to use, and this would also allow you to
highlight any possible bias I may have shown in comparing them ;)
ghi
¶
ghi is a great issues client, written in Ruby.
I personally didn’t like the “feel” of the command line interface, and wanted slightly different output.
hubugs
provides the following advantages:
Easily customisable output
On-disk cache support
and has the following disadvantages:
hubugs
requires a significant number of external packages, which may be a problem for some users
github-cli
¶
github-cli is a fantastic command-line client for GitHub’s issues, written in
Python. I really liked github-cli
to the extent of authoring a few
patches, but just didn’t find it comfortable to use in the long run 1.
hubugs
provides the following advantages:
Easily customisable output
HTTP compression support
On-disk cache support
Pull request integration
Uses the same method as
git
for choosing an editor to use, which will only affect you if you a custom editor for interacting withgit
and has the following disadvantages:
hubugs
requires a significant number of external packages, which may be a problem for some users
- 1
If you look at the timeline for the hubugs repository and my github-cli fork you’ll see I was using
github-cli
for a few months after spikinghubugs
.
Release HOWTO¶
Test¶
In the general case tests can be run via pytest
:
$ pytest tests
When preparing a release it is important to check that hubugs
works with
all currently supported Python versions, and that the documentation is correct.
Prepare release¶
With the tests passing, perform the following steps
Update the version data in
hubugs/_version.py
Update
NEWS.rst
, if there are any user visible changesCommit the release notes and version changes
Create a signed tag for the release
Push the changes, including the new tag, to the GitHub repository
Todo items for documentation¶
API documentation¶
Note
The documentation in this section is aimed at people wishing to contribute
to hubugs
, and can be skipped if you are simply using the tool from
the command line.
Command line¶
Note
The documentation in this section is aimed at people wishing to contribute to
hubugs
, and can be skipped if you are simply using the tool from the
command line.
-
hubugs.
setup
(globs, local)¶ Setup GitHub access token.
-
hubugs.
list_bugs
(globs, label, page, pull_requests, order, state)¶ Listing bugs.
-
hubugs.
search
(globs, order, state, term)¶ Searching bugs.
-
hubugs.
show
(globs, full, patch, patch_only, browse, bugs)¶ Displaying bugs.
-
hubugs.
open_bug
(globs, add, create, stdin, title, body)¶ Opening new bugs.
-
hubugs.
comment
(globs, message, stdin, bugs)¶ Commenting on bugs.
-
hubugs.
edit
(globs, stdin, title, body, bugs)¶ Editing bugs.
-
hubugs.
close
(globs, stdin, message, bugs)¶ Closing bugs.
-
hubugs.
reopen
(globs, stdin, message, bugs)¶ Reopening closed bugs.
-
hubugs.
label
(globs, add, create, remove, list, bugs)¶ Labelling bugs.
-
hubugs.
milestone
(globs, milestone, bugs)¶ Issue milestones.
-
hubugs.
milestones
(globs, order, state, create, list)¶ Repository milestones.
-
hubugs.
report_bug
(globs)¶ Report a new bug against hubugs.
models
¶
Note
The documentation in this section is aimed at people wishing to contribute
to hubugs
, and can be skipped if you are simply using the tool from
the command line.
-
hubugs.models.
object_hook
(__d, __name='unknown')¶ JSON object hook to create dot-accessible objects.
-
hubugs.models.
_v2_conv_timestamp
(__s)¶ Parse API v2 style timestamps.
- Parameters
__s (
str
) – Timestamp to parse
-
hubugs.models.
from_search
(__obj)¶ Support legacy API search results as API v3 issues(-ish).
This is an awful hack to workaround the lack of search support in API v3. It needs to be removed at the first possible opportunity.
- Returns
API v2 issue mangled to look like a API v3 result
- Return type
Issue
Template¶
Note
The documentation in this section is aimed at people wishing to contribute
to hubugs
, and can be skipped if you are simply using the tool from
the command line.
-
hubugs.template.
get_template
(__group, __name)¶ Fetch a Jinja template instance.
Jinja filter support¶
-
hubugs.template.
jinja_filter
(__func)¶ Simple decorator to add a new filter to Jinja environment.
-
hubugs.template.
colourise
(__text, fg=None, bg=None, **kwargs)¶ Colourise text.
Returns text untouched if colour output is not enabled
-
hubugs.template.
highlight
(__text, lexer='diff', formatter='terminal')¶ Highlight text with pygments.
Returns text untouched if colour output is not enabled
User interface support¶
-
hubugs.template.
display_bugs
(__bugs, __order, **extras)¶ Display bugs to users.
-
hubugs.template.
edit_text
(edit_type='default', data=None)¶ Edit data with external editor.
- Parameters
- Return type
- Returns
User supplied text
- Raises
EmptyMessageError
– No message givenEmptyMessageError
– Message not edited
Utilities¶
Note
The documentation in this section is aimed at people wishing to contribute
to hubugs
, and can be skipped if you are simply using the tool from
the command line.
-
hubugs.utils.
setup_environment
(__project, __host_url)¶ Configure execution environment for commands dispatch.
Convenience functions¶
-
hubugs.utils.
get_editor
()¶ Choose a suitable editor.
See git-var(1) for details.
Git/GitHub support¶
-
hubugs.utils.
get_github_api
()¶ Create a GitHub API instance.
- Returns
GitHub HTTP session
- Return type
httplib2.Http
-
hubugs.utils.
get_git_config_val
(__key, default=None, local_only=False)¶ Fetch a git configuration value.
-
hubugs.utils.
set_git_config_val
(__key, __value, local_only=False)¶ Set a git configuration value.
-
hubugs.utils.
get_repo
()¶ Extract GitHub project name from git/hg config.
We check the git config for
hubugs.project
, and then fall back toremote.origin.url
. If both of these fail we check a mercurial root, to satisfy thehg-git
users.- Return type
- Returns
GitHub project name, including user
Errors¶
Note
The documentation in this section is aimed at people wishing to contribute to
hubugs
, and can be skipped if you are simply using the tool from the
command line.
-
exception
hubugs.template.
EmptyMessageError
¶ Error to raise when the user provides an empty message.
-
exception
hubugs.utils.
HttpClientError
(message, response, content)¶ Error raised for client error status codes.
-
exception
hubugs.utils.
RepoError
¶ Error raised for invalid repository values.
Appendix¶
Bug
objects¶
-
Bug.
assignee
(User)¶ The user the issue is assigned to, if any.
-
Bug.
body
(str)¶ The full body of the issue.
-
Bug.
body_html
(str)¶ The full body of the issue rendered as HTML.
-
Bug.
closed_at
(datetime.datetime)¶ The date and time the issue was closed.
-
Bug.
closed_by
(User)¶ The user the issue was closed by, if closed.
-
Bug.
comments
(int)¶ The number of comments made on the issue.
-
Bug.
created_at
(datetime.datetime)¶ The date and time the issue was created.
-
Bug.
labels
(list)¶ Label
objects associated with the issue.
-
Bug.
milestone
(str)¶ The milestone name associated with the issue, if any.
-
Bug.
number
(int)¶ The issue’s number.
-
Bug.
pull_request
(PullRequest)¶ Pull request data associated with the issue.
-
Bug.
state
(str)¶ State of the issue, either
open
orclosed
.
-
Bug.
title
(str)¶ The issue’s title.
-
Bug.
updated_at
(datetime.datetime)¶ The date and time when the issue was last updated.
-
Bug.
user
(User)¶ The GitHub user that created the issue.
Comment
objects¶
-
Comment.
body
(str)¶ The full text of the comment.
-
Comment.
body_html
(str)¶ The full text of the comment rendered as HTML.
-
Comment.
created_at
(datetime.datetime)¶ The date and time the comment was created.
-
Comment.
updated_at
(datetime.datetime)¶ The date and time when the comment was last updated.
-
Comment.
user
(User)¶ The GitHub user that created the comment.
Label
objects¶
-
Label.
color
¶ The colour value for the given label.
-
Label.
name
¶ The name given to the label.
PullRequest
objects¶
-
PullRequest.
diff_url
(str)¶ URL for diff output associated with the issue.
-
PullRequest.
patch_url
(str)¶ URL for the git format-patch output associated with the issue.
Repository
objects¶
-
Repository.
clone_url
(str)¶ Clone URL for fetching via HTTP.
-
Repository.
created_at
(datetime.datetime)¶ The date and time the repository was created.
-
Repository.
description
(str)¶ The description given to the repository
-
Repository.
fork
(bool)¶ Whether the repository is a fork of another on GitHub
-
Repository.
forks
(int)¶ The number of forks on GitHub
-
Repository.
git_url
(str)¶ Clone URL for fetching via
git
protocol.
-
Repository.
has_downloads
(bool)¶ Whether the repository has downloads enabled
-
Repository.
has_issues
(bool)¶ Whether the repository has issues enabled
-
Repository.
has_wiki
(bool)¶ Whether the repository has the wiki enabled
-
Repository.
homepage
(str)¶ The homepage of the repository
-
Repository.
html_url
(str)¶ The main project page on GitHub
-
Repository.
language
(str)¶ The programming language used
-
Repository.
master_branch
(str)¶ The repository’s defined master branch
-
Repository.
mirror_url
(str)¶ The original location of a repository, if a mirror
-
Repository.
name
(str)¶ The repository’s name
-
Repository.
open_issues
(int)¶ The number of open issues in a repository
-
Repository.
owner
(User)¶ The owner of the repository
-
Repository.
private
(bool)¶ Whether the repository is set as private
-
Repository.
pushed_at
(datetime.datetime)¶ The last time the repository’s content was updated
-
Repository.
size
(int)¶ The size of the repository
-
Repository.
watchers
(int)¶ The number of watchers of the repository