Changes between Version 1 and Version 2 of Commentary/GSoC_Cabal_nix


Ignore:
Timestamp:
Jun 17, 2015 6:46:51 AM (4 years ago)
Author:
fugyk
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoC_Cabal_nix

    v1 v2  
    44[[Image(http://www.well-typed.com/blog/aux/images/cabal-hell/install-example1.png)]]
    55
    6 There are situations where Cabal’s chosen solution would involve reinstalling an existing version of a package but built with different dependencies.
    7 In this example, after installing app-1.1, app-1.0 and other-0.1 will be broken. The root of the problem is having to delete – or if you like, mutate – package instances when installing new packages. This is due to the limitation of only being able to have one instance of a package version installed at once.
     6There are situations where Cabal's chosen solution would involve reinstalling an existing version of a package but built with different dependencies.
     7In this example, after installing app-1.1, app-1.0 and other-0.1 will be broken. The root of the problem is having to delete or mutate package instances when installing new packages. This is due to the limitation of only being able to have one instance of a package version installed at once.
    88== Type errors when using packages together ==
    99[[Image(http://www.well-typed.com/blog/aux/images/cabal-hell/install-example2.png)]]
    1010
    1111The second, orthogonal, problem is that it is possible to install two packages and then load them both in GHCi and find that you get type errors when composing things defined in the two different packages. Effectively you cannot use these two particular installed packages together.
    12 The fundamental problem is that developers expect to be able to use combinations of their installed packages together, but the package tools do not enforce consistency of the developer’s environment.
     12The fundamental problem is that developers expect to be able to use combinations of their installed packages together, but the package tools do not enforce consistency of the developer's environment.
    1313= Goals =
    1414* Fix breaking re-installs (Persistent package store)
     
    2424It will have additional benefit that package will not be built again if same source has already been built earlier, thus saving time.
    2525== Views ==
    26 Views will the subset of packages of package store whose modules can be imported. Views will be present as various *.view file in <Package DB location>/views like default.view. The view file contains list of installed package IDs. There will exist a default view which contains packages installed by cabal install outside sandbox. If a package name is installed two times, default view will contain the instance of package which is installed at last. Views’ packages will also act like GC roots.
     26Views will the subset of packages of package store whose modules can be imported. Views will be present as various *.view file in <Package DB location>/views like default.view. The view file contains list of installed package IDs. There will exist a default view which contains packages installed by cabal install outside sandbox. If a package name is installed two times, default view will contain the instance of package which is installed at last. Views' packages will also act like GC roots.
    2727
    2828To facilitate views, ghc-pkg will need some new commands:
     
    5252It will require additional constraint to check that there is no other instance of the same package or its dependencies is in the environment(packages from which we have imported the modules with their dependency closure) when we are importing the module from a package. It also needs to be checked when cabal is configuring the package, that a package do not directly or indirectly depends on two version of same package. If it is violated it needs to give out an error.
    5353== Garbage collection ==
    54 This will firstly involve determining the root packages and package list. Root packages are the packages which are in some view. Then we find list of all packages in the database. As there will be single database after implementing views, we don&rsquo;t need to call it for every sandbox database. Then we need to do mark-sweep and find which package are not in the reachable package list and select it for garbage collection. Then the selected packages will be deleted from the package store and also unregistered from database with ghc-pkg.
     54This will firstly involve determining the root packages and package list. Root packages are the packages which are in some view. Then we find list of all packages in the database. As there will be single database after implementing views, we don't need to call it for every sandbox database. Then we need to do mark-sweep and find which package are not in the reachable package list and select it for garbage collection. Then the selected packages will be deleted from the package store and also unregistered from database with ghc-pkg.
    5555== cabal remove ==
    5656With everything implemented above, it is just removing a package from default view. If package is unreachable it can be freed from disk by GC. It is guaranteed to not break any package except the package that is removed.