Direct dependency on service provider modules? was: Service provider module dependency resolving webrev

[Jaroslav Tulach]

Dne St 20. června 2012 17:42:44, Paul Sandoz napsal(a):
> 
> >> - service provider modules dependencies are resolved after the explicit
> >> dependencies have been successfully resolved.
> > 
> > This part can be made easy with complete repository[1].
> 
> Would you be able to elaborate in layman's terms?

Paul, please excuse me for not expressing myself clearly: I wanted to say that 
"resolving explicit dependencies" can be made easy with complete 
repository[1]. It is the easy/easier part.

Resolving later the service provider modules will then be the hard part.

> I think i might grok it: we essentially treat each service provider module
> dependency as a direct (or top-level) dependency.

Do you say that "require service xyz" declaration would mean to enable all 
modules which "provide service xyz with something"? E.g. like saying that a 
module that "require service xyz" has a direct dependency on all modules that 
"provide service xyz".

That is radical approach. It can work if the set of modules is properly 
selected at beginning (e.g. NetBeans IDE version 7.2 without external modules, 
or Ubuntu 12.04 release) - and we know all modules that "provide service xyz" 
can in fact be linked under (almost) all situations. 

But if you apply the same rule to a collection of modules with history, 
provided by various parties (e.g. Maven Central), than it is very limiting - 
there will always be at least one module that "provides service xyz" and it 
cannot be enabled. Then the whole resolution should collapse, right?

The approach with "direct dependency on each service provider" certainly 
eliminates the NP-complete problem. But it suffers from the fact that it is 
not very usable. Unless the set of modules is carefully pre-selected by humans 
(e.g. humans solve the NP-completeness first) it almost certainly leads to 
"can't resolve" results all over.

An interesting property of "treating each service provider module dependency 
as direct" is that one can break the system by installing new module! E.g. 
your module which "requires service xyz" can be resolved. By installing new 
module which "provide service xyz" and is unresolvable (for any reasons) and 
the original module won't resolve any more either. How do you like this 
(mis)behavior?

> >>  - if service provider modules or their dependencies are service consumer
> >> 
> >> modules then the correspond service provide modules are resolved after
> >> the
> >> explicit dependences and so on.
> > 
> > In this step you have to select one of the modules that "provides a
> > service" which has been requested by some module in the first step. This
> > is the part when the algorithm turns into 3-SAT solver.
> 
> I would very like to do a mind meld with you on this!
> 
> It's interesting in that, with the current Resolver implementation, when you
> push service provider module dependency resolution to the end then there is
> no longer any backtracking above those dependencies, since they are
> optional.

Are they really optional? What is optional on "requires service xyz"? But...

Heuréka! I think I know how to overcome the NP-complete problem with services. 
We need to make sure we make the dependencies optional. E.g. there are no NP-
complete problems with "requires service optional xyz". Thus, if we allow only 
optional services, we simplify everything a lot. 

Of course, some "requires service" are not that optional. So the question for 
me is: how to make the dependency system usable and still pretend all services 
are in fact optional?

> Which i think means one can break things down into ordered sub-phases
> resolving the dependencies of each service provider module (which IIUC is
> still NP-Complete as you point out). That may make it easier to report
> service provider module dependency resolution issues to the developer.
> > No surprise, things may get unclear and complicated (which is how I
> > understood your further discussion with Alan).
> 
> Yes, i am trying to run the resolver in my head. It's concerns me if
> developers have to do the same.

;-)

Well, people can do this on a small system (e.g. distribution). They have 
their ideal vision and see the whole picture. They just need a language (e.g. 
requires/provides/service/optional) to describe such vision. 

The problem arises when few such small systems are combined together (e.g. 
Maven central). No human is able to see the whole picture then, still we want 
computers to operate on such mess effectively.

-jt