Open B4rabbas opened 4 months ago
configparser.DuplicateOptionError: While reading from '/home/harry/.var/app/net.davidotek.pupgui2/config/pupgui/config.ini' [line 5]: option 'github_api_token' in section 'pupgui' already exists
Did you configure the GitHub API access token? It seems like it is configured twice.
Please edit /home/harry/.var/app/net.davidotek.pupgui2/config/pupgui/config.ini
and remove the second github_api_token
entry.
Maybe you meant gitlab_api_token
instead? (GitLab not GitHub)
Yes, it's fixed.
Is there a (straightforward) way we could manage this better? For example removing duplicate entries, or ignoring them and using the latest?
Assuming the issue above was that github_api_token
was defined twice when it was meant to be gitlab_api_token
, this would simply mask an issue, as a user would expect the GitLab token to be defined and it wouldn't be. But maybe handling it in some way is better than a crash? This crash afaict comes from the library we use but maybe there's something we can configure?
Then again , maybe not worth it since the long-term plan is to allow this to be configurable from the UI.
I had a look into this, we could catch configparser.DuplicateOptionError
, but we'd have to do this in a few places.
Mostly when we read from the config file in util.py
, we use read_update_config_value
(introduced as part of #306). There was, as far as I recall, an explicit decision to not use read_update_config_value
in certain places, because a refactor could end up being a bit unwieldy. So there are two places where we still interact with the config file directly:
install_directory
config_custom_install_location
In order to catch this error, we would need to make adjustments in the following places (how we want to handle the exception is a different story):
read_update_config_value
- This one is straightforward, we can just wrap the function in a try/except DuplicateOptionError
block.install_directory
- Also straightforward, the same idea, and we return an empty string if the install directory is not found anyway, so we have a fallback return valueconfig_custom_install_location
- The tricky one, as this expects to always return a dictionary. Depending on how we want to handle the exception, i.e. if we want to just warn and silently continue, we'll have to be careful here.So that covers where we need to make the changes, and how we coulld do it. Basically just wrap these interactions with the config file in a try/except that catches DuplicateOperationError
.
If we go forward with this, the question becomes how we want to handle this. There are some ideas I have:
read_update_config_value
, we have the section
and option
, so we could offer a guess to the user as to what key is duplicated in what section.
ConfigFile
is a solution, but maybe each time we write we'll still get pestered about this, not sure...github_api_token
is defined 5 times, take either the 1st or 5th occurrence).ConfigParser
, which feels dirty to me (we can't read with ConfigParser
because then it'll error about the duplicate key, and so the cycle continues). This also means we'd have to manage the logic of parsing the sections and such ourselves. Finally, the responsibility would be on us to decide which key to remove. How do we decide this? Do we remove the first, or last instance?Personally, I think showing a more human-readable dialog to override the existing dialog, which just pulls in the stacktrace (#313), to better inform the user of what actually went wrong, is a step in the right direction. The two problems here are:
This one is straightforward, we can just wrap the function in a try/except DuplicateOptionError block. Show a slightly more user-friendly error. Instead of a stack trace, we could show a dialog and print that some key in the config file is duplicated. In read_update_config_value, we have the section and option, so we could offer a guess to the user as to what key is duplicated in what section.
Feels a bit sketchy, but we could do something like this:
try:
# config code
except DuplicateOperationError:
raise Exception("Hello, this is a user friendly error message")
Or ideally just show a message box and then load a default config from constants.py
or something.
If we go forward with this, the question becomes how we want to handle this
I should note that the user should know how to edit the config as duplicate keys were introduced by the user before.
but if we could read and remove duplicate keys, that might be an option to do after warning about the duplicate values
Removing the duplicate key would probably be the most user friendly option although we would need to remove both instances as we don't know which one is correct and then let the user know.
Alternatively, there could be a dialog with the buttons: Okay, just delete the config for me
and Exit, I will fix it myself
.
Is this even worth exploring? Maybe we'd be better putting effort into refactoring the "About" menu into an "Options" menu, and exposing the config options on the UI. That way, we should be able to avoid duplicate entries in the config file in the first place. Although there's no reason we can't do both.
Seems to the the most logical option...
I feel like the way to go is:
Delete config
(default choice) and I'll fix it myself
.I like the "delete" option. This kind of issue should never happen from our side (we always use ConfigParser
, and it's unlikely to cause a problem) so I think having the option to just start over or let the user investigate is good.
Describe the bug
ProtonUpQt crash on startup
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Launching the app witheout crash.
Screenshots
Sorry, there is nothing more than the shell output.
Desktop (please complete the following information):
Additional context
Happen after installing proton in native steam (for my lutris library)
Terminal output