Refactor module loading v2: move writing of module_config.bin to bootstrap #425
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was looking over PR #396, updated it from the master, but ran into some issues. The "do not lazy load" commit (71ba788) causes failures since
self.modules
is oftenNone
. When I dove a bit deeper I became a little unsatisfied with how often ModuleCollector was being initialized and doing all that work. Before we would import the same instantiated object frombackends
instead of passing it around. I could do some more work here, but I think this PR's method may accomplish the same thing in a more simple fashion.This PR only writes the
module_config.bin
inbootstrap
and then updating the sharedconfig
object.Both this solution and the other PR mean that the frontend will only have the latest data from
module_config.bin
if it is started after the backend. I do not believe this is a large problem asmodule_config.bin
is only modified if code is updated (necessitating a restart of both anyway), but worth noting for 4CAT instances not managed by Docker as order becomes important.As you are well aware, both PRs have an oddity in that all module classes are imported with a version of config that does not have the module configurations. The only place I noticed an effect was in
ModuleCollector.expand_datasources()
which callsget_options()
. That method does often use config, but inexpand_datasources
we only care about any options returning so there seems to be no issue. I note it in case something happens down the road related to this.