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):
-
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:
-
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.
-
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:
while one waits for a pr to fix these problems, a workaround is to export empty GH_TOKEN:
workaround demonstation
+ 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.
merged pr #64 introduced support for
ghprivate 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):environment variable
GH_TOKENis not handled properly in case the variable is unset, leading to program termination whensubprocess.runparses the variable. see theseGitHubFetcherinstance methods:_gh_api_search_items_fetch_contribution_graphtheoretically, point 1 should not be a problem if an appropriate token is passed when program is first set up. but that token, as a
GitHubFetcherinstance variable, is not in use anywhere else in the class.though @Zeviraty has attempted to remove
GH_TOKENusages 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_gitfromBaseFetcher_api_requestfromGitLabFetcherwhile one waits for a pr to fix these problems, a workaround is to export empty
GH_TOKEN:workaround demonstation
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
pdbto get a grasp on where the trouble was, and i don't wish to repeat this sort of experience when a new issue occurs.