Skip to content
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

Load modules sorted by dependencies #923

Open
wants to merge 6 commits into
base: dev
Choose a base branch
from

Conversation

Tharylia
Copy link
Contributor

This PR implements module loading sorted by dependencies.
This is needed for contexts to work properly if the context class is contained inside the module.

Discussion Reference

All new features must be discussed prior to code review. This is to ensure that the implementation aligns with other design considerations. Please link to the Discord discussion:

https://discord.com/channels/531175899588984842/599270434642460753/1160999293361061979

Is this a breaking change?

Breaking changes require additional review prior to merging. If you answer yes, please explain what breaking changes have been made.

No

@@ -300,7 +300,10 @@ public class ModuleService : GameService {
Logger.Warn("Failed to load module from path {modulePath}.", ApplicationSettings.Instance.DebugModulePath);
}

debugModule?.TryEnable();
if (debugModule != null) {
debugModule.State.Enabled = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This impacts the state even after we're no longer using --module, which is a change in behavior we'll just want to keep in mind.

Before: when no longer using --module, a module would adhere to the state it was previously in.
After: when no longer using --module, the module will be enabled until disabled again.

@@ -5,7 +5,7 @@
},
"PowerShell HUD": {
"commandName": "Project",
"commandLineArgs": "-p powershell -w ConsoleWindowClass"
"commandLineArgs": " --process WindowsTerminal --window \"Windows PowerShell\" "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears to be completely unrelated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true.. not sure how that got in here. How do I remove that again?

@dlamkins
Copy link
Member

I did a first-pass lookover.

Other things that need answering:

  1. What is the expected behavior when a module is allowed to start prior to GW2? How does this affect the load order?
  2. What happens when a user manually disables a dependency?
  3. What UI feedback is provided to the user to explain a module not enabled because of a dependency issue? Is it just the dependency section?

Regarding your use case, it's still unclear to me why the dependent module has a different implementation of an assembly being loaded, making the load order important. Can you provide a minimal code example that exhibits this issue so that I can see it?

  1. Load order doesn't explicitly ensure that a module's assemblies are loaded prior to another in the event that the module doesn't attempt to use an assembly first.

@Tharylia
Copy link
Contributor Author

I did a first-pass lookover.

Other things that need answering:

  1. What is the expected behavior when a module is allowed to start prior to GW2? How does this affect the load order?
  2. What happens when a user manually disables a dependency?
  3. What UI feedback is provided to the user to explain a module not enabled because of a dependency issue? Is it just the dependency section?
  1. Nothing, the same as prior to this PR. The dependent module needs to check for this case. In case of contexts: The state of Expired.
  2. No change. It is still the same as prior to the PR. Its only visible in the dependency section. I considered ScreenNotifications but I'm not sure if we want to potentially spam users.

@Tharylia
Copy link
Contributor Author

BlishHUD Module Load Order Test.zip

ModuleB registers a context and ModuleA is dependent on B as it wants to use it.

Steps:

  • Build both modules and place in modules folder
  • Start blish and start ModuleB and then ModuleA
  • See log for INFO | AnotherTest.ModuleA | Found context of module B. entry
  • Restart blish and wait for module A to load completely ( takes 30 seconds )
  • See log for INFO | AnotherTest.ModuleA | Could not find context of module B after 30 seconds.
  • Close blish
  • Prefix the module file "LoadOrderTest.bhm" with "00_" to make it first in list and simulate a different load order
  • Start blish
  • See log for INFO | AnotherTest.ModuleA | Found context of module B.

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

No Coverage information No Coverage information
0.0% 0.0% Duplication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants