Changes between Version 13 and Version 14 of Commentary/GSoCMultipleInstances


Ignore:
Timestamp:
May 23, 2012 1:58:51 PM (3 years ago)
Author:
kosmikus
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoCMultipleInstances

    v13 v14  
    22== Overview ==
    33
    4 It is a problem that cabal does not support multiple instances of the same package version installed at the same time. Instead of installing them next to each other it overwrites the previous instance. This causes packages that depended upon the overwritten instance to break. The solution is to never overwrite an installed package. In the case of inplace registrations the overwriting has already taken place which is a problem.
     4It is a problem that cabal does not support multiple instances of the same package version installed at the same time. [Mainly ghc, not cabal. Cabal's non-support is a consequence.] Instead of installing them next to each other it overwrites the previous instance. This causes packages that depended upon the overwritten instance to break. The solution is to never overwrite an installed package. In the case of inplace registrations the overwriting has already taken place which is a problem. [?]
    55
    6 Relating this to how Nix works. Cabal stores potentially every instance of every package possible. Lets call this the cabal store. There might at least be a global and a local one. Shadowing doesn't matter because if two packages have the same hash they should be interchangeble.
     6Relating this to how Nix works. Cabal stores potentially every instance of every package possible. Lets call this the cabal store. [Are you talking about Nix or about Cabal? Does the store really contain all packages, even packages not ever built?] There might at least be a global and a local one. [Might be?] Shadowing doesn't matter because if two packages have the same hash they should be interchangeable. [Define shadowing.]
    77
    8 The dependency resolver comes up with an install plan. In this install plan all packages have completely fixed dependencies based on the dependencies specified in the cabal file. Same of them are already present in the cabal store and some aren't. They are a subset of all possible package instances. This corresponds to a profile in Nix as well as a sandbox. We call this an environment.
     8The dependency resolver comes up with an install plan. [Is this part of the current situation or part of the solution?] In this install plan all packages have completely fixed dependencies based on the dependencies specified in the cabal file. Same of them are already present in the cabal store and some aren't. They are a subset of all possible package instances. This corresponds to a profile in Nix as well as a sandbox. We call this an environment. [I still don't get this definition of environment. In particular, I fail to see how an environment is related to the solver.]
    99
    1010== Dependency resolution ==
    1111
    12 The dependency resolver takes into account which packages are already installed and tries to reuse them. Another option would be for the resolver to ignore which packages are already installed. It then computes the hashes for the packages it needs for compilation. Then those that aren't already present in the cabal store are built.
     12The dependency resolver takes into account which packages are already installed and tries to reuse them. [Is this part of the current situation or part of the solution?] Another option would be for the resolver to ignore which packages are already installed. It then computes the hashes for the packages it needs for compilation. Then those that aren't already present in the cabal store are built. [Tradeoffs?]
    1313
    1414== Released and Unreleased packages ==
    1515
    16 If we cabal install a package that is released on hackage we call this a clean install. Those should not be used to satisfy dependencies but rather to bring a package into scope in ghci to play with it. If we cabal install an unreleased package we call this a dirty install. I assume that the source code for a released package is uniquely identified by its version number. For unreleased packages this is not the case.
     16If we cabal install a package that is released on hackage we call this a clean install. Those should not be used to satisfy dependencies but rather to bring a package into scope in ghci to play with it. [Or to install an application? Why not phrase this positively? Also, why not first give the definitions completely, then discuss the differences.] If we cabal install an unreleased package we call this a dirty install. I assume that the source code for a released package is uniquely identified by its version number. [Why is this important?] For unreleased packages this is not the case.
    1717
    1818== The cabal hash ==