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
During the import of brian2, the validity of preferences set in preference files is checked. At time of the brian2 import, any external package that defines a new preference (e.g. brian2cuda or brian2genn) will not be imported yet. If the preference files sets a preference registered in the external package, one gets a Preference cateogry ... is unregistered error.
I think it would be nice to support preference files brian2cuda / brian2genn as well. One solution would be to move the preference check from brian2/only.py into the first run call. I'm not sure if this would break things though if one relies on changing a preference between defining brian objects (if that is possible)?
Alternatively, one could implement a way that brian2 is imported without the check and have brian2cuda / brian2genn be imported before brian2 (they would internally still import brian2 but without the preference check). When brian2 is imported in the main script, the check would run, but external preferences would be registered already.
The text was updated successfully, but these errors were encountered:
Or just hard-code that prefs.devices.cuda_standalone and prefs.devices.genn are excluded from the check and let the packages handle checking those preference in preference files? Probably the easiest solution. And adding any addition package that defines preferences in the future shouldn't be a problem (and will likely occur not so often :P).
denisalevi
added a commit
to brian-team/brian2cuda
that referenced
this issue
Aug 31, 2021
Hmm, this is a very good point. I think this merits a bit of thought, since it is not the only thing in the preference system that is suboptimal. For example, some preferences are only checked during import (e.g. the logging configuration) and changing them later does not have any effect. I would prefer not adding a workaround on top of our system at this time.
What we could do as a temporary solution in brian2genn and brian2cuda is to allow the user to store their preferences in separate files and add something like this to the end of their __init__.py (when the preferences are already registered):
During the import of
brian2
, the validity of preferences set in preference files is checked. At time of the brian2 import, any external package that defines a new preference (e.g. brian2cuda or brian2genn) will not be imported yet. If the preference files sets a preference registered in the external package, one gets aPreference cateogry ... is unregistered
error.I think it would be nice to support preference files brian2cuda / brian2genn as well. One solution would be to move the preference check from
brian2/only.py
into the firstrun
call. I'm not sure if this would break things though if one relies on changing a preference between defining brian objects (if that is possible)?Alternatively, one could implement a way that brian2 is imported without the check and have brian2cuda / brian2genn be imported before brian2 (they would internally still import brian2 but without the preference check). When brian2 is imported in the main script, the check would run, but external preferences would be registered already.
The text was updated successfully, but these errors were encountered: