PackagingWG/2020-03-03-pip¶
Legacy Wiki Page
This page was migrated from the old MoinMoin-based wiki. Information may be outdated or no longer applicable. For current documentation, see python.org.
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{.backtick} for sanity checks on installationprepared{.backtick} 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{.backtick}TopoRequires packages
Next steps
TP works on wiring up the provider models to use InstallRequirement for metadata
Sync up on Thursday