1 files changed, 27 insertions, 0 deletions
diff --git a/bpkg/conditional-dependencies b/bpkg/conditional-dependencies
new file mode 100644
index 0000000..5d1015d
--- /dev/null
+++ b/bpkg/conditional-dependencies
@@ -0,0 +1,27 @@
+- Support for conditional dependencies [feature]
+
+In a nutshell, a package may or may not depend on another package and, in the
+worst case scenario, this can be ascertained only during configuration. As a
+result, an iterative approach seems like the way to implement this.
+
+That is, initially, bpkg assumes that a conditional dependency is not
+necessary and tries to configure the package without it. It also runs build2
+in the "failed import discovery mode". In this mode build2 outputs to stdout
+all the failed imports (maybe all imports?) and exits with non-zero status.
+We will also need to limit imports to stage 1 only since we don't want
+conditional dependencies to be found as installed [this needs more thinking;
+feels like a special case hack at the moment].
+
+What if the conditional dependency is already in the configuration? We need
+to prevent build2 from using it. Looks like that empty import override idea
+will do the trick.
+
+This process will only discover one conditional dependency per package at a
+time which may make the whole thing quite tedious. Not sure what we can do
+here since we cannot continue processing a buildfile if we failed to import a
+project. Or do we? If we fail to find a build2 project we delegate it to the
+rule. So as long as we don't match rules, we are good and can discover all the
+failed imports. BTW, an alternative model would be a true import intercept
+where we build conditional dependencies as part of the import hook call. The
+bad part about this approach is that we cannot show the user the plan for
+extra packages we need to build. It is a lot more complex.