Dev mini syncup
26 March 2020
Participants: Paul, Pradyun, Tzu-Ping
Agenda:
ignore_dependencies implementation https://github.com/pypa/pip/pull/7888
It works!
- Paul: wasn't expecting any issues. I'll catch up and merge; and deal with the merge conflicts.
- TP: One of the problems is that we need to add/remove/modify arguments on the same function.
- Paul: If we change that to partials, it'll simplify a bit. Avoiding too much coupling. Relatively simple to think about.
- Pradyun: LGTM; one minor comment on set comparison.
- TP: Can be a follow up PR.
Extras implementation https://github.com/pypa/pip/pull/7897
- Paul needs write the implementation idea down to avoid getting into the same loop every time.
- Paul: code seems fine to me.
- Invalid extras.
- To warn undefined extras you need to know the list of defined extras
- But to get a list of extras you need to prepare the dist, so we can’t warn as soon as we build the candidate
- We can warn on get_dependencies(), but what if we call it multiple times
- Cache the result (it’s not gonna change)
- Pradyun: It’s still better to warn multiple times than not warning at all
- Paul: Code currently doesn't have warning/logging mechanisms imported.
Paul: I'll put it in logger.warning()
- A test on extra merging
- Needed at some point, but not at the simple test case stage we’re in now
- Paul: Expects Ilan will come in for this
- Need to better understand how Ilan fits into the rest of the work here.
Requires-Python prototype needs at least one interface tweak https://github.com/pypa/pip/pull/7889
- Order of work: ignore_dependencies, extras, refactoring for decoupling, then this.
Need to change get_dependencies() implementation as well
Use installed dist: ignore_installed and force_reinstall https://github.com/pypa/pip/projects/5#card-35032881
InstalledProjectCandidate
- Refactoring of "make_candidate" will help.
InstallProjectCandidate would have a very different interface -- no links.
- Again, it shouldn't be too difficult; but it's all prep work for the actual implementation.
- Paul: treated with the right priority [inaudible]
- Pradyun: Also need to think about how it fits in with priorities
- Paul: Thinking about how to implement the flags, once we have a concrete candidate
- TP: Agree with Paul; priorities is next topic!
- Refactoring of "make_candidate" will help.
Is it time to talk about upgrade_strategy again? (Probably not yet.)
We'll talk about this priorities and upgrade_strategy later, once there is an implementation.
- Broader resolution debugging ideas!
- visualizing the exploration?
- E.g. resolver revisting a candidate when it shouldn’t, it would be easier to debug if we have a way to dump the state from the resolvelib side and then generate something to visualize that.
- This is where reporter comes into play.
- Pradyun: The problem of UI and debuggability are *very* close.
- Paul: The reporter object should be able to do both (report things to the user, and dump state to the implementer)
- Paul: Last time I needed to do something like this, I put prints in code.
TP: Where did you put the "print" -- that's probably a good place to report.
- Paul: put them on the Provider.
Another useful thing would be to add better __repr__ and __str__ on our Requirement/Candidate objects
- Time's up! Team meeting time!
- TODO: Travis CI
- BTW why is Travis stalling so much recently
- :shrug: I don't know!
- BTW why is Travis stalling so much recently
End of meeting.