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?