SPEAKER: So, yeah I was going to talk about test,
but I decided that that was kind of boring.
I'm happy to talk your ear off about it in person.
But I think a better lightning talk
would be the work that I've been doing
on Pub's versions solver, which I think is really, really cool.
So I don't know how many of you have used Pub before.
It Dart's package manager.
Way back in the day, Bob and I worked on a version solver
for it, which is the chunk of code that
takes your set of dependencies declared in your Pub spec
and looks up all of those packages,
looks up all of their dependencies,
and figures out a group of packages
that satisfies every dependency in every transitive package,
while also ensuring that all of the root packages' dependencies
are satisfied.
It turns out that this is a really hard problem.
Those of you familiar with complexity theory
might know it as MP hard.
Those of you who are not, trust me it's really, really hard.
We got a pretty decent solution working
that's sort of based on what a lot of other package managers
do.
But one problem that many of you have probably run into
is that the errors it reports are not very good.
Kevin brought this up in his talk earlier.
So my new algorithm is designed to solve that.
And I think it does it in a pretty clever way.
So instead of sort of thinking about it
as just a list of package versions to try
and thinking about hopping back to old versions that failed
and trying different versions of those
and trying different versions of all the other packages in case
that changed something, the way it works now,
is it thinks about it in terms of facts about the world
that it knows are true.
So these are facts like, if you depend on package foo,
then you must also depend on this version
range of package bar.
Or facts like package [? kwuks ?]
is incompatible with package quack.
So you can take these facts about the world, which
you can start off by generating from the Pub spec,
and use a pretty straightforward process
of taking decisions you've already
made about which packages to select,
figuring out which packages are forced by that.
Like, if you have package foo selected,
that means that you definitely need at least this range
of package bar.
Eventually, you might run into a conflict,
because sometimes you're making decisions arbitrarily
based on which package ranges are unsatisfied.
The really clever thing about this new algorithm
is when it encounters a conflict,
it doesn't just go back to where the conflict happened
and make a different decision.
It actually looks at the facts that
caused this conflict to happen and combines
them using sophisticated logic programming to come up
with a new fact about the world that
is sort of heuristically representing the root
cause of that conflict.
So for example, if you have package foo that
depends on package bar and package bar depends
on package baz, and package baz doesn't match your current SDK
constraints, it will actually be able to figure out, well, OK,
package baz can't be selected.
The reason we selected package baz was because bar
depended on it.
So bar can't be selected.
The reason we have selected bar was because foo depended on it.
So foo can't be selected.
And then it'll remember that this range of versions of foo
can't be selected ever, and it won't ever
try to select them again.
The really cool thing about this,
in addition to just making the version solving faster,
is it takes these facts, and if it
runs into a conflict that can't be solved, where there are
no more versions of packages left to try, it can actually
figure out, OK, why did this fact that says there are
no possible versions that could ever
solve this package [? graph, ?] why was this fact generated?
What two previous facts did we combine,
using sophisticated logic programming,
to create this new fact?
Why did those facts exist?
And eventually it'll get back to the dependencies that
are declared in your Pub spec.
And it will be able to report that to you as just plain text
and say, these are exactly the reasons
why we couldn't find anything.
So I'm hoping to release this in Pub sometime this quarter.
So keep an eye out.
[APPLAUSE]