Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. Let’s see if I understand this correctly. I believe that Duncan/you envisage the following scenario: · Package database: you can install any package, compiled against any dependencies, without breaking anything. So the package database can contain multiple instances of P-2.3, compiled against different dependencies. · Environment. The “environment” maps a package name, such as “P-2.3” to a particular package instance in the database. When you say “ghc –c Foo.hs –package P”, the “-package 2.3” consults the environment to determine which of the many P-2.3 instances you might mean. Mind you, GHC’s new –package flag takes a package key (which identifies a unique package instance in the database). So I’m hazy about exactly when the environment is used. · You can in principle have many environments (akin to sandboxes) but only one database. There is a UI issue about how you define and maintain environments. · Duncan argues that, for predictability, every environment should be consistent. o I’m not sure exactly what “consistent” means. Can I have P-2.3 and P-2.4 in the same environment, or only one P (for a given package name P)? o Intuitively, though, “consistent” means that all packages in the environment are compatible; they won’t give rise to the confusing “P-2.3:M.T does not match P-2.4:M.T” errors. · The environment is irrelevant when cabal is installing a package,. Cabal just computes a set of consistent dependencies, installs any missing dependencies, and installs the package. So the environment only matters for explicit user –package flags. I think it would be incredibly helpful to have a wiki page in which the proposed design is fleshed out in detail. The above is a start, but clearly I’m confused about many things. Lacking a concrete, well-specified design we risk repeating the same conversations. (I’m sure I have repeated above stuff that is well worn territory.) Thanks! Simon From: Vishal Agrawal [mailto:vishal4556@gmail.com] Sent: 11 May 2015 23:02 To: Simon Peyton Jones Cc: Boespflug, Mathieu; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan@well-typed.com); Ryan Trinkle; haskell-infrastructure@community.galois.com; cabal-devel@haskell.org; ghc-devs@haskell.org; Haskell Libraries Subject: Re: QRE: Cabal and simultaneous installations of the same package Thanks. I will start working on it soon. Currently I am having a great mentorship by Ryan Trinkle. We have talked a few times, mostly about the plan of the project. The main problem that can arise by the project is by enforcing consistency. It is already well documented by Duncan Coutts in a blog post from which I took most of the ideas from. http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-...
Enforcing consistency does have implications for the user interface. There will be situations where one wants to install a new package, but it is impossible to add it to the current environment while keeping all of the existing packages. For example, suppose we have two different web stacks that have many packages in common but that require different versions of some common package. In that case we could not have a consistent environment that contains both. Thus the user interface will have to do something when the user asks to add the second web stack to an environment that already contains the first. The user interface could minimise the problem by encouraging a style of use where most environments are quite small, but it cannot be avoided in general. While what I am suggesting for consistency is relatively strong, we cannot get away without enforcing some restrictions on the environment. For example if our environment did contain two instances of the same version of a package then which one would we get when we launch GHCi? So my view is that given that we cannot avoid the user interface issues with environment consistency, it is better to go for the stronger and more useful form. I am little unsure about what other community members think about it, but there is an acceptance from Duncan Coutts. If consistency is not enforced, errors like ‘bytestring is not bytestring’ can increase many times after implementing persistent package store as there will be a larger pool of packages. If enforced, there might be situation where developer will not be able load two package at the same time which can earlier work at the same time. My personal preference is to enforce consistency.
On 11-May-2015, at 9:47 pm, Simon Peyton Jones
Well, no one is actually suggesting that!
But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs