Fixed issues with handling of gh token

[Zeviraty]

Fixes issues outlined in #68
all relevant information in that thread

[minhtrancccp]

[c.c. @Matars]
i think the token logic, together with the logic for providers, should be rewritten from scratch instead, since it is inappropriate for DEFAULT section to contain provider-specific details. see also: https://docs.python.org/3/library/configparser.html#fallback-values

a stopgap for now can be to check provider name in the fetchers. but as a suggestion, a provider logic can be as followed:

• at the fresh start of program, a dedicated config section is generated for chosen provider (naturally, provider name can still be set in DEFAULT for obvious reasons). such section should contain a username, a provider url and a token (default to empty string), to start with. Enum and/or dataclass may help with specifying possible providers and their attributes, default values included.
• when program fetches data from a provider, fetcher class is init with configs for that provider. for example:
  • username/provider url:
    • read from config section
    • if none, prompt for one
    • if still none, terminate program
  • token:
    • read from config section
    • if none, read from appropriate environment variable (e.g., GH_TOKEN or GITLAB_TOKEN)
    • if still none, perhaps print warning for no tokens and consequences (e.g. limited returned data from api calls), as well as instruction on how to provide one

while im at it, in the future the program may also have an option for users to specify path to text file with api tokens and read the file, simplifying how the program keeps track of api tokens

[Matars]

[c.c. @Matars] i think the token logic, together with the logic for providers, should be rewritten from scratch instead, since it is inappropriate for DEFAULT section to contain provider-specific details. see also: https://docs.python.org/3/library/configparser.html#fallback-values

a stopgap for now can be to check provider name in the fetchers. but as a suggestion, a provider logic can be as followed:

* at the fresh start of program, a dedicated config section is generated for chosen provider (naturally, provider name can still be set in `DEFAULT` for obvious reasons). such section should contain a username, a provider url and a token (default to empty string), to start with. [`Enum` and/or `dataclass`](https://docs.python.org/3/howto/enum.html#dataclass-support) may help with specifying possible providers and their attributes, default values included.

* when program fetches data from a provider, fetcher class is init with configs for that provider. for example:
  
  * username/provider url:
    
    * read from config section
    * if none, prompt for one
    * if still none, terminate program
  * token:
    
    * read from config section
    * if none, read from appropriate environment variable (e.g., `GH_TOKEN` or [`GITLAB_TOKEN`](https://docs.gitlab.com/cli/#environment-variables:~:text=GITLAB%5FTOKEN))
    * if still none, perhaps print warning for no tokens and consequences (e.g. limited returned data from api calls), as well as instruction on how to provide one

while im at it, in the future the program may also have an option for users to specify path to text file with api tokens and read the file, simplifying how the program keeps track of api tokens

tysm

ld be rewritten from scratch instead, s

Thanks, doing this right now.