regressions on gh token handling #68

merged pr #64 introduced support for gh private token. however, a number of regressions has not been patched before the pr got accepted into the main branch, namely (from the most severe to the least):

1. environment variable GH_TOKEN is not handled properly in case the variable is unset, leading to program termination when subprocess.run parses the variable. see these GitHubFetcher instance methods:

   • _gh_api

   • _search_items

   • _fetch_contribution_graph

2. theoretically, point 1 should not be a problem if an appropriate token is passed when program is first set up. but that token, as a GitHubFetcher instance variable, is not in use anywhere else in the class.

3. though @Zeviraty has attempted to remove GH_TOKEN usages where the variable is not needed, there still exists two such instances, which are also terminating chokepoints as shown above. the instances are in these methods:

   • _build_contribution_graph_from_git from BaseFetcher

   • _api_request from GitLabFetcher

while one waits for a pr to fix these problems, a workaround is to export empty GH_TOKEN:

+ declare -f is-token-set
is-token-set () 
{ 
    [ -v GH_TOKEN ] || echo 'token not set'
}
+ is-token-set
+ '[' -v GH_TOKEN ']'
+ echo 'token not set'
token not set
+ gitfetch
Error: expected str, bytes or os.PathLike object, not NoneType
+ export GH_TOKEN=
+ GH_TOKEN=
+ is-token-set
+ '[' -v GH_TOKEN ']'
+ gitfetch
    No contribution data yet              Minh Tran - 0 contributions this year
                                          

+ gitfetch --clear-cache
Cache cleared successfully!

as a final note, it will be great if the program has a better verbose/debug mode, as the error messages (an example is shown in the above demonstration) don't provide enough details to figure out where the errors originate. for this particular issue, i had to spend hours working with pdb to get a grasp on where the trouble was, and i don't wish to repeat this sort of experience when a new issue occurs.