earlier meeting of resolver team
Paul / Pradyun / Tzu-Ping
Paul: Deep dive into InstallRequirement
- What happens when you create a requirement (all three kinds)
- Also worth documenting in the architecture docs
TP: Re-implement Python-related tests from ResolveLib to pip
- Based on Paul's initial test fixtures and pip's YAML test infrastructure
TP: Go with the current prototype models for candidate
Paul: still thinks it’s possible to not use InstallRequirement for the requirement part
- Likely to have a decision after the deep-dive
Front-end UI:
Pradyun: Conda feels to strict (and also slower because SAT) so people fall back to pip when "needed"
- But the new resolver will be slower than Conda
- Some people want to be able to ignore an edge if the resolver has conflicts
- We can limit ourselves to only a subset of the graph and avoid doing confusing things.
Are people OK with running pip multiple times? May be an approach to complex scenarios, but currently users push back over splitting requirements files.
- We may want to be explicit that some problems will need multi-stage installs.
Making sure we put some sort of logging into the new provider, so we can track how often does it do things e.g. re-prepare requirements that slow things down.
Better way of describing whole environment - out of scope here, mostly for higher level tools.
Communication:
- Need a way to describe what we are doing with the new resolver to scale down people's expectations.
- pip will not magically be able to read users' minds and do the right thing when it isn't right now
- We'll need to involve Sumana in this, and provide the topics we want to send across to the users
Mini-syncup (PG/PM/TP):
- 9:00 GMT 17:00 Taipei 2:30pm Mumbai Tue, Wed and 30 min before the Thu meeting
March 3rd mini-syncup of resolver team
Mini-syncup, 3 Mar 2020
Paul / Tzu-ping
- Paul came back from the abyss
Resolver can probably use InstallRequirement. Need to make sure everything that install needs gets set up. Paul to check that this week.
Go forward with Pradyun’s idea to implement both Requirement and Candidate as InstallRequirement wrappers
“Clone” the internal InstallRequirement when generating Candidates from Requirement
- No roadblocks from what Paul can tell
Need to remember setting is_direct for sanity checks on installation
prepared is not used anywhere (except in the legacy resolver internally) so we’re probably fine
- Organising the tests (TP)
- Add a environment variable to flip the resolver implementations, and make sure the new one passes on CI
- Any existing packages to test for dependency resolution?
tests/function/test_yaml.py
TopoRequires packages
- Next steps
TP works on wiring up the provider models to use InstallRequirement for metadata
- Sync up on Thursday