Dev mini syncup

8 April 2020

Participants: Paul, Pradyun, Tzu-Ping

• Agenda
  • Error messages and reporting / New resolver output messages
    • - How much do we need to replicate the old resolver’s output?
      • - As long as it makes sense, otherwise we don’t need to follow verbatim
      • - The old resolver outputs "aleady installed" at the start (checking whether to install) new would do it at the end
      • - We probably can't get things exactly the same
      • - Maybe we just add messages and see where it gets us?
      • - Any way to "tag" new resolver messages? (Pradyun) there's a PR for that
        • - probably over-engineering, let's just see how plain messages look for now.
      • - What should even be printed?
        • - Building in pip download.
  • Digression into pip's CLI
    • Do we actually know if there's an actual problem w/ the new resolver?
    • Paul: I'll just try and see how pip download works after call.
    • TP: I want to add a test to ensure the resolver prepares sdist and source correctly in --no-deps mode
  • Upgrade Strategies
    • How would we implement the different upgrade strategies? (not the behavior, but implementation / code)
    • Paul: Implement them in find_matches()
    • to-satisfy-only: Return a single-element list containing the installed dist
    • only-if-needed: Carefully order the already-installed dist to the end of the list (highest priority)
    • eager: What we’re doing right now
    • Paul: I'll pick this up...?
      • Hide some stuff behind if False:
  • Code structure
    • Looks fine
    • TP: The only thing I would consider moving is get_dependencies()
    • Pradyun: Wants to thin out models, closer to plain data objects
    • Paul: Requirements are simple, candidates are messy
    • Let’s revisit this once in a while and see what we think
  • Installed Packages causing conflicts
    • eager: Nothing to change, just upgrade anything if it wants to
      • One question: this is an "upgrade-strategy" to upgrade eagerly. Should we downgrade?
      • Paul: how about an allow-downgrade option? This will vastly reduce the candidate search size as well
      • The name “upgrade-strategy” give the user expectation
        • Rename it --version-strategy or something? But that has much more implications
      • We should bring this up at the UX meeting
    • to-satisfy-only:
  • canonicalize_name()
    • Just wait for packaging to fix those types and maybe we get a release, vendor it eagerly, and work from there
  • User testing:
    • - Should we error out proactively so that users in the beta have to ask for functionality and discuss their needs with us?
    • - Maybe don't implement upgrade strategy for beta, on that basis.
    • - Skip implementing "eager", just to-satisfy-only (pip install) and only-if-needed (pip install --upgrade)
    • Review upgrade strategies, get feedback from user research.
  • pip install a, a depends on c 2.0, already installed b and c where b depends on c 1.0
    • - error or upgrade?
    • - Paul: error, but give the user an option to say "it's OK to upgrade". Is that one of the upgrade strategies?
    • Do we have use cases for relaxing the graph?
      • - The a, b depend on different versions of c down

      • - this case https://lwn.net/Articles/816044/

      • - numpy, user has a carefully crafted build installed
      • - bad metadata. Overrides can be considered as something we should have a standardised metadata override mechanism for.
        • - To put it another way, treat it as YAGNI for now.
      • - Manifest, lock file, etc.
        • - Let’s finish this resolver thing so we can work on those
  • Beta release automation
    • Doable (looks like)!
  • Moar weekly calls

    • w/ UX folks for figuring out UI/UX stuff with them.

And:

• Pradyun needs more sleep! (yes!)