You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
systemwide defaults are ignored if user rc is found, this is atypical behavior #11279
Normally, systemwide configuration files at not completely ignored just because a local/user configuration file exists. But MPL will ignore default configuration values in /etc/matplotlibrc if a user matplotlibrc is found.
The documentation states that user configuration files are searched first, which, if you think about it, only makes sense if the configuration files are all mutually exclusive. But, this is not stated or acknowledged in the documentation, elsewhere. Since mutual exclusivity is abnormal behavior for configuration files, can you please, at least, make this more clear in the documentation?
Is it possible to implement more conventional behavior where the system-wide defaults are always read, if they exist, and the user-specific or local configurations override them?
What plans were there for "fixing" this? And I see #9526 (which I plan to
use my veto rights to block until the end of time) as completely unrelated
to the issue at hand. The question is whether we should update the rcParam
dictionary while loading all the found files, or just load the first found
file. This can be done in the current architecture just fine, and your
proposal doesn't require that behavior either.
So, the question that really needs to be addressed is if the parameter list
is orthogonal or not. Does every possible value of each parameter make
complete sense regardless of the value of any other parameter in the list.
I believe this to be the case, but I don't think anyone has actually done
an analysis to verify that.
#9528 would fix this by allowing you to implement whatever fallback logic you want, it's Python, you can run whatever code you want, you can manipulate sys.path, whatever. And yes I know your position regarding that statement, we can keep the discussion to that thread.
I have no problems with anyone implementing cascading logic into the current system either... (but #6320 is sufficient to track this issue)
Activity
anntzer commentedon May 21, 2018
That's basically a duplicate of #6320, and yes we have plans to fix that (essentially #9528).
WeatherGod commentedon May 23, 2018
anntzer commentedon May 23, 2018
#9528 would fix this by allowing you to implement whatever fallback logic you want, it's Python, you can run whatever code you want, you can manipulate sys.path, whatever. And yes I know your position regarding that statement, we can keep the discussion to that thread.
I have no problems with anyone implementing cascading logic into the current system either... (but #6320 is sufficient to track this issue)