More refactoring.

notes/architecture.md

@@ -13,14 +13,16 @@ requirements are met.
 
 Then we attempt to build.
 
-If any problems are found in the log, buildlog-consultant will report them.
+If any Problems are found in the log, buildlog-consultant will report them.
 
-ognibuild can then invoke "fixers" to address Problems.
+ognibuild can then invoke "fixers" to address Problems. Fixers can do things
+like e.g. upgrade configure.ac to a newer version, or invoke autoreconf.
+
+A list of possible fixers can be provided. Each fixer will be called
+(in order) until one of them claims to ahve fixed the issue.
 
 Problems can be converted to UpstreamRequirements by UpstreamRequirementFixer
 
-Other Fixer can do things like e.g. upgrade configure.ac to a newer version.
-
 UpstreamRequirementFixer uses a UpstreamRequirementResolver object that
 can translate UpstreamRequirement objects into apt package names or
 e.g. cpan commands.
@@ -28,3 +30,22 @@ e.g. cpan commands.
 ognibuild keeps finding problems, resolving them and rebuilding until it finds
 a problem it can not resolve or that it thinks it has already resolved
 (i.e. seen before).
+
+Operations are run in a Session - this can represent a virtualized
+environment of some sort (e.g. a chroot or virtualenv) or simply
+on the host machine.
+
+For e.g. PerlModuleRequirement, need to be able to:
+
+ * install from apt package
+  + DebianInstallFixer(AptResolver()).fix(problem)
+ * update debian package (source, runtime, test) deps to include apt package
+  + DebianPackageDepFixer(AptResolver()).fix(problem, ('test', 'foo'))
+ * suggest command to run to install from apt package
+  + DebianInstallFixer(AptResolver()).command(problem)
+ * install from cpan
+  + CpanInstallFixer().fix(problem)
+ * suggest command to run to install from cpan package
+  + CpanInstallFixer().command(problem)
+ * update source package reqs to depend on perl module
+  + PerlDepFixer().fix(problem)

notes/roadmap.md

@@ -0,0 +1,44 @@
+class UpstreamRequirement(object):
+
+    family: str
+
+
+class PythonPackageRequirement(UpstreamRequirement):
+
+    package: str
+
+
+SetupPy.get_build_requirements() yields some PythonPackageRequirement objects
+
+apt_resolver.install([PythonPackageRequirement(...)]) then:
+
+ * needs to translate to apt package name
+
+
+Once we find errors during build, buildlog consultant extracts them ("MissingPythonPackage", "configure.ac needs updating").
+
+fix_build then takes the problem found and converts it to an action:
+
+ * modifying some of the source files
+ * resolving requirements
+
+Resolving requirements dependencies means creating e.g. a PythonPackageRequirement() object and feeding it to resolver.install()
+
+we have specific handlers for each kind of thingy
+
+resolver.install() needs to translate the upstream information to an apt name or a cpan name or update dependencies or raise an exception or..
+
+MissingPythonPackage() -> PythonPackageRequirement()
+
+PythonPackageRequirement() can either:
+
+ * directly provide apt names, if they are known
+ * look up apt names
+
+We specifically want to support multiple resolvers. In some cases a resolver can't deal with a particular kind of requirement.
+
+Who is responsible for taking a PythonPackageRequirement and translating it to an apt package name?
+
+ 1) PythonPackageRequirement itself? That would mean knowledge about package naming etc, is with the requirement object, which seems wrong.
+ 2) PythonPackageRequirement.apt_name(apt_archive) - i.e. find the package name given an archive object of some sort
+ 3) The apt resolver has a list of callbacks to map requirements to apt package names