The magic of dependency resolution
Oh, this is about Conda?..<p>I think, this is going to be the third go at the problem?  The first two were hands-down awful leading to creation of Mamba.  But speeding things up is only part of the solution here.<p>Conda package ecosystem has a bunch of issues that are related to the format and the repositories providing packages as well as on the policy for accepting packages into those repositories.  They tried to solve too many problems at once, probably, w&#x2F;o even realizing what kind of problem they are attacking.<p>Here&#x27;s a major problem with Conda ecosystem, the way I see it: package developers are encouraged to produce very &quot;precise&quot; dependency requirements because this makes installation process go faster and ensures less wiggle room for untested dependency combination.  This, in turn, results in proliferation of package versions, all of which declare themselves as incompatible and non-interchangeable with many others.<p>On top of this, beside providing just the Python packages, Conda, ambitiously, wants to also provide shared libraries, which blows up the minimum installation to an enormous size, including the number of packages that need installing.<p>So, being a Conda package maintainer, you will face a dilemma: do you want your users to be able to install the package in acceptable time (at least under 10 minutes...) or work towards compatibility with multiple different versions of other packages the users might need for other reasons in the same environment (and your installation times start shooting through the roof).  In my experience, the longest <i>successful</i> Conda install took about a day (i.e. close to 24 hours).  It may take few days for Conda to fail to install (due to imaginary or real conflict).<p>Now, add to this the existence of multiple sources for different packages (i.e. &quot;channels&quot;). Different channels may, and actually quite often do provide different unrelated other packages in their channel, but the users cannot specify the channel when requesting to install a package <i>on per-package basis</i>.  So, the solver needs to guess somehow which channel to prefer as a source of any given package.  The problem is that while the package version found in that channel might be the same, the requirements for that package might differ between channels.<p>So, while aiming at providing a lot of possibly useful features, Conda programmers programmed themselves into a corner with no good way out.<p>Several things might help, but none will ultimately solve the situation.<p>* Package bundles (or meta-packages, like they are called in some Linux distributions) will cut significantly on the work a solver needs to do.  A lot of the basic (shared libraries) packages are, essentially, always the same in each install.<p>* LTS curated channel snapshots.  I.e. provide a very large collection of packages that are verified to all work together, but unlike the meta-packages need not be installed together.<p>* Incorporate channel into version specification, especially when specifying package dependencies so that maintainers were required to specify the source of their dependencies when submitting their package.<p>* There are a bunch of (very) infrequently used options in the current solver that can be safely removed, but they add to the complexity and the time the solver spends in various &quot;impossible&quot; scenarios.