[Bernard and Pradyun spoke on Feb 6 and Feb 7 to give Bernard an understanding of pip's architecture.]
Feb 6th
Pradyun/Bernard discussion, 6 Feb 2020
Which side of we want to start from? User-facing or broader architecture
At a reasonably high level, what are the moving parts of pip?
Software architecture:
- pip is for installing packages, like a car is going A-B. the main bits within pip are
- a chunk of logic for downloading the things we
- a chunk of logic for converting what we've downloaded into something we can install
- deciding amongst the things we see we should download and install
- final chunk for installing things
- one chunk for uninstalling things
- methods for see the environment - e.g. it's state, whats installed
- search - for discovering things - reading YAML files (pip search yaml)
The different parts of pip:
- env
- config files - saves the user having to express synat ever time (e.g., looking to user's own dev infra for downloading packages, etc)
cli - parsing user input syntax https://pip.pypa.io/en/stable/user_guide/#config-file
- implentation files -
https://pradyunsg.me/talks/slides/2019-python-packaging-overview.pdf -- some relevant notes
https://pradyunsg.me/talks/ -- has the video of the talk corresponding to those slides
Chunks of work (https://github.com/pypa/pip/milestone/10)
knowing what the key func is
figuring out if the way we printout of the output is useful
making the info message look less like error message to the users
making the error messages more helpful
give them tools to debug the problem
there is a tradeoff here - more error messages, the more complexity you add to the codebase. every detailed message needs to add code and this adds complexity to the codebase
which switches are useful? which are not?
How possible is it for us to map all the pip command journeys' flows? Essentially
Look at how long this is: https://pip.pypa.io/en/stable/reference/pip_install/ (complexity in pip's options)