Resolver Dev Syncup (28 April 2020)

Participants:
   * Paul
   * Pradyun
   * Tzu-Ping

Agenda:

 * pip 20.1 release
 * test failures
	 * https://trello.com/b/tydA30lP/new-resolver-for-pip-fix-the-failing-tests (maybe do not include in public notes?)
 * 20.1 and resolver work
	* Merge the existing resolver PRs into a single PR so we can sort out the merge conflicts in advance. Paul will do this.
		* Paul will take a look at his monolithic merged PRs branch's failures.
 * Visualization work
	* Update on work / discussion on the visualization design
	* Graphviz!!!
	* Paul: Looks good.
	* Tzu-Ping: Do we expect a random user to understand this graph?
		* Pradyun: no?
	* Q: Where does this fit in?
		* Pradyun: beside resolvelib. maybe?

	* https://github.com/sarugaku/resolvelib/issues/46#issuecomment-620106093

(bringing other discussions / past discussions)

 * pip upgrade package [package ...]
	* TP: Definitely better than `pip install --upgrade`—if we can ever convince the users :p
 * pip command to open project URL ( pypi.org/project/<name>/<version> ) to let the user have easy access to metadata.
	* TP: Think about this again, the setup.py I want to read is almost never the frontmost code on GitHub (that’s master, I want a specific version). A more viable solution would be for Warehouse to implement a “view content in sdist” page, and we link to that.
	* TP: Wiew wheel metadata is less useful because most people don’t understand Core Metadata format anyway
	* TODO: TP files a feature request to Warehouse

 * Paul: We should try to not distract ourselves away from the tedious work of fixing the test failures though.

 * When pip install fails, dump a “postmortem” in a file instead of cluttering the console
	* TP thinks this is a good idea, but we need to keep CI in mind (where the log file is not accessible, only the console)
	* NPM and Yarn both dump an error file on failures, but they still puts up verbose messages in the console
	* Pradyun: things to log:
		* choice made
		* discarding choice (backtracking)
		* note dependencies as discovered
		* I'm doing a download now! (TP thinks this is unnecessary)
	* Paul: More thinking about dumping the "state of the resolver" at the time of the exception for analysis
		* Dependency graph, in some serialised (machine readable) form.
			* TP It can be difficult to decide “which” graph to dump on multiple backtracking. Maybe dump the graph on each backtracking?
		* Discarded candidates, maybe, if resolvelib still has a record of them.