September 2012 - cabal-devel

Re: Agreeing on a UI for sandboxes
by Mikhail Glushenkov 04 Sep '12

04 Sep '12

Hi, On Wed, Aug 29, 2012 at 1:45 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > 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. One problem with a separate sandbox-init command is that it gives you two ways to specify configure flags. E.g. you can do $ cabal sandbox-init -w /path/to/compiler-1 $ cabal install --only-dependencies and then run $ cabal configure -w /path/to/compiler-2 which will rewrite the package environment file, but then fail due to dependencies not being installed (since we are now using a different compiler). It can also be a bit non-obvious that when you run 'configure' after 'sandbox-init' it uses the configure flags given to 'sandbox-init' earlier (saved in the package environment file). >> 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. [...] > 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. We can make automatic updating of dependencies the default and current behaviour optional. In any case, we need to agree how to update dependencies automatically. A naive algorithm is to just reinstall everything (which is what cabal-dev does). We can try to be a bit smarter and do something like the following: For each dependency added with add-source: If the dependency has already been configured and there is no need to reconfigure: Either just run 'cabal build' and reinstall only if the produced lib/exe is newer than the one we have installed, or get a list of all source files for each target (is this possible?) and rebuild&reinstall only if there is some source file newer than the installed target. Otherwise just configure, build and install. Also, should this happen each time the user runs 'cabal build' or only when running 'cabal install'? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

2 14

Uploading imported package to hackage 2
by Erik Hesselink 01 Sep '12

01 Sep '12

On Fri, Aug 31, 2012 at 11:12 AM, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Fri, Aug 31, 2012 at 2:13 AM, Leon Smith <leon.p.smith(a)gmail.com> wrote: >> Ok, I tried to upload the most recent version of postgresql-simple, and I >> couldn't because I'm not the maintainer for that package. > > What is your account name? I can add you as a maintainer for this package. I've experimented with this a bit. As an admin, I cannot edit the maintainers list. I had to add myself to the trustees group. Then I added myself as the maintainer of one of my packages. However, uploading a new version still failed. I cannot find a way to upload one of the existing imported packages. Does anyone have an idea why? Erik

2 4

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