August 2008 - cabal-devel

patch applied (cabal-install): Always print the message about nothing to install
by Duncan Coutts 14 Aug '08

14 Aug '08

Thu Aug 14 11:53:04 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Always print the message about nothing to install Not just if the user specified -v or --dry-run. Otherwise it's rather confusing. Also clarify that the reason there is nothing to install is because the latest versions are installed already. Also mention the --reinstall flag: Resolving dependencies... No packages to be installed. All the requested packages are already installed. If you want to reinstall anyway then use the --reinstall flag. M ./Distribution/Client/Install.hs -1 +8 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080814185304-adfee-…

1 0

patch applied (cabal-install): Only look for detailed build reports if we were generating them
by Duncan Coutts 14 Aug '08

14 Aug '08

Thu Aug 14 11:48:37 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Only look for detailed build reports if we were generating them M ./Distribution/Client/Install.hs -3 +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080814184837-adfee-…

1 0

patch applied (cabal-install): Add cabal install --reinstall flag
by Duncan Coutts 14 Aug '08

14 Aug '08

Thu Aug 14 11:34:45 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add cabal install --reinstall flag to force reinstall of package where we have the exact same version already installed. Ordinarily we would say that there is nothing to do as the exact same package version is already installed. There are some cases where you might want to do this, eg to rebuild with different compiler options, or adding/removing components (since we do not track those indifidually yet, eg docs, profiling libs). M ./Distribution/Client/Install.hs -6 +17 M ./Distribution/Client/Setup.hs +8 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080814183445-adfee-…

1 0

patch applied (cabal-install): Fetch packages even if they happen to already be installed
by Duncan Coutts 14 Aug '08

14 Aug '08

Thu Aug 14 11:02:01 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fetch packages even if they happen to already be installed Though obviously not if they have already been fetched. This lets people study the source for core packages that came with their compiler say, so they did not get have the sources downloaded via cabal-install. Fixes ticket #297. M ./Distribution/Client/Fetch.hs -6 +28 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080814180201-adfee-…

1 0

Re: Cabal-Install User Experience Feedback
by Duncan Coutts 14 Aug '08

14 Aug '08

On Thu, 2008-08-14 at 12:22 -0700, Jason Dagit wrote: > Can you suggest anything? Currently --help says: > > --enable-library-vanilla Enable Vanilla libraries > --disable-library-vanilla Disable Vanilla libraries > -p --enable-library-profiling Enable Library profiling > --disable-library-profiling Disable Library profiling > > I was thinking something that makes mention that you get twice as much > stuff. > > -p --enable-library-profiling Enable Library profiling and implies > Vanilla libraries Ah, but it doesn't. Each option is independent. You can build only profiling if you --enable-library-profiling --disable-library-vanilla > It seems very nit-picky to comment on the usage of vanilla, because > really that that idiom should be widely understood, but I do it below > anyway :) So I assume vanilla is mostly used to contrast with > profiling. I'm sort of assuming you can get _only_ the profiling > library if you use -p --disable-library-vanilla. Right, exactly. Yeah, I'm not so sure about "vanilla", perhaps "ordinary" or some other word would be better. > Perhaps, "implies" should be "also enables" or "in addition to". > > I recall reading a research paper once about picking terms when > designing command sets that reaffirms the intuition of making sure > your commands are distinct opposites. An example in the paper was > that when designing a command set for giving directions you wouldn't > pick "Left" and "Turn", you'd pick "Left" and "Right" because people > remember opposites more easily. Maybe that gives us a reason to not > use vanilla, or even standard/regular. I have a hard time finding > antonyms for profile or instrumented (I tried some other word forms > there off, still with no luck). In that case I might prefer to see > "standard" instead of vanilla. So what should we use, given the semantics we have (which I think is the right semantics). In future we may well also gain other 'ways' of building a library/executable. Other kinds of profiling, vectorisation etc. We want to be able to enable/disable any combination of these. Duncan

1 0

patch applied (cabal): unbreak for non-GHC
by Malcolm Wallace 14 Aug '08

14 Aug '08

Thu Aug 14 11:25:58 PDT 2008 Malcolm.Wallace(a)cs.york.ac.uk * unbreak for non-GHC M ./Distribution/Simple/Utils.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080814182558-6871e-1dcbdc92…

1 0

Re: Cabal-Install User Experience Feedback
by Duncan Coutts 14 Aug '08

14 Aug '08

On Thu, 2008-08-14 at 09:52 -0700, Jason Dagit wrote: > The main page has the instructions for bug reporting (or via > the cabal home page): > http://hackage.haskell.org/trac/hackage/ > > Ah, I didn't think to go there. I was focused on cabal-install. So clearly we need to update the cabal-install page or persuade google to point somewhere else for cabal-install. Or both. > you can either register or use the guest account. > > Okay. Is this some sort of antispam measure? Yes. Previously we used to drown in spam. > If so, it might be worth investing more time and re-evaluating the > options. If there's something better in trac then we should certainly use it. > I feel as though the current method used by the cabal-install project > is "letting the spammers win". By which I mean, you've stop working > in a convenient way because they are jerks. I wonder if trac has a > way to open the bug submission but require a captcha for people not > logged in? We do allow open registrations now, and the register link is on every page. Of course if one doesn't know to look on the front page then it's not obvious that one has to register (or login as guest) to get the "report a bug" link. > So the things I think that'd fix your problem in future, are: > 1. install/upgrade should report when they think there is nothing to > install since it's using the latest version (this is easy) Done. > 2. allow a way to force the reinstall of a package (easy) Nearly done... > That sounds like a great proposal. It wouldn't hurt if you can find > someone willing to do some technical writing and write more > documentation for cabal-install. Yeah, while the Cabal manual is reasonably comprehensive (if not brilliantly organised), we've got no real docs for cabal-install yet. Of course almost all the UI is the same, but there's not much that says that. > Also, one thing I forgot to mention before, the -p option didn't make > it 100% clear that I would get both normal and profiling builds. It > turns out you get both and that's exactly what I wanted, but I wasn't > confident just from looking at the options. Can you suggest anything? Currently --help says: --enable-library-vanilla Enable Vanilla libraries --disable-library-vanilla Disable Vanilla libraries -p --enable-library-profiling Enable Library profiling --disable-library-profiling Disable Library profiling > Overall cabal-install is coming along very nicely (I forgot to mention > that before). > > Thanks! Thanks :-) Duncan

1 0

Re: Cabal-Install User Experience Feedback
by Duncan Coutts 14 Aug '08

14 Aug '08

On Wed, 2008-08-13 at 22:58 -0700, Jason Dagit wrote: > Hello, > > I tried to use cabal-install but my user experience was less than > satisfactory. Thanks for the feedback Jason. Sorry, I did have a longer version of this email but my net connection currently seems to be having trouble sending emails more than about 4k. So I'm afraid you're getting a shortened version. The main page has the instructions for bug reporting (or via the cabal home page): http://hackage.haskell.org/trac/hackage/ you can either register or use the guest account. > $ cabal install -p ByteString > Resolving dependencies... > > Hmm...What does that mean? So the problem is that we do not track the profiling versions of libs separately. So cabal is noting (but not saying) that there is nothing to do because you've already got bytestring installed. The workaround at the moment is to unregister that package and reinstall with -p So the things I think that'd fix your problem in future, are: 1. install/upgrade should report when they think there is nothing to install since it's using the latest version (this is easy) 2. allow a way to force the reinstall of a package (easy) 3. properly track for each package which components are installed (ordinary libs, profiling libs, docs) and allow the remaining components to be installed (eg cabal install bytestring -p would install just bytestring's prof libs, and all of bytestring's deps that are also missing the profiling libs) (this is hard) 4. implement uninstall (medium difficulty) Anything else? Duncan

1 0

patch applied (cabal): Catch exit exceptions as well as IO exceptions after running programs
by Ian Lynagh 14 Aug '08

14 Aug '08

Wed Aug 13 14:30:35 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Catch exit exceptions as well as IO exceptions after running programs We need to catch IO exceptions for things like "couldn't find the program", but we also need to catch exit exceptions as Cabal uses them to signal what the program returned. M ./Distribution/Simple/Configure.hs -2 +3 M ./Distribution/Simple/GHC.hs -1 +2 M ./Distribution/Simple/Program.hs -2 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080813213035-3fd76-afe5e5ff…

1 0

missing packages on hackage
by Duncan Coutts 13 Aug '08

13 Aug '08

Ross, A user noticed that gentoo's HAppS package was broken because the upstream .tar.gz package had disappeared. Checking the hackage archive it does indeed seem to have gone (except for some log files). Is this intentional or something gone wrong? I don't think we should be removing tarballs, except where the package was uploaded in violation of the upload policy. Certainly we want a mechanism to mark packages as obsolete and drop them from the contents page but I don't think they should be removed from the index tarball or the archive. Duncan

2 1