-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manipulating ETSConfig in Application. _initialize_application_home
is problematic
#464
Comments
Agreed, but it would make sense that the application does own its choices about directories. The problem is that information which really belongs to the app is being stored in a different place that's accessible to and used by things that are unaware of the existence of the application context. It seems to me that this information belongs in the app and not in ETSConfig at all. Could we deprecate use of |
I guess making the application the single source of truth for directory information would require restructuring so that any |
This just bit me again in a different way: assigning a different value to There is also a race condition during application start-up between the default value for the |
No, it just needs to be aware of the right directory to use. And currently the application is creating the |
I think that's the right thing to do for the |
In
Application._initialize_application_home
, theapplication_home
directory ofETSConfig
is mutated:envisage/envisage/application.py
Lines 486 to 495 in 6e5c7ba
This is good in the sense that it brings the two into alignment if they are different, and it's definitely good that the method makes sure that the directory exists(!), but that allows the possibility of objects created prior to the application having the old value. The most likely case is for
Preferences
objects to get the wrong thing, in code that creates a custom preferences object, like the (not unreasonable) following:The implementation of
ScopedPreferences.get_scope
as a side-effect sets the default value of itsapplication_preferences_filename
trait using the value ofETSConfig.application_home
before the creation of theApplication
object changes this, so it will potentially target the wrong file (in a directory that may not even exist).Even worse than the above example, it is possible that even the default
preferences
could end up being created before_initialize_application_home
is called if, for example, traits listeners are set up on it in the class in a way that causes early instantiation of the preferences from the default (eg. something that listens for changes to the preferences instance to hook up and disconnect preference listeners).To some extent, this boils down to "do not mess with global state that you do not own."
I'm not sure what the fix should be.
The text was updated successfully, but these errors were encountered: