- cabal-devel - Haskell.org

patch applied (hackage-server): "Disable per-package uploader test"
by devnull＠community.haskell.org 01 Sep '12

01 Sep '12

Sat Sep 1 15:56:58 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Disable per-package uploader test Ignore-this: ddee547da6dd08f27c5a3cbc27089f07 Having both that test, and the uploader group, seems redundant, and will add to the work load of the admins. M ./Distribution/Server/Features/Upload.hs -1 +3

1 0

patch applied (hackage-server): "Allow admins to add/remove admins"
by devnull＠community.haskell.org 30 Aug '12

30 Aug '12

Thu Aug 30 22:58:07 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Allow admins to add/remove admins Ignore-this: 552762da705aee949c063df88e07e445 This fix feels a little unsatisfactory to me. groupResourceAt will modify adminGroupDesc, but it will not modify the nested copies of adminGroupDesc in the canAddGroup/canRemoveGroup lists. I think it's the right fix given the existing system, though. M ./Distribution/Server/Features/Users.hs -2 +2

1 0

Re: Build failed in Jenkins: cabal #56
by Johan Tibell 30 Aug '12

30 Aug '12

On Wed, Aug 29, 2012 at 11:12 AM, Jenkins <jenkins(a)johantibell.com> wrote: > PackageTests/BuildDeps/InternalLibrary0/: > : [Failed] > error should say 'library which is defined within the same package.' > expected: True > but got: False I suspect that this test might be flaky as I've seen it go from passing to failing and back between builds which introduced changes that shouldn't affect this test. I've CCed the original test author. Anyone else knows what's going on here? -- Johan

1 2

Re: Agreeing on a UI for sandboxes
by Johan Tibell 29 Aug '12

29 Aug '12

Hi all, On Wed, Aug 29, 2012 at 3:38 PM, David Terei <dave.terei(a)gmail.com> wrote: > Hi All, > > So my uniformed 2cents. > > I'd really hate having to use normal'ish cabal commands prefixed with > 'sandbox'. I.e., configure-sandbox, build-sandbox... are all horrible. I should have clarified this point. These commands are temporary and hidden and will be removed once we settled on a UI. They exist so we can play around with the mechanism (i.e. sandbox) before we have a real UI for it. Sorry about the confusion. -- Johan

1 0

Re: Agreeing on a UI for sandboxes
by Johan Tibell 29 Aug '12

29 Aug '12

Hi all, I've should have CCed cabal-devel on this discussion from the start. My apologies. I will try to remember to have all these discussion in the open in the future. We're discussing how the sandbox mechanism that cabal got during this year's GSoC should be exposed to users. I've included the discussion so far below: --8<----------------------- Date: Fri, 24 Aug 2012 15:40:14 -0700 Subject: Agreeing on a UI for sandboxes From: Johan Tibell <johan.tibell(a)gmail.com> To: Duncan Coutts <duncan.coutts(a)googlemail.com>, =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com>, Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> Hi all, I've now merged Mikhail's last patches and the remaining work is to figure out how to expose the sandbox mechanism to users in a way that easy to understand and convenient to use. Mikhail has added some hidden commands that you can use to today to work within the sandbox. The goal is to remove these commands in favor of modifying the behavior of the current command set. If we could bring out the different possible designs and issues before ICFP, perhaps we can solve any remaining issues in person there. Mikhail, as a starting point, could you please explain how you'd use these hidden commands (you can probably reuse your description from the pull request). -- Johan --8<----------------------- Date: Sat, 25 Aug 2012 01:01:04 +0200 Subject: Re: Agreeing on a UI for sandboxes From: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> To: Johan Tibell <johan.tibell(a)gmail.com> Cc: Duncan Coutts <duncan.coutts(a)googlemail.com>, =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com> Hi all, On Sat, Aug 25, 2012 at 12:40 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > Mikhail, as a starting point, could you please explain how you'd use > these hidden commands (you can probably reuse your description from > the pull request). There are four new hidden commands: * cabal sandbox-configure Same as 'cabal configure', but also initialises a new sandbox to be used for building. * cabal sandbox-add-source Makes a source package available for installation inside the sandbox. * cabal sandbox-build Builds a package inside the sandbox. * cabal sandbox-install Installs a package into the sandbox. I tried to keep the UI close to the current one, so dependency installation & configuration is still done manually. If a dependency added with sandbox-add-source is updated, it must be manually reinstalled with cabal sandbox-install LibName. Here's an example session: $ git clone git://github.com/haskell/cabal.git $ cd cabal/cabal-install $ cabal sandbox-configure -w /path/to/ghc-7.4.1 $ cabal sandbox-add-source ../Cabal $ cabal sandbox-install --only-dependencies # Since the previous configure only initialised the sandbox $ cabal sandbox-configure -w /path/to/ghc-7.4.1 $ cabal sandbox-build One major annoyance with the current UI is that you often have to run cabal sandbox-configure twice (first to initialise the sandbox, and after that to actually configure the package once the dependencies have been installed). I propose that we make sandbox-configure run 'sandbox-install --only-dependencies' automatically after creating a sandbox. --8<----------------------- Date: Mon, 27 Aug 2012 20:28:29 +0200 Message-ID: <CALjd_v5v8UWMFbLWdXDi-WXt-P+tkmHcgS518wCUycqA2P1pLQ(a)mail.gmail.com> Subject: Re: Agreeing on a UI for sandboxes From: =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com> To: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> Cc: Johan Tibell <johan.tibell(a)gmail.com>, Duncan Coutts <duncan.coutts(a)googlemail.com> Hi. > I tried to keep the UI close to the current one, so dependency > installation & configuration is still done manually. If a dependency > added with sandbox-add-source is updated, it must be manually > reinstalled with cabal sandbox-install LibName. You mean a sandbox-install command to something depending on LibName won't pick it up? > Here's an example session: > > $ git clone git://github.com/haskell/cabal.git > $ cd cabal/cabal-install > $ cabal sandbox-configure -w /path/to/ghc-7.4.1 So I can only create a sandbox in a Cabal package directory? And "cabal sandbox-add-source ." is implicit? > $ cabal sandbox-add-source ../Cabal > $ cabal sandbox-install --only-dependencies Why can't I just say "cabal sandbox-install" at this point? > # Since the previous configure only initialised the sandbox > $ cabal sandbox-configure -w /path/to/ghc-7.4.1 > $ cabal sandbox-build > > One major annoyance with the current UI is that you often have to run > cabal sandbox-configure twice (first to initialise the sandbox, and > after that to actually configure the package once the dependencies > have been installed). I propose that we make sandbox-configure run > 'sandbox-install --only-dependencies' automatically after creating a > sandbox. I'm not particularly fond of having non-install commands download stuff from the internet. Cheers, Andres --8<----------------------- Date: Tue, 28 Aug 2012 03:51:59 +0200 Subject: Re: Agreeing on a UI for sandboxes From: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> To: =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com> Cc: Johan Tibell <johan.tibell(a)gmail.com>, Duncan Coutts <duncan.coutts(a)googlemail.com> Hi, On Mon, Aug 27, 2012 at 8:28 PM, Andres L=F6h <andres.loeh(a)googlemail.com> = wrote: > Hi. > >> I tried to keep the UI close to the current one, so dependency >> installation & configuration is still done manually. If a dependency >> added with sandbox-add-source is updated, it must be manually >> reinstalled with cabal sandbox-install LibName. > > You mean a sandbox-install command to something depending on LibName > won't pick it up? Not if the same version is already installed. We can change it so all dependencies added with add-source are always reinstalled when you run sandbox-install. I'm not quite satisfied with both the current and the proposed solution, ideally it'd possible to detect when some .hs files have changed and the package needs to be reinstalled. >> Here's an example session: >> >> $ git clone git://github.com/haskell/cabal.git >> $ cd cabal/cabal-install >> $ cabal sandbox-configure -w /path/to/ghc-7.4.1 > > So I can only create a sandbox in a Cabal package directory? There is a --sandbox option that lets you specify the location (so shared sandboxes are allowed). > And > "cabal sandbox-add-source ." is implicit? This is not currently being done, but is probably worth adding (to support shared sandboxes better). >> $ cabal sandbox-add-source ../Cabal >> $ cabal sandbox-install --only-dependencies > > Why can't I just say "cabal sandbox-install" at this point? You can use sandbox-install once the sandbox has been created, it's just that I opted to use sandbox-build in the example. > I'm not particularly fond of having non-install commands download > stuff from the internet. Good point, I'm also a bit uneasy about this. On the other hand, running 'sandbox-install --only-dependencies' directly after creating a sandbox is a common use case. I also don't like requiring the user to run 'sandbox-configure' twice. Maybe the sandbox should be initialised by install instead of configure? --8<----------------------- Date: Tue, 28 Aug 2012 08:28:47 +0200 Subject: Re: Agreeing on a UI for sandboxes From: =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com> To: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> Cc: Johan Tibell <johan.tibell(a)gmail.com>, Duncan Coutts <duncan.coutts(a)googlemail.com> Hi. >> You mean a sandbox-install command to something depending on LibName >> won't pick it up? > > Not if the same version is already installed. Ah, ok. But if the version changes, it will. That makes sense. The other point would be fixed if the other GSoC project gets closer to maturity. > We can change it so all > dependencies added with add-source are always reinstalled when you run > sandbox-install. I wouldn't change it yet. If at all, it should be a flag per add-source. Not everything you add-source are libraries you necessarily actively develop at the time. And I guess you can add-source not only local packages, right? > I'm not quite satisfied with both the current and the proposed > solution, ideally it'd possible to detect when some .hs files have > changed and the package needs to be reinstalled. Yes, indeed. >> So I can only create a sandbox in a Cabal package directory? > > There is a --sandbox option that lets you specify the location (so > shared sandboxes are allowed). Cool. >> And >> "cabal sandbox-add-source ." is implicit? > > This is not currently being done, but is probably worth adding (to > support shared sandboxes better). > >>> $ cabal sandbox-add-source ../Cabal >>> $ cabal sandbox-install --only-dependencies >> >> Why can't I just say "cabal sandbox-install" at this point? > > You can use sandbox-install once the sandbox has been created, it's > just that I opted to use sandbox-build in the example. Yes, but that's what makes you end up having to run sanbox-configure twice. >> I'm not particularly fond of having non-install commands download >> stuff from the internet. > > Good point, I'm also a bit uneasy about this. On the other hand, > running 'sandbox-install --only-dependencies' directly after creating > a sandbox is a common use case. I also don't like requiring the user > to run 'sandbox-configure' twice. Maybe the sandbox should be > initialised by install instead of configure? That seems to be more in line with how it works without sandbox-* ? Cheers, Andres --8<----------------------- Date: Tue, 28 Aug 2012 16:55:46 +0200 Subject: Re: Agreeing on a UI for sandboxes From: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> To: =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com> Cc: Johan Tibell <johan.tibell(a)gmail.com>, Duncan Coutts <duncan.coutts(a)googlemail.com> Hi, On Tue, Aug 28, 2012 at 8:28 AM, Andres L=F6h <andres.loeh(a)googlemail.com> = wrote: > Ah, ok. But if the version changes, it will. That makes sense. The > other point would be fixed if the other GSoC project gets closer to > maturity. Looking forward to that! > I wouldn't change it yet. If at all, it should be a flag per > add-source. Not everything you add-source are libraries you > necessarily actively develop at the time. We discussed this - the initial idea was to have a separate link-source command. Johan thinks that it is redundant and it would be best to avoid adding it. One idea is to make 'install' run 'cabal build' on packages added with add-source (those that we depend on) and then only install those files that have actually changed (so that re-linking is avoided). > And I guess you can > add-source not only local packages, right? The plan is to allow linking to remote repositories. This is not yet implemented. >>> I'm not particularly fond of having non-install commands download >>> stuff from the internet. >> >> Good point, I'm also a bit uneasy about this. On the other hand, >> running 'sandbox-install --only-dependencies' directly after creating >> a sandbox is a common use case. I also don't like requiring the user >> to run 'sandbox-configure' twice. Maybe the sandbox should be >> initialised by install instead of configure? > > That seems to be more in line with how it works without sandbox-* ? Kind of. I think that I'll make sandbox-install initialise a sandbox by default because of this use case: $ mkdir darcs && cd darcs $ cabal sandbox-install darcs But using 'install' for building feels inconsistent. For the normal build you are using 'cabal configure && cabal install --only-dependencies && cabal build'. For the sandboxed build you would be using 'cabal install --sandbox'. Ideally, I'd like the differences between workflows to be minimal. Assuming that the standard commands were made sandbox-aware: $ cabal configure --sandbox $ cabal install --only-dependencies $ cabal build But configure fails when the sandbox is empty, so one has to run it twice. --8<----------------------- Date: Tue, 28 Aug 2012 16:45:55 -0700 Subject: Re: Agreeing on a UI for sandboxes From: Johan Tibell <johan.tibell(a)gmail.com> To: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com> Cc: =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com>, Duncan Coutts <duncan.coutts(a)googlemail.com> Hi, I haven't had time to collect my thoughts fully yet, so here are some initial thoughts: It's important that users don't use a mix of sandbox and non-sandbox commands by misstake. That would lead to confusing build errors. Ideally the users should request that work is to be done in a sandbox once and then all commands should use the sandbox. This means that there should be no e.g. cabal build/test/bench --sandbox flags. Perhaps a separate command, cabal init-sandbox, would be the best approach. Running that command would create the right package environment for running in a sandbox and the remaining commands would then use that sandbox. Separating init-sandbox from configure prevents the user from removing the sandbox preference when reconfiguring for some other reason (e.g. to add --enable-tests). To get out of the sandbox the user would edit the package environment file. Alternatively we could have a sandbox command that lets you both add and remove sandboxes. cabal sandbox --init cabal sandbox --delete cabal sandbox --init --path=/path/to/sandbox -- Johan --8<----------------------- Date: Tue, 28 Aug 2012 16:56:20 -0700 Subject: Re: Agreeing on a UI for sandboxes From: Johan Tibell <johan.tibell(a)gmail.com> To: =?ISO-8859-1?Q?Andres_L=F6h?= <andres.loeh(a)googlemail.com> Cc: Mikhail Glushenkov <the.dead.shall.rise(a)gmail.com>, Duncan Coutts <duncan.coutts(a)googlemail.com> On Mon, Aug 27, 2012 at 11:28 PM, Andres L=F6h <andres.loeh(a)googlemail.com>= wrote: >> We can change it so all >> dependencies added with add-source are always reinstalled when you run >> sandbox-install. > > I wouldn't change it yet. If at all, it should be a flag per > add-source. Not everything you add-source are libraries you > necessarily actively develop at the time. And I guess you can > add-source not only local packages, right? I'm worried about making cabal even more cumbersome to use. Today you need to do the following to work on several repos at once: for every dependency: cd $dir cabal configure cabal build cd $main-dir cabal configure --package-db=3D$dir1/dist/package.conf.inplace --package-db=3D$dir1/dist/package.conf.inplace ... If the use manually has to rebuild dependencies every time the change even when using a sandbox we have essentially no improvement over status quo and or cabal-dev. Cabal today is too much about mechanism and not enough about user intentions. Lets try to move it towards the latter, not away from it. Here's my claim, if rebuilding my project requires something more than "cabal build", we did something wrong in designing the user interface. -- Johan

1 0

New cabal-install release (and schedule) needed
by Bryan O'Sullivan 27 Aug '12

27 Aug '12

We need to publish a new cabal-install 0.16 release shortly, ideally before GHC 7.6.1 and the next Haskell Platform come out. At the very least, there's a newish incompatibility between GHC 7.6 and cabal-install that causes all -Werror builds to fail because cabal-install uses a deprecated package flag. This was fixed back in May, but that needs to actually go out into the wild. Stepping back, I'd also like to suggest that we move to a quarterly release cycle on a simple, widely used model. A major goal here is to get code into people's hands on a predictable schedule. We maintain two branches, stable and master. Master freezes a month before a release, with only bugfixes and typo fixes going in. At release time, the stable branch opens (in case any emergency fixes are needed), and master opens up for normal development again. Johan and I are happy to do the work to manage these cycles. I suggest that we start the first cycle with a target release date of the end of September, then go four months to the next one (after all, it would be unrealistic to pretend that we might do a release at the end of December). Does this sound reasonable?

5 14

Some possible solutions for the dependency issues
by Chris Moline 25 Aug '12

25 Aug '12

Hi, so with all the furor over dependency hell I've been thinking about how to address the issue. I've come up with an approach that I'm willing to try to implement, if it's sensible. First is using explicitly versioned libraries and executables. For example, using 'alex-3.0.2' instead of just 'alex'. Next is implementing the suggestion for soft and hard upper bounds. Hard upper bounds would be denoted by a duplicated first character of the relevant operator, ie, <<, <<=, ===. Finally, if an install fails because of dependency versioning issues, automated support for fixing these issues would kick in, probably after prompting the user if they want to attempt it, or after issuing a command such as 'cabal repair'. There would be integration with bug reporting and bug report search so that if there are problems that are more than the user wants to deal with the bug report could be submitted easily. This functionality would be available with the command 'cabal submit-issue'. If the repair was successful patches would be submitted to the maintainer after checking that similar patches haven't been submitted already. Maybe it could be useful for cabal to provide convenient means of communicating with the package maintainer. For example, instead of having to subscribe to the mailing list for gtk 'cabal submit-issue' would present the results of search to see if the issue was already brought up. If the user doesn't think anything relevant came up they could then be presented with a form for filing a bug report. After that the user would be kept in the loop without having to subscribe to the mailing list. So does this sound like a useful solution?

1 1

patch applied (hackage-server): "Don't enable tests when building docs"
by devnull＠community.haskell.org 21 Aug '12

21 Aug '12

Tue Aug 21 18:34:22 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Don't enable tests when building docs Ignore-this: ffe4e86e21c3f4225fb4ec0dd83c9137 css-text-0.1.1's testsuite has been running for over an hour now M ./BuildClient.hs -1

1 0

Cabal install solver as a library
by Benjamin Edwards 20 Aug '12

20 Aug '12

Hi, Was looking at some slides from well typed ( http://www.haskell.org/wikiupload/b/b4/HIW2011-Talk-Loeh.pdf) which suggested that at some point cabal-install would be available as a lib. I am currently trying to get cabal to play nicely with meta-build systems and it would be great if I could dump install plans in json or similar. Is there anyone looking at this? Is it feasible? Would someone be available to mentor such a change if I volunteered some time? Ben

1 0

patch applied (hackage-server): "Forgot to multiply minutes by 60 to get seconds"
by devnull＠community.haskell.org 20 Aug '12

20 Aug '12

Mon Aug 20 13:03:06 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Forgot to multiply minutes by 60 to get seconds Ignore-this: 67860d35111d8db8056353ae8628e081 M ./BuildClient.hs -1 +1

1 0