On 1 October 2012 16:26, Duncan Coutts <duncan.cou...@googlemail.com> wrote: > On 1 October 2012 04:21, Johan Tibell <johan.tib...@gmail.com> wrote: >> Hi, >> >> I don't want to hold up the release on this issue if it needs more >> discussion. I'd like to make another Cabal/cabal-install release >> before end of the year (probably around GHC's release timeline), to >> include the sandbox stuff once done. Would it be OK to wait until then >> with these two patches? > > I think these specific patches do not need discussion now, here's why: > the feature comes in two parts, server and client, the bulk of the > feature is the server side part which is not implemented yet. There's > plenty of time for more discussion of the feature in general before we > start actually using it. But if we decide it's ok, then we have to > wait even longer to start using it. We can deploy new server side code > quickly, but not client side code. If we decide it's not ok, then we > don't make use of the feature server-side and then we rip out the > client code. So that's why I want to get the client code in now, in > advance of the server side implementation. > > Also note, I have discussed this before with several people (and I > think on this list too, a couple years back). So Bryan didn't see it, > but it's not like I'm inventing this crazy idea from nowhere and > forcing it on people. I'm very happy to discuss the details again, but > that's independent of these two patches.
Please do; I think a 2 week discussion period would be appropriate given that this is a surprise to most people here. My understanding of this idea is: * some unspecified group of people with global authority on Hackage can insert a new "x-hackage-version" line into existing .cabal files, and modify dependency bounds * anyone parsing a .cabal file must now interpret x-hackage-version as somehow appended to or overriding version (?) * using the "cabal unpack" tool will retrieve this modified .cabal file * using "wget" will retrieve a tarball containing the original .cabal file I think this idea is the wrong way to go, as it mixes up author-specified versioning info and distro-specified overrides in the same mechanism. This will likely make it difficult for others to package Haskell packages as the file contents retrieved no longer just depend on the version requested. The retrieved file contents now depend on the tool used for retrieval, and on the version of cabal used for cabal unpack: distro developers who do not bootstrap with a latest-version cabal will get the wget behaviour. Conrad. _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
