Changes between Version 29 and Version 30 of Commentary/GSoCMultipleInstances


Ignore:
Timestamp:
Jun 19, 2012 2:10:19 PM (3 years ago)
Author:
kosmikus
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoCMultipleInstances

    v29 v30  
    123123Options are to either offer an interactive process where packages that look unused are suggested for removal, or to integrate with a sandbox mechanism. If, for example, dirty builds are usually installed into a separate package DB, that package DB could just be removed completely by a user from time to time. 
    124124 
    125 == Related topics == 
    126  
    127 In the following, we discuss some other issues which are related to the multi-instance problem, but not necessarily directly relevant in order to produce an implementation. 
    128  
    129 === Separating storage and selection of packages === 
    130  
    131 Currently the two concepts of storing package instances (cabal store) and selecting package instances for building (environment) are conflated into a `PackageDB`. Sandboxes are used as a workaround to create multiple different environments. But they also create multiple places to store installed packages. The disadvantages of this are disk usage, compilation time and one might lose the overview. Also if the multi-instance restriction is not lifted sandboxes will eventually suffer from the same unintended breakage of packages as non-sandboxed `PackageDB`s. 
    132 There should be a separation between the set of all installed packages called the cabal store and a subset of these called an environment. While the cabal store can contain multiple instances of the same package version an environment needs to be consistent. An environment is consistent if for every package version it contains only one instance of that package version. 
    133  
    134 === First class environments === 
    135  
    136 It would be nice if we had some explicit notion of an environment. 
    137  
    138 == Questions to remember == 
    139  
    140 What about builtin packages like ghc-prim, base, rts and so on? 
    141  
    142 Inplace Registration? 
    143  
    144 Who has assumptions about the directory layout of installed packages? 
    145  
    146 Executables? 
    147  
    148 Haddock? 
    149  
    150 Installation Planner? 
    151  
    152 Custom Builds and BuildHooks? 
    153  
    154 Other Compilers, backwards compatibility? 
    155  
    156 What is ComponentLocalBuildInfo for? 
    157  
    158125== Currently open design decisions == 
    159126 
     
    172139 
    173140ABI hash cannot be in install path because it's only available after build. 
     141 
     142=== Handling of dirty builds === 
     143 
     144How should hash computation work for dirty builds? 
     145 
     146   * Use a random number even if we otherwise use hashes 
     147   * Hash the complete build directory 
     148   * Attempt to make a clean (sdist-like) copy or linked copy of the sources and hash and build from that. 
     149   * Use the Cabal file to determine the files that would end up in an sdist and hash those directly without copying. 
     150 
     151The third option has the advantage(?) that the build is more guaranteed to use only  files actually mentioned in the Cabal file. 
    174152 
    175153=== Build flavours === 
     
    197175 
    198176   * Agnostic (except for builtin packages): could be done with only the Cabal hash in `InstalledPackageInfo`. 
     177 
     178=== Simplistic dependency resolution === 
     179 
     180Options (in order of preference): 
     181 
     182 * use the time of installation 
     183 * user-specified priorities 
     184 * pick a random / unspecified instances 
     185 * (build a complex solver into GHC) 
     186 
     187A combination of the first two seems possible and useful. 
     188 
     189== Related topics == 
     190 
     191In the following, we discuss some other issues which are related to the multi-instance problem, but not necessarily directly relevant in order to produce an implementation. 
     192 
     193=== Separating storage and selection of packages === 
     194 
     195Currently the two concepts of storing package instances (cabal store) and selecting package instances for building (environment) are conflated into a `PackageDB`. Sandboxes are used as a workaround to create multiple different environments. But they also create multiple places to store installed packages. The disadvantages of this are disk usage, compilation time and one might lose the overview. Also if the multi-instance restriction is not lifted sandboxes will eventually suffer from the same unintended breakage of packages as non-sandboxed `PackageDB`s. 
     196There should be a separation between the set of all installed packages called the cabal store and a subset of these called an environment. While the cabal store can contain multiple instances of the same package version an environment needs to be consistent. An environment is consistent if for every package version it contains only one instance of that package version. 
     197 
     198=== First class environments === 
     199 
     200It would be nice if we had some explicit notion of an environment. 
     201 
     202== Questions to remember == 
     203 
     204What about builtin packages like ghc-prim, base, rts and so on? 
     205 
     206Inplace Registration? 
     207 
     208Who has assumptions about the directory layout of installed packages? 
     209 
     210Executables? 
     211 
     212Haddock? 
     213 
     214Installation Planner? 
     215 
     216Custom Builds and BuildHooks? 
     217 
     218Other Compilers, backwards compatibility? 
     219 
     220What is ComponentLocalBuildInfo for?