[Haskell-cafe] Re: Cabal dependency hell
Edward Z. Yang wrote: Ivan Lazar Miljenovic's wrote: Edward Z. Yang writes: I doubt you'd get very much runtime with that. I'd suggest prompting the user to submit a failed build report if the build fails. Exactly like how Windows keeps prompting you to allow it to send an error report to Microsoft? I don't know about you, but I always found it irritating... I think the primary irritation is that Microsoft gets all of these error reports and they disappear into the great black VOID. Some public statistics might help alleviate the irritation. Perhaps exactly when the user is prompted? Would you like to send an anonymous report of this build failure to hackage.org? Users have been uploading 189 reports so far; yours would be the 190th report that ensures high quality Haskell packages! [y/n] Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Cabal dependency hell
Heinrich Apfelmus apfel...@quantentunnel.de writes: Perhaps exactly when the user is prompted? Would you like to send an anonymous report of this build failure to hackage.org? Users have been uploading 189 reports so far; yours would be the 190th report that ensures high quality Haskell packages! [y/n] Which, in its own way, means that cabal-install is still phoning home; you then even need network access if you're building packages that you've already downloaded the sources for. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cabal dependency hell
Ivan Lazar Miljenovic wrote: Heinrich Apfelmus writes: Perhaps exactly when the user is prompted? Would you like to send an anonymous report of this build failure to hackage.org? Users have been uploading 189 reports so far; yours would be the 190th report that ensures high quality Haskell packages! [y/n] Which, in its own way, means that cabal-install is still phoning home; you then even need network access if you're building packages that you've already downloaded the sources for. Good point. How about using a cached number from the last cabal install , then: Would you like to send an anonymous report of this build failure to hackage.org? Users have been uploading more than 188 reports so far to help ensure high quality Haskell packages! [y/n] It's just to instill a sense of activity and purpose. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Cabal dependency hell
On Thu, Mar 11, 2010 at 08:54:15AM -0800, Rogan Creswick wrote: (c) fix the unpacked version, and increment the version number by adding a new level of detail (so, 3.1.0 becomes 3.1.0.1). This version number never leaves my system -- it only exists to keep my cabal/ghc-pkg consistent! A decent approach, except if the library in question is a core package to the compiler or a library that those packages depend on. I suffered some vast destruction doing the above to the Win32 package. Apparently packages like directory depends on this, breaking GHC irrecoverably if you try to propagate fixes. I managed to limp along for a bit with constraints, but ended up wiping the whole install and installing a clean one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Cabal dependency hell
On Mon, Mar 8, 2010 at 2:31 PM, Maciej Piechotka uzytkown...@gmail.com wrote: On Mon, 2010-03-08 at 15:37 +0100, Marc Weber wrote: We can't expect package maintainers to test everything. So it must be people like you and me who fixes those changes. Well. Except that it require bumping versions. Which according to hackage policy requires to fork a project (which makes it pointless in the first place) This isn't quite that dire -- I've adopted the following practice when I encounter a cabal dependency issue: (a) identify the problem (eg: observing `cabal install foo` fails) (b) get the source via hackage: `cabal unpack foo` (c) fix the unpacked version, and increment the version number by adding a new level of detail (so, 3.1.0 becomes 3.1.0.1). This version number never leaves my system -- it only exists to keep my cabal/ghc-pkg consistent! (d) if possible, verify that the problem still exists in the project's actual source control (e) email the maintainer, and if possible, including a patch to the current head of the revision control system for the project. So far, it's worked pretty well :) Everyone I've sent patches to has been very responsive and helpful, often pushing updated versions to hackage by the end of the day. The way to go is make hackage allow changing constraints on the fly notifying the author that he can update his repository. You can, at times, do this by forcing constraints via cabal command line flags, or by installing packages with a version specification. $ cabal install foo-1.2.3 will install that specific version of foo. --Rogan This will work in most cases. Bumping versions because a dependency has changed is bad as well. This will cause to much overhead (and it dosen't solve the problem because the old package is still wrong). Specifying dependencies must be decoupled from bumping versions. It's because dep specs do depend on the world which can change.. At least that's what I think. Hmm. When I was returning home I thought about some wiki-like system that would allow to say 'Package X is compatible/not compatible with Y'. Possibly something like: - Only the 'sure' deps are installed in default mode - When in 'expert' mode I can install any package which has not been marked as incompatible Then I can say that I tested built and: - It failed to built - It failed the automatic tests (if they exists)/does not work - It success So if there is versions: 0.7 0.8 0.9 1.0 1.0.1 1.1 1.2 1.3 1.4 And: - 0.8 failed to built - =1.0 1.1 was marked by author - 1.1 was marked as success - 1.3 failed to build Then - In default/normal mode it can be used with 1.0, 1.0.1 and 1.1 - In expert mode 0.9 and 1.2 can be installed in addition to above - Any version can be installed in 'I'm feeling lucky' mode when I explicitly say package to ignore some restriction Possibly it is needed to collect user karma (or possibly already account verification is sufficient). If you're interested in Nix and hack-nix I can show you how everything works using an SSH session. Ekhm... SSH? Marc Weber Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cabal dependency hell
On Mon, 2010-03-08 at 15:37 +0100, Marc Weber wrote: Hi Maciej, that's why I started hack-nix. You can patch dependencies easily. However you have to install the Nix package manager. It also works with lates versions only because the dependency solves is written in Nix itself. Which package is causing trouble to you? For example happstack. We can't expect package maintainers to test everything. So it must be people like you and me who fixes those changes. Well. Except that it require bumping versions. Which according to hackage policy requires to fork a project (which makes it pointless in the first place) The way to go is make hackage allow changing constraints on the fly notifying the author that he can update his repository. This will work in most cases. Bumping versions because a dependency has changed is bad as well. This will cause to much overhead (and it dosen't solve the problem because the old package is still wrong). Specifying dependencies must be decoupled from bumping versions. It's because dep specs do depend on the world which can change.. At least that's what I think. Hmm. When I was returning home I thought about some wiki-like system that would allow to say 'Package X is compatible/not compatible with Y'. Possibly something like: - Only the 'sure' deps are installed in default mode - When in 'expert' mode I can install any package which has not been marked as incompatible Then I can say that I tested built and: - It failed to built - It failed the automatic tests (if they exists)/does not work - It success So if there is versions: 0.7 0.8 0.9 1.0 1.0.1 1.1 1.2 1.3 1.4 And: - 0.8 failed to built - =1.0 1.1 was marked by author - 1.1 was marked as success - 1.3 failed to build Then - In default/normal mode it can be used with 1.0, 1.0.1 and 1.1 - In expert mode 0.9 and 1.2 can be installed in addition to above - Any version can be installed in 'I'm feeling lucky' mode when I explicitly say package to ignore some restriction Possibly it is needed to collect user karma (or possibly already account verification is sufficient). If you're interested in Nix and hack-nix I can show you how everything works using an SSH session. Ekhm... SSH? Marc Weber Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
