<div dir="ltr">I apologize for the duplicate mail. Please respond on this thread.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 25 Mar 2017 at 21:16 Pradyun Gedam <<a href="mailto:pradyunsg@gmail.com">pradyunsg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Hello Everyone!<br class="gmail_msg"><br class="gmail_msg">I had previously sent a mail on this list, stating that I would like to work on pip's dependency resolution for my GSoC 2017. I now have drafted a proposal for the same; with help from my mentors - Donald Stufft and Justin Cappos. I'd also take this opportunity to thank them for agreeing to be my mentors for this GSoC.<br class="gmail_msg"><br class="gmail_msg">I would like to request for comments on my proposal for GSoC - it is hosted at <a href="https://gist.github.com/pradyunsg/5cf4a35b81f08b6432f280aba6f511eb" class="gmail_msg" target="_blank">https://gist.github.com/pradyunsg/5cf4a35b81f08b6432f280aba6f511eb</a>.<br class="gmail_msg"><br class="gmail_msg">Please find trailing a MarkDown version of the proposal.<br class="gmail_msg"><br class="gmail_msg">Thanks,<br class="gmail_msg">Pradyun Gedam<br class="gmail_msg"><br class="gmail_msg">-----<br class="gmail_msg"><br class="gmail_msg"># Adding Proper Dependency Resolution to pip<br class="gmail_msg"><br class="gmail_msg">- **Name:** Pradyun S. Gedam<br class="gmail_msg">- **Email:** [<a href="mailto:pradyunsg@gmail.com" class="gmail_msg" target="_blank">pradyunsg@gmail.com</a>][mailto-email]<br class="gmail_msg">- **Github:** [pradyunsg][github-profile]<br class="gmail_msg">- **University:** [VIT University, Vellore, India][vit-homepage]<br class="gmail_msg">- **Course:** Bachelor of Technology in Computer Science and Engineering<br class="gmail_msg">- **Course Term:** 2016/17 - 2019/20 (4 Year)<br class="gmail_msg">- **Timezone:** IST (GMT +5:30)<br class="gmail_msg">- **GSoC Blog RSS Feed URL:** <<a href="https://pradyunsg.github.io/gsoc-2017/feed.xml" class="gmail_msg" target="_blank">https://pradyunsg.github.io/gsoc-2017/feed.xml</a>><br class="gmail_msg"><br class="gmail_msg">[github-profile]: <a href="http://github.com/pradyunsg/" class="gmail_msg" target="_blank">http://github.com/pradyunsg/</a><br class="gmail_msg">[vit-homepage]: <a href="http://vit.ac.in/" class="gmail_msg" target="_blank">http://vit.ac.in/</a><br class="gmail_msg">[mailto-email]: mailto:<a href="mailto:pradyunsg@gmail.com" class="gmail_msg" target="_blank">pradyunsg@gmail.com</a><br class="gmail_msg"><br class="gmail_msg">## About Me<br class="gmail_msg"><br class="gmail_msg">I was introduced to Python about five years ago, through "Core Python<br class="gmail_msg">Programming" by Weasley J Chun. After the initial struggle with Python 2/3, the<br class="gmail_msg">ball was set rolling and hasn't stopped since. I have fiddled around with<br class="gmail_msg">Game Programming (PyGame), Computer Vision (OpenCV), Data Analytics (Pandas,<br class="gmail_msg">SciPy, NumPy), transcompilers (Py2C) and more.<br class="gmail_msg"><br class="gmail_msg">As a high school student, I did internship at Enthought in 2013 and 2014.<br class="gmail_msg">The two summers that I spent at Enthought were a great learning experience and<br class="gmail_msg">I thoroughly enjoyed the environment there.<br class="gmail_msg"><br class="gmail_msg">Other than Python, I have also used C, C++, Web Technologies (JavaScript, HTML,<br class="gmail_msg">CSS) and preprocessors (Pug, TypeScript, LESS/SASS/SCSS), Java and Bash/Zsh for<br class="gmail_msg">some other projects.<br class="gmail_msg"><br class="gmail_msg">Curious to understand how pip works, I began looking into pip's source code.<br class="gmail_msg">I started contributing to pip in May 2016. I am now fairly familiar with the<br class="gmail_msg">design of pip and have a fair understanding of how it works, due to the various<br class="gmail_msg">contributions I have made to pip in the past year.<br class="gmail_msg"><br class="gmail_msg">## Mentors<br class="gmail_msg"><br class="gmail_msg">- Donald Stufft (@dstufft on GitHub)<br class="gmail_msg">- Justin Cappos (@JustinCappos on GitHub)<br class="gmail_msg"><br class="gmail_msg">Communication with the mentors will be done mostly on issues and pull requests<br class="gmail_msg">on pip's GitHub repository. If at any point in time, a real time discussion is<br class="gmail_msg">to be done with the mentors, it would be done over IRC or Skype. Email can also<br class="gmail_msg">be used if needed.<br class="gmail_msg"><br class="gmail_msg">## Proposal<br class="gmail_msg"><br class="gmail_msg">This project is regarding improving dependency resolution performed within pip<br class="gmail_msg">by implementing a dependency resolver within it.<br class="gmail_msg"><br class="gmail_msg">### Abstract<br class="gmail_msg"><br class="gmail_msg">Currently, pip does not resolve dependencies correctly when there are<br class="gmail_msg">conflicting requirements. The lack of dependency resolution has caused<br class="gmail_msg">hard-to-debug bugs/failures due to the installation of incompatible packages.<br class="gmail_msg">The lack of a dependency resolver is also a blocker for various other features -<br class="gmail_msg">adding an upgrade-all functionality to pip and properly determining build-time<br class="gmail_msg">dependencies for packages are two such features.<br class="gmail_msg"><br class="gmail_msg">### Deliverables<br class="gmail_msg"><br class="gmail_msg">At the end of this project, pip will have the ability to:<br class="gmail_msg"><br class="gmail_msg">- detect requirement conflicts<br class="gmail_msg">- resolve conflicting dependency requirements where possible<br class="gmail_msg"><br class="gmail_msg">### Implementation<br class="gmail_msg"><br class="gmail_msg">The implementation language will be Python. The code will maintain the<br class="gmail_msg">compatibility requirements of pip - the same source code will support the<br class="gmail_msg">multiple Python implementations and version, including but not limited to,<br class="gmail_msg">CPython 2.7, CPython 3.3+, PyPy 2, PyPy3.<br class="gmail_msg"><br class="gmail_msg">New Tests for the functionality introduced will be added to pip's current test<br class="gmail_msg">suite.<br class="gmail_msg"><br class="gmail_msg">User documentation would not be a major part of this project. The only changes<br class="gmail_msg">would be to mention pip can now resolve dependencies properly. There are certain<br class="gmail_msg">sections that might need updating.<br class="gmail_msg"><br class="gmail_msg">#### Overview<br class="gmail_msg"><br class="gmail_msg">The project will be composed of the following stages:<br class="gmail_msg"><br class="gmail_msg">1. Refactor the dependency resolution logic of pip into a separate module.<br class="gmail_msg">1. Implement dependency information caching in pip.<br class="gmail_msg">1. Implement a backtracking dependency resolver to resolve the dependencies.<br class="gmail_msg"><br class="gmail_msg">Every stage depends on the previous ones being completed. This step-wise<br class="gmail_msg">approach would make incremental improvements so that there is a constant<br class="gmail_msg">feedback on the work being done as well as making it easy to change course<br class="gmail_msg">without losing existing work; if needed for some unforeseen reason.<br class="gmail_msg"><br class="gmail_msg">#### Discussion<br class="gmail_msg"><br class="gmail_msg">There is a class in pip - `RequirementSet`, which is currently a God class. It<br class="gmail_msg">is responsible for the following:<br class="gmail_msg"><br class="gmail_msg">  1. Holding a list of things to be installed<br class="gmail_msg">  1. Downloading Files<br class="gmail_msg">  1. Dependency Resolution<br class="gmail_msg">  1. Unpacking downloaded files (preparation for installation)<br class="gmail_msg">  1. Uninstalling packages<br class="gmail_msg">  1. Installing packages<br class="gmail_msg"><br class="gmail_msg">This is clearly a bad situation since this is most of the heavy lifting<br class="gmail_msg">involved in pip. These responsibilities need to be separated and moved out into<br class="gmail_msg">their independent modules/classes, to allow for simplification of<br class="gmail_msg">`RequirementSet` while providing a clean platform for the remaining work.<br class="gmail_msg">This is the most tricky portion of this project, given the complexity of<br class="gmail_msg">`RequirementSet` as it stands today.<br class="gmail_msg"><br class="gmail_msg">There are two kinds of distributions that may be used to install a package -<br class="gmail_msg">wheels (binary) and sdists (source). When installing a package, pip builds a<br class="gmail_msg">wheel from an sdist and then proceeds to install the wheel. The difference<br class="gmail_msg">between the two formats of distribution relevant to this project is - wheels<br class="gmail_msg">store the information about dependencies within them statically; sdists do not.<br class="gmail_msg"><br class="gmail_msg">Determining the dependencies of a wheel distribution is merely the matter of<br class="gmail_msg">fetching the information from a METADATA file within the `.whl` file. The<br class="gmail_msg">dependency information for an sdist, on the other hand, can only be determined<br class="gmail_msg">after running its `setup.py` file on the target system. This means that<br class="gmail_msg">dependencies of an sdist depend on how its `setup.py` behaves which can change<br class="gmail_msg">due to variations on target systems or could even contain through random<br class="gmail_msg">choices.<br class="gmail_msg"><br class="gmail_msg">Computation of an sdist's dependencies on the target system is a time-consuming<br class="gmail_msg">task since it potentially involves fetching a package from PyPI and executing<br class="gmail_msg">it's setup.py to get the dependency information. In order to improve<br class="gmail_msg">performance, once an sdist's dependencies are computed, they would be stored in<br class="gmail_msg">a cache so that during dependency resolution, the dependencies of an sdist are<br class="gmail_msg">not computed every time they are needed. Further, pip caches wheels it<br class="gmail_msg">downloads or builds meaning that any installed package or downloaded wheel's<br class="gmail_msg">dependency information would available statically, without the need to go<br class="gmail_msg">through the sdist dependency cache.<br class="gmail_msg"><br class="gmail_msg">Like the wheel cache, sdist-dependency-cache will be a file system based cache.<br class="gmail_msg">The sdist-dependency-cache would only be used if the corresponding sdist is<br class="gmail_msg">being used.<br class="gmail_msg"><br class="gmail_msg">Since sdist dependencies are non-deterministic, the cached dependency<br class="gmail_msg">information is potentially incorrect - in certain corner cases such as using<br class="gmail_msg">random choices in setup.py files. Such uses are not seen as important enough to<br class="gmail_msg">cater to, compared the benefits of having a cache. Further, this is already the<br class="gmail_msg">case with the information in the wheel cache.<br class="gmail_msg"><br class="gmail_msg">SAT solver based resolution is not feasible for pip since a SAT solver needs<br class="gmail_msg">the entire set of packages and their dependencies to compute a solution, which<br class="gmail_msg">cannot be generated due to the aforementioned non-deterministic behaviour of<br class="gmail_msg">setup.py file. Computing dependency information for all of PyPI on a target<br class="gmail_msg">system for installing a package is simply not feasible.<br class="gmail_msg"><br class="gmail_msg">The most reasonable approach is using a backtracking solver. Such a solver can<br class="gmail_msg">be incrementally provided information about the dependencies of a package and<br class="gmail_msg">would only need dependency information about packages in the dependency graph<br class="gmail_msg">of the current system.<br class="gmail_msg"><br class="gmail_msg">There is a need to keep a cache of visited packages during dependency<br class="gmail_msg">resolution. A certain package-version combination may be reached via multiple<br class="gmail_msg">paths and it is an inefficient use of computation time to re-compute that<br class="gmail_msg">whether it is indeed going to satisfy the requirements or not. By storing<br class="gmail_msg">information about which package-version combinations have been visited and do<br class="gmail_msg">(or do not) satisfy the constraints, it is possible to speedup the resolution.<br class="gmail_msg"><br class="gmail_msg">Consider the following example:<br class="gmail_msg"><br class="gmail_msg">```<br class="gmail_msg">A-1.0 (depends: B)<br class="gmail_msg">A-2.0 (depends: B and E-1.0)<br class="gmail_msg">B-1.0 (depends: C and D)<br class="gmail_msg">C-1.0 (depends: D)<br class="gmail_msg">D-1.0<br class="gmail_msg">D-1.1 (depends: E-2.0)<br class="gmail_msg">E-1.0<br class="gmail_msg">E-2.0<br class="gmail_msg">```<br class="gmail_msg"><br class="gmail_msg">If an installation of A is required, either A-2.0 or D-1.1 should not be<br class="gmail_msg">installed because they have a conflicting requirement - E. While there are<br class="gmail_msg">multiple possible solutions to this situation, the "most obvious" one us to use<br class="gmail_msg">the D-1.0, instead of not installing A-2.0. Further, as multiple packages<br class="gmail_msg">depend on D, the algorithm would "reach it" multiple times. By maintaining a<br class="gmail_msg">cache for the visited packages, it is possible to achieve a speedup in such a<br class="gmail_msg">scenario.<br class="gmail_msg"><br class="gmail_msg">#### Details<br class="gmail_msg"><br class="gmail_msg">Pull requests would be made on a regular basis during the project to ensure<br class="gmail_msg">that the feedback loop is quick. This also reduces the possibilities of<br class="gmail_msg">conflicts due to unrelated changes in pip.<br class="gmail_msg"><br class="gmail_msg">All the code will be tested within pip's existing testing infrastructure. It<br class="gmail_msg">has everything needed to write tests related to all the changes to be made.<br class="gmail_msg">Every PR made to pip as a part of this project will contain new tests or<br class="gmail_msg">modifications to existing ones as needed.<br class="gmail_msg"><br class="gmail_msg">##### Stage 1<br class="gmail_msg"><br class="gmail_msg">Initially, some abstractions will be introduced to the pip codebase to improve<br class="gmail_msg">the reuse of certain common patterns within the codebase. This includes cleaner<br class="gmail_msg">temporary directory management through a `TempDirectory` class.<br class="gmail_msg"><br class="gmail_msg">`RequirementSet.prepare_files` and `RequirementSet._prepare_file` are<br class="gmail_msg">downloading, unpacking packages as well as doing what pip does as dependency<br class="gmail_msg">resolution. Taking these functions apart neatly is going to be a tricky task.<br class="gmail_msg"><br class="gmail_msg">The following is a listing of the final modules that will be responsible for<br class="gmail_msg">the various tasks that are currently being performed by `RequirementSet`:<br class="gmail_msg"><br class="gmail_msg">- `pip.resolve` - Dependency Resolution<br class="gmail_msg">- `pip.download` - Downloading Files & Unpacking downloaded files<br class="gmail_msg">- `pip.req.req_set` - Holding a list of things to be installed / uninstalled<br class="gmail_msg">- `pip.operations.install` - Installing Packages (preparation for installation)<br class="gmail_msg">- `pip.operations.uninstall` - Uninstalling Packages<br class="gmail_msg"><br class="gmail_msg">To be able to proceed to the next step, only the dependency resolution related<br class="gmail_msg">code needs to be refactored into a separate module. Other portions of<br class="gmail_msg">`RequirementSet` are not required to be refactored but the same will be tackled<br class="gmail_msg">as optional deliverables. In other words, only `pip.resolve` needs to be<br class="gmail_msg">completed to be able to proceed to the next stage in this project. This is<br class="gmail_msg">needed since in Stage 3, the resolver would be written in `pip.resolve`,<br class="gmail_msg">independent of the rest of the codebase.<br class="gmail_msg"><br class="gmail_msg">##### Stage 2<br class="gmail_msg"><br class="gmail_msg">A new module `pip.cache` will be created. Within this module, all the caching<br class="gmail_msg">will be handled. Thus, the code for the current wheel cache would be moved.<br class="gmail_msg">The new code for a dependency cache for sdists would also be written here.<br class="gmail_msg"><br class="gmail_msg">The new cache would hold all of an sdist's egg-info. The information will be<br class="gmail_msg">stored on the file-system in a sub directory structure much like that of the<br class="gmail_msg">wheel cache, in a directory structure based on hash of the sdist file holding<br class="gmail_msg">the egg-info at the end. This will be done in a class named `EggInfoCache`.<br class="gmail_msg"><br class="gmail_msg">`EggInfoCache` cache will be used only if a corresponding wheel for an sdist is<br class="gmail_msg">not available. Installing an sdist results in the creation of a wheel which<br class="gmail_msg">contains the dependency information, which would be used over the information<br class="gmail_msg">available in the `EggInfoCache`.<br class="gmail_msg"><br class="gmail_msg">To be able to proceed to the next step, it is required that `EggInfoCache` is<br class="gmail_msg">implemented.<br class="gmail_msg"><br class="gmail_msg">##### Stage 3<br class="gmail_msg"><br class="gmail_msg">The module `pip.resolve` will be modified and a class named<br class="gmail_msg">`BacktrackingResolver` will be added to it. The class does what you expect it<br class="gmail_msg">to do - it would resolve dependencies with recursive backtracking. As described<br class="gmail_msg">above, there will be some global state stored about the packages that have been<br class="gmail_msg">explored. Other than the maintenance of global state, in the form of the cache,<br class="gmail_msg">the rest of the algorithm will essentially follow the same structure as any<br class="gmail_msg">backtracking algorithm.<br class="gmail_msg"><br class="gmail_msg">The project would be complete when the aforementioned resolver is implemented.<br class="gmail_msg"><br class="gmail_msg">#### Existing Work<br class="gmail_msg"><br class="gmail_msg">There is existing work directly related to dependency resolution in pip, done by<br class="gmail_msg">multiple individuals.<br class="gmail_msg"><br class="gmail_msg">- Robert Collins (un-merged closed pull request on pypa/pip)<br class="gmail_msg"><br class="gmail_msg">  This has an incomplete backtracking dependency resolver and dependency<br class="gmail_msg">  caching.<br class="gmail_msg"><br class="gmail_msg">- Sebastien Awwad (branch on a separate fork)<br class="gmail_msg"><br class="gmail_msg">  This was used for the depresolve project, to investigate the state of<br class="gmail_msg">  Dependency Resolution in PyPI/pip ecosystem.<br class="gmail_msg"><br class="gmail_msg">- `pip-compile` (separate project)<br class="gmail_msg"><br class="gmail_msg">  This has a backtracking dependency resolver implemented to overcome pip's<br class="gmail_msg">  inablity to resolve dependencies.<br class="gmail_msg"><br class="gmail_msg">Their work would be used for reference, where appropriate, during the course of<br class="gmail_msg">the project. Further, there are many package managers which implement dependency<br class="gmail_msg">resolution, which would also be looked into.<br class="gmail_msg"><br class="gmail_msg">### Tentative Timeline<br class="gmail_msg"><br class="gmail_msg">- Community Bonding Period: **5 May - 29 May**<br class="gmail_msg"><br class="gmail_msg">  - Clean up and finalize my existing pull requests.<br class="gmail_msg">  - Read existing literature regarding dependency resolution.<br class="gmail_msg">  - Inspect existing implementations of dependency resolvers.<br class="gmail_msg"><br class="gmail_msg">  GOAL: Be ready for the work coming up.<br class="gmail_msg"><br class="gmail_msg">- Week 1: **30 May - 5 June**<br class="gmail_msg"><br class="gmail_msg">  - Introduce abstractions across pip's codebase to make refactoring<br class="gmail_msg">    `RequirementSet` easier.<br class="gmail_msg">  - Begin breaking down `RequirementSet.prepare_file`.<br class="gmail_msg"><br class="gmail_msg">- Week 2: **6 June - 12 June**<br class="gmail_msg"><br class="gmail_msg">  - Continue working on the refactor of `RequirementSet`.<br class="gmail_msg"><br class="gmail_msg">- Week 3: **13 June - 19 June**<br class="gmail_msg"><br class="gmail_msg">  - Continue working on the refactor of `RequirementSet`.<br class="gmail_msg">  - Finish and polish `pip.resolve`.<br class="gmail_msg"><br class="gmail_msg">  GOAL: `pip.resolve` module will be ready, using the current resolution<br class="gmail_msg">        strategy.<br class="gmail_msg"><br class="gmail_msg">- Week 4: **20 June - 26 June**<br class="gmail_msg"><br class="gmail_msg">  - Finish and polish all work on the refactor of `RequirementSet`.<br class="gmail_msg"><br class="gmail_msg">- Week 5: **27 June - 3 July**<br class="gmail_msg"><br class="gmail_msg">  - Move code for `WheelCache` into a new `pip.cache` module.<br class="gmail_msg">  - Write tests for `pip.cache.EggInfoCache`, based on `WheelCache`.<br class="gmail_msg">  - Begin implementation of `pip.cache.EggInfoCache`.<br class="gmail_msg"><br class="gmail_msg">- Week 6: **4 July - 10 July**<br class="gmail_msg"><br class="gmail_msg">  - Finish and polish `pip.cache.EggInfoCache`.<br class="gmail_msg"><br class="gmail_msg">  GOAL: A cache for storing dependency information of sdists would be ready to<br class="gmail_msg">        add to pip.<br class="gmail_msg"><br class="gmail_msg">- Week 7: **10 July - 16 July**<br class="gmail_msg"><br class="gmail_msg">  - Create a comprehensive set of tests for the dependency resolver.<br class="gmail_msg">    (in `tests/unit/test_resolve.py`)<br class="gmail_msg">  - Begin implementation on the backtracking algorithm.<br class="gmail_msg"><br class="gmail_msg">  GOAL: A comprehensive test bed is ready for testing the dependency resolver.<br class="gmail_msg"><br class="gmail_msg">- Week 8: **17 July - 24 July**<br class="gmail_msg"><br class="gmail_msg">  - Complete a rough implementation of the backtracking algorithm<br class="gmail_msg"><br class="gmail_msg">  GOAL: An implementation of a dependency resolver to begin running tests on<br class="gmail_msg">  and work on improving.<br class="gmail_msg"><br class="gmail_msg">- Week 9: **25 July - 31 July**<br class="gmail_msg"><br class="gmail_msg">  - Fixing bugs in dependency resolver<br class="gmail_msg"><br class="gmail_msg">- Week 10: **1 August - 6 August**<br class="gmail_msg"><br class="gmail_msg">  - Finish and polish work on dependency resolver<br class="gmail_msg"><br class="gmail_msg">  GOAL: A ready-to-merge PR adding a backtracking dependency resolver for pip.<br class="gmail_msg"><br class="gmail_msg">- Week 11: **6 August - 13 August**<br class="gmail_msg"><br class="gmail_msg">  Buffer Week.<br class="gmail_msg"><br class="gmail_msg">- Week 12: **13 August - 21 August**<br class="gmail_msg"><br class="gmail_msg">  Buffer Week. Finalization of project for evaluation.<br class="gmail_msg"><br class="gmail_msg">If the deliverable is achieved ahead of schedule, the remaining time will be<br class="gmail_msg">utilized to resolve open issues on pip's repository in the order of priority as<br class="gmail_msg">determined under the guidance of the mentors.<br class="gmail_msg"><br class="gmail_msg">#### Other Commitments<br class="gmail_msg"><br class="gmail_msg">I expect to not be able to put in 40 hour/week for at most 3 weeks throughout<br class="gmail_msg">the working period, due to the schedule of my university.<br class="gmail_msg"><br class="gmail_msg">I will have semester-end examinations - from 10th May 2017 to 24th May 2017 -<br class="gmail_msg">during the Community Bonding Period. My university will re-open for my third<br class="gmail_msg">semester on 12 July 2017. I expect mid-semester examinations to be held in my<br class="gmail_msg">University around 20th August 2017. During these times, I would not be able to<br class="gmail_msg">put in full 40 hour weeks due to the academic workload.<br class="gmail_msg"><br class="gmail_msg">I might take a 3-4 day break during this period, regarding which I would be<br class="gmail_msg">informing my mentor around a week in advance.<br class="gmail_msg"><br class="gmail_msg">I will be completely free from 30th May 2017 to 11 July 2017.<br class="gmail_msg"><br class="gmail_msg">### Future Work<br class="gmail_msg"><br class="gmail_msg">There seems to be some interest in being able to reuse the above dependency<br class="gmail_msg">resolution algorithm in other packaging related tools, specifically from the<br class="gmail_msg">buildout project. I intend to eventually move the dependency resolution code<br class="gmail_msg">that would come out of this project into a separate library to allow for reuse<br class="gmail_msg">by installer projects - pip, buildout and other tools.<br class="gmail_msg"><br class="gmail_msg">## Previous Contributions to pip<br class="gmail_msg"><br class="gmail_msg">(As on 12th March 2017)<br class="gmail_msg"><br class="gmail_msg">### Issues<br class="gmail_msg"><br class="gmail_msg">Authored:<br class="gmail_msg"><br class="gmail_msg">- #3785 - Prefering wheel-based installation over source-based installation (Open)<br class="gmail_msg">- #3786 - Make install command upgrade packages by default (Closed)<br class="gmail_msg">- #3787 - Check if pip broke the dependency graph and warn the user (Open)<br class="gmail_msg">- #3807 - Tests fail since change on PyPI (Closed)<br class="gmail_msg">- #3809 - Switch to TOML for configuration files (Open)<br class="gmail_msg">- #3871 - Provide a way to perform non-eager upgrades (Closed)<br class="gmail_msg">- #4198 - Travis CI - pypy broken dues to dependency change in pycrypto (Closed)<br class="gmail_msg">- #4282 - What's the release schedule? (Closed)<br class="gmail_msg"><br class="gmail_msg">Participated:<br class="gmail_msg"><br class="gmail_msg">- #59 - Add "upgrade" and "upgrade-all" commands (Open)<br class="gmail_msg">- #988 - Pip needs a dependency resolver (Open)<br class="gmail_msg">- #1056 - pip install -U does not remember whether a package was installed with --user (Open)<br class="gmail_msg">- #1511 - ssl certificate hostname mismatch errors presented badly (Open)<br class="gmail_msg">- #1668 - Default to --user  (Open)<br class="gmail_msg">- #1736 - Create a command to make it easy to access the configuration file (Open)<br class="gmail_msg">- #1737 - Don't tell the user what they meant, just do what they meant (Open)<br class="gmail_msg">- #2313 - Automated the Creation and Upload of Release Artifacts (Open)<br class="gmail_msg">- #2732 - pip install hangs with interactive setup.py setups (Open)<br class="gmail_msg">- #3549 - pip -U pip fails (Open)<br class="gmail_msg">- #3580 - Update requests/urllib3 (Closed)<br class="gmail_msg">- #3610 - pip install from package from github, with github dependencies  (Open)<br class="gmail_msg">- #3788 - `pip` version suggested is older than the version which is installed (Closed)<br class="gmail_msg">- #3789 - Error installing Mayavi in Mac OS X  (Closed)<br class="gmail_msg">- #3798 - On using python -m pip install -upgrade pip.. its throwing an error like the one below (Closed)<br class="gmail_msg">- #3811 - no matching distribution found for install (Closed)<br class="gmail_msg">- #3814 - pip could not find a version that satisfies the requirement oslo.context (Closed)<br class="gmail_msg">- #3876 - support git refs in @ syntax (Open)<br class="gmail_msg">- #4021 - Will you accept PRs with pep484 type hints?  (Open)<br class="gmail_msg">- #4087 - pip list produces error (Closed)<br class="gmail_msg">- #4149 - Exception thrown when binary is already linked to /usr/local/bin (Open)<br class="gmail_msg">- #4160 - Pip does not seem to be handling deep requirements correctly (Open)<br class="gmail_msg">- #4162 - Let --find-links be context aware to support github, gitlab, etc. links (Open)<br class="gmail_msg">- #4170 - pip list |head raises BrokenPipeError (Open)<br class="gmail_msg">- #4182 - pip install should install packages in order to avoid ABI incompatibilities in compiled  (Open)<br class="gmail_msg">- #4186 - IOError: [Errno 13] Permission denied: '/usr/local/bin/pip' (Open)<br class="gmail_msg">- #4206 - Where on Windows 10 is pip.conf or pip.ini located? (Closed)<br class="gmail_msg">- #4221 - Feature request: Check if user has permissions before downloading files (Closed)<br class="gmail_msg">- #4229 - "pip uninstall" is too noisy (Open)<br class="gmail_msg"><br class="gmail_msg">#### Pull Requests<br class="gmail_msg"><br class="gmail_msg">Authored:<br class="gmail_msg"><br class="gmail_msg">- #3806 - Change install command's default behaviour to upgrade packages by default (Closed, superseded by #3972)<br class="gmail_msg">- #3808 - Fix Tests (Merged)<br class="gmail_msg">- #3818 - Improve UX and tests of check command (Merged)<br class="gmail_msg">- #3972 - Add an upgrade-strategy option (Merged)<br class="gmail_msg">- #3974 - [minor] An aesthetic change to wheel command source (Merged)<br class="gmail_msg">- #4192 - Move out all the config code to a separate module (Merged)<br class="gmail_msg">- #4193 - Add the ability to autocorrect a user's command (Open)<br class="gmail_msg">- #4199 - Fix Tests for Travis CI (Merged)<br class="gmail_msg">- #4200 - Reduce the API exposed by the configuration class (Merged)<br class="gmail_msg">- #4232 - Update documentation to mention upgrade-strategy (Merged)<br class="gmail_msg">- #4233 - Nicer permissions error message (Open)<br class="gmail_msg">- #4240 - [WIP] Add a configuration command (Open)<br class="gmail_msg"><br class="gmail_msg">Participated:<br class="gmail_msg"><br class="gmail_msg">- #2716 - Issue #988: new resolver for pip (Closed)<br class="gmail_msg">- #2975 - Different mock dependencies based on Python version (Merged)<br class="gmail_msg">- #3744 - Add a "Upgrade all local installed packages" (Open)<br class="gmail_msg">- #3750 - Add a `pip check` command. (Merged)<br class="gmail_msg">- #3751 - tox.ini: Add "cover" target (Open)<br class="gmail_msg">- #3794 - Use the canonicalize_name function for finding .dist-info (Merged)<br class="gmail_msg">- #4142 - Optionally load C dependencies based on platform (Open)<br class="gmail_msg">- #4144 - Install build dependencies as specified in PEP 518 (Open)<br class="gmail_msg">- #4150 - Clarify default for --upgrade-strategy is eager (Merged)<br class="gmail_msg">- #4194 - Allow passing a --no-progress-bar to the install script to surpress progress bar (Merged)<br class="gmail_msg">- #4201 - Register req_to_install for cleanup sooner (Merged)<br class="gmail_msg">- #4202 - Switch to 3.6.0 final as our latest 3.x release (Merged)<br class="gmail_msg">- #4211 - improve message when installing requirements file (#4127) (Merged)<br class="gmail_msg">- #4241 - Python 3.6 is supported (Merged)<br class="gmail_msg"><br class="gmail_msg">## References<br class="gmail_msg"><br class="gmail_msg">1. [pypa/pip#988](<a href="https://github.com/pypa/pip/issues/988" class="gmail_msg" target="_blank">https://github.com/pypa/pip/issues/988</a>)<br class="gmail_msg"><br class="gmail_msg">   Tracking issue for adding a proper dependency resolver in pip. Contains<br class="gmail_msg">   links to various useful resources.<br class="gmail_msg"><br class="gmail_msg">1. [pypa/pip#2716](<a href="https://github.com/pypa/pip/issues/2716" class="gmail_msg" target="_blank">https://github.com/pypa/pip/issues/2716</a>)<br class="gmail_msg"><br class="gmail_msg">   Prior work by Robert Collins for adding a proper dependency resolver in pip.<br class="gmail_msg"><br class="gmail_msg">1. [Python Dependency Resolution](<a href="https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit?usp=sharing" class="gmail_msg" target="_blank">https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit?usp=sharing</a>)<br class="gmail_msg"><br class="gmail_msg">   A writeup by Sebastian Awwad on the current state of dependency resolution<br class="gmail_msg">   in pip and PyPI in general.<br class="gmail_msg"><br class="gmail_msg">1. [PSF Application Template](<a href="https://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2017" class="gmail_msg" target="_blank">https://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2017</a>)<br class="gmail_msg"><br class="gmail_msg">   For guidance on how to write the application and what information is needed.<br class="gmail_msg"><br class="gmail_msg">1. [Stork: Secure Package Management for VM Environments](<a href="http://isis.poly.edu/~jcappos/papers/cappos_stork_dissertation_08.pdf" class="gmail_msg" target="_blank">http://isis.poly.edu/~jcappos/papers/cappos_stork_dissertation_08.pdf</a>)<br class="gmail_msg"><br class="gmail_msg">   A Paper by Justin Cappos about Stork, used for reference regarding<br class="gmail_msg">   Backtracking Resolution<br class="gmail_msg"><br class="gmail_msg"></div></blockquote></div>