11 May

Participants:
 * Paul
 * Pradyun
 * TP

Agenda:

- Pradyun is happy that someone else closed the meeting notes like he's been doing for so long! (with [syntax])

- UX + Pradyun syncups!
	* Circular dependency figured out
	* UX team + Ilan will collect test cases
	* Main problem now:
		What metrics to use for the “too complicated” error?
		* TP: Maximum versions tried per package, sounds perfect!
			Everyone agrees.
			Paul: Doesn't sound like it'd be too difficult in resolvelib.
		* Paul: When we do the finder logic in the provider, there's never any reason we'd return 2 compatible ones.
			* will ask on Zulip, since this is a bigger topic that might not need much discussion or need lots of discussion. :)

- !PubGrub:
	* TP: Was reading !PubGrub before this call. Current takeaway is that Python specifiers is missing -- negation: `Django > 3.0` to `Django <= 3.0`. We'd need to implement negation (non trivial!)
	* TP: Implementing incompatibility tracking would be better; since it's significantly faster.
	* TP: Does not make sense to switch to !PubGrub now (Python packaging logic lacks negation, which is essential for PubGrub)

- What are we working on next?

	* Paul: Couple/Three of things
		* Tidying up anything that comes out of the constraints issue (2 failing tests that TP found)
			* As long as it works for !OpenStack, what we should do is remove those tests, and declare that constraints aren't meant to do that anyway.
			* Will add / improve documentation.
				* Only valid as `"project <= version"` and similar forms.
				* Pradyun: Validation?
					* Paul: Don't want to get side-tracked by that entire discussion -- will do if it's easy. Will come back with "let's not bother" if it's hard.
		* Documentation of update mode (reminded by an issue mention/notification)
			* Will have another pass.
			* Wanna get some writeup that talks about what we do. The longer I take, the more annoyed at this situation.
			* Wanna be less annoyed at how complicated it is!
		* Refactoring Requirements-bit, so that they're on the provider instead.
			* It also makes sense to move `upgrade_strategy`.
			* Have the factory be responsible for get the candidates from Finder.
			* Provider puts them in the correct order.
			* All ordering logic in Provider. All internal-interaction with Factory.
				* Pradyun: we should document this structure is being taken.
				* TP: since we need to rewrite `find_matches`, I was planning on adding a new class for it -- your plan sounds equally good.
				* Paul: This is where the question about more-than-one-candidate-per-question.
			* Particularly, when it's doing the matching by versions etc in the sorting.
			* It might be easier if the factory to return 1 candidate per version.
			* [Pradyun (note taker) got distracted/zoned out]
			* Paul: That sounds like what we wanna do.

	* TP:
		* Yanked
			* depends on https://github.com/pypa/pip/pull/8066
		* `find_matches()` rewrite
			* Might conflict with Paul's planned refactor.
			* Paul: Tell me to stop, if there's conflicts.
			* TP: I will likely be introducing a new class.
		* TP: need to look at the tests.
		* Pradyun: we should look at all the issues, and write down something about this.
			* Paul: would be really nice.
			* TP: I tried doing that -- I got stuck on the constraints
			* [we talk about how we get stuck while doing this -- it's horrible or I can try this (few minutes later) this is horrible]
			* while we're looking at the tests, it would be nice to finally thrash out how "old resolver test" vs "new resolver" tests should work.
				* might be check the environment.
				* Add a `--new-resolver` option in pytest and check that throughout the suite
					* interaction with YAML tests

	* Pradyun

		* Actually triage issues (lol)
			* Did a bit last week, but had to walk away after getting frustrated with the in-place builds responses (and landing on #5599).
		* Get 20.1.1 out.
			* Reverting in-place-builds.
				* PR
				* Paul: we've got to do it, because of the issues.
					* We've had a couple of people who've come in and say "this is cool!"
					* Should give a heads up to those people.
					* Reopen issues, telling people why we had to do the revert.
					* Paul to do this on one issue. Pradyun will copy-paste on others, after reverting.
		* Wrap up visualization stuff
			* Put it in a library / tool, instead of a bunch of file in my local resolvelib.
		* Look at the failures
			* Note down what's happening here.
			* Need to put a clock or something, to keep me from digging too deep.
		* Look into the `.[extras]` (stretch goal)

		* TP: I'd be very impressed if you make it past the first 2 bullets this week.
		* Paul: Yea, that's a lot of stuff.

 * Constraints -- covered above