Code Monkey home page Code Monkey logo

Comments (2)

pradyunsg avatar pradyunsg commented on September 4, 2024

This was actually one of the first things I thought of when I was starting and it actually falls under the umbrella of "the resolver would always make the user end up with a consistent dependency graph".

If the current installed state is broken, it would be possible to have the resolver explore versions other than the ones currently installed for trying to unbreak the environment. From a resolution point of view, it's just a matter of providing the resolver with all the possible versions of a package, with a preference for the currently installed one. The resolver would then choose a consistent set of packages, if it can, like it's supposed to.

This does mean that if you want to just install a package in a broken environment, without fixing that environment, you would no longer be able to do so -- unless we have some way to ignore everything else in the environment. Staying functional in that environment is definitely possible and maybe I'll look into enabling that if it makes sense for us -- I don't think it does.

The more interesting/difficult part of the puzzle might be the actual UX here -- something I think we should get into when we have a PR to discuss it on. :)

from zazo.

pfmoore avatar pfmoore commented on September 4, 2024

I don't personally have a use case for it, but I imagine some people will need to be able to "just install X" without being blocked by problems with packages not in the dependency graph of X.

A more complex case. X depends on Y and Z, and Y 1.0 depends on Z>1.0. Y 1.0 and Z 1.0 are already installed. The installation is broken, but it nevertheless does satisfy the declared requirements of X (that Y and Z are present). Should installing X trigger reinstalls of either Y or Z? If so, why? I suspect that the "intuitive" answer is that by default, pip shouldn't try to "fix" existing installs unless asked to, or it's not possible to satisfy the top-level dependencies of the specified requirements. In that case, it would make sense to have a --fix-installed flag to do a full pass.

Agreed that a lot of this is UX discussion, which can be deferred, but I think that it's quite possible that the resolver having an "assume that installed packages are valid" mode will be important to at least some people.

from zazo.

Related Issues (19)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.