From peteg42 at gmail.com Tue Jan 1 01:55:09 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Tue Jan 1 01:49:20 2008 Subject: building only the docs In-Reply-To: <1198954850.5982.165.camel@localhost> References: <72158021-C8A1-4783-91A8-D7D5DBB67EA2@gmail.com> <20071224121026.GA31548@matrix.chaos.earth.li> <1198954850.5982.165.camel@localhost> Message-ID: On 30/12/2007, at 2:00 AM, Duncan Coutts wrote: > cabal install --docs --everything-else > > What would the user interface be? Are there any other categories than > docs? Is it additive, subtractive? Can the default be explained in > terms > of the new proposed flags? Interesting questions. I see in a related discussion with Bryan O'Sullivan you say: >> By the way, is there a reason why a .cabal file can specify multiple >> executables, but only one library? LLVM wants to be built in a >> modular >> fashion to minimise the number of dependencies, and it would be >> nice to >> be able to put llvm-common, llvm-core, and llvm-engine all in a >> single >> .cabal file, each with different ld-options. > > It's because we don't yet support building collections of related > packages very well. There have been suggestions that when we do > support > that better that there should only be one library or executable > per .cabal file. So what we really want is a way to say (at least) build/haddock/ install for each package/executable we're interested in as well. HaXml is one example, where I don't really care about the executables and just want the libraries + docs. I expect you and Iain can draw on your experience as distro packagers and thrash this out better than I can. (No pressing need from me, I'm just armchairing again.) cheers peter From trac at galois.com Tue Jan 1 16:21:20 2008 From: trac at galois.com (Hackage) Date: Tue Jan 1 16:15:21 2008 Subject: [Hackage] #197: implement cabal upgrade (installs new versions of all packages) In-Reply-To: <043.090e1a2b105c421ff001edc4fa61e7d1@localhost> References: <043.090e1a2b105c421ff001edc4fa61e7d1@localhost> Message-ID: <052.7f2e727c03b1f562ea73d8497d0fbd3a@localhost> #197: implement cabal upgrade (installs new versions of all packages) ---------------------------------+------------------------------------------ Reporter: ijones | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use. So at the moment the behaviour is: {{{ cabal install foo }}} means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies {{{cabal install foo-1.1}}} then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198). {{{ cabal upgrade }}} means upgrade all upgradable packages. Presumably we upgrade them in dependency order. There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed. One data point that I am familiar with is gentoo's package manager. It has a number of variations: {{{ emerge foo }}} means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested. {{{ emerge foo --update }}} changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version. This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed. {{{ emerge foo --deep }}} This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo. There are also a couple meta-packages. One {{{emerge world}}} which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target. So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 1 16:56:22 2008 From: trac at galois.com (Hackage) Date: Tue Jan 1 16:50:22 2008 Subject: [Hackage] #198: outline for revamp of "cabal install" and upgrade behavior In-Reply-To: <042.3a89c9de745ec8db0eb2c32f82e4c7fe@localhost> References: <042.3a89c9de745ec8db0eb2c32f82e4c7fe@localhost> Message-ID: <051.b75fe18cac00be609bb86aab9d91e0fd@localhost> #198: outline for revamp of "cabal install" and upgrade behavior ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by ijones): * summary: cabal install foo should upgrade foo if there's a newer version => outline for revamp of "cabal install" and upgrade behavior Old description: > As in #168 > > if I have foo-1.0 installed, and foo-2.0 is available, "cabal install > foo" should upgrade foo to version 2.0 > > 1. If the user specifies a package without a version, and a newer > version is available on Hackage, that newer version should be installed. > 2. If the system is installing dependencies on "foo", if the dependency > can be satisfied locally, do not install the "hackage" version, even if > it's newer. > 1. If a user specifies a specific version > 1. if that version is available locally, use that > 1. if a user specifies a version range > 1. if that version can be satisfied locally, but not from hackage, use > the local version > 1. if a newer version on Hackage satisfies the dependency too, install > that. New description: I'm consolidating #168 and #197 here. = Use cases = * "cabal install world --deep" (upgrades all packages, whether required or not) * do we delete obsolete packages too? * "cabal install world" (upgrades only "interesting" packages and any required upgrades) * "cabal install foo" (upgrades foo and any required upgrades from foo) * "cabal install foo --deep" (upgrades foo and all its dependencies whether required or not) = Definitions = * '''Interesting packages''' are packages that a user specifically requests, rather than a package that's installed because of a dependency. * '''Obsolete packages''' are packages which were installed as a dependency on an interesting package, but are no longer depended on by any interesting package. * '''required upgrades''' - if the new version of foo requires a new version of Bar, then we are required to upgrade bar. = behavior of "install foo" = if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that. = background from duncan re gentoo = I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use. So at the moment the behaviour is: {{{ cabal install foo }}} means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies cabal install foo-1.1 then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198). {{{ cabal upgrade }}} means upgrade all upgradable packages. Presumably we upgrade them in dependency order. There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed. One data point that I am familiar with is gentoo's package manager. It has a number of variations: {{{ emerge foo }}} means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested. {{{ emerge foo --update }}} changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version. This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed. {{{ emerge foo --deep }}} This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo. There are also a couple meta-packages. One emerge world which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target. So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 1 16:57:20 2008 From: trac at galois.com (Hackage) Date: Tue Jan 1 16:51:20 2008 Subject: [Hackage] #197: implement cabal upgrade (installs new versions of all packages) In-Reply-To: <043.090e1a2b105c421ff001edc4fa61e7d1@localhost> References: <043.090e1a2b105c421ff001edc4fa61e7d1@localhost> Message-ID: <052.41687e646e8dcd42c6e4f94179963c8d@localhost> #197: implement cabal upgrade (installs new versions of all packages) ---------------------------------+------------------------------------------ Reporter: ijones | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Old description: > much like apt-get, we should have a way to upgrade all of the packages to > the latest version. > > "cabal upgrade" is probably a good name. New description: See [ticket:198 continued discussion]. much like apt-get, we should have a way to upgrade all of the packages to the latest version. "cabal upgrade" is probably a good name. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 1 16:58:25 2008 From: trac at galois.com (Hackage) Date: Tue Jan 1 16:52:26 2008 Subject: [Hackage] #168: Behaviour of cabal-install with respect to upgradeable packages is unexpected In-Reply-To: <042.0de7d213a922d3e288e1ed5885d4a119@localhost> References: <042.0de7d213a922d3e288e1ed5885d4a119@localhost> Message-ID: <051.22bd917bd2f05b29325d3f642bf21818@localhost> #168: Behaviour of cabal-install with respect to upgradeable packages is unexpected ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.0 Severity: normal | Resolution: duplicate Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by ijones): * status: new => closed * resolution: => duplicate Old description: > When an old version of a package is already installed, running cabal- > install to install it should install the latest available version of the > package, rather than complaining that the package is already installed. > (Or at least interactively provide the option to do so.) > > Having it simply abort without doing anything is strange because in the > most common case a user tries to install a package because they need it > and do not already have it. If the package is already installed, that > probably means that they do not have a recent enough version of the > package. > > It would also make cabal-install more apt-like, which is probably a good > thing, considering the obvious inspiration. New description: Note: Consolidating this ticket and others to #198. Please watch that ticket for further developments. When an old version of a package is already installed, running cabal- install to install it should install the latest available version of the package, rather than complaining that the package is already installed. (Or at least interactively provide the option to do so.) Having it simply abort without doing anything is strange because in the most common case a user tries to install a package because they need it and do not already have it. If the package is already installed, that probably means that they do not have a recent enough version of the package. It would also make cabal-install more apt-like, which is probably a good thing, considering the obvious inspiration. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 1 17:18:13 2008 From: trac at galois.com (Hackage) Date: Tue Jan 1 17:12:13 2008 Subject: [Hackage] #198: outline for revamp of "cabal install" and upgrade behavior In-Reply-To: <042.3a89c9de745ec8db0eb2c32f82e4c7fe@localhost> References: <042.3a89c9de745ec8db0eb2c32f82e4c7fe@localhost> Message-ID: <051.2554f8be626f8f66123d6df3e9517374@localhost> #198: outline for revamp of "cabal install" and upgrade behavior ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Old description: > I'm consolidating #168 and #197 here. > > = Use cases = > * "cabal install world --deep" (upgrades all packages, whether required > or not) > * do we delete obsolete packages too? > * "cabal install world" (upgrades only "interesting" packages and any > required upgrades) > * "cabal install foo" (upgrades foo and any required upgrades from foo) > * "cabal install foo --deep" (upgrades foo and all its dependencies > whether required or not) > > = Definitions = > * '''Interesting packages''' are packages that a user specifically > requests, rather than a package that's installed because of a dependency. > * '''Obsolete packages''' are packages which were installed as a > dependency on an interesting package, but are no longer depended on by > any interesting package. > * '''required upgrades''' - if the new version of foo requires a new > version of Bar, then we are required to upgrade bar. > > = behavior of "install foo" = > > if I have foo-1.0 installed, and foo-2.0 is available, "cabal install > foo" should upgrade foo to version 2.0 > > 1. If the user specifies a package without a version, and a newer > version is available on Hackage, that newer version should be installed. > 2. If the system is installing dependencies on "foo", if the dependency > can be satisfied locally, do not install the "hackage" version, even if > it's newer. > 1. If a user specifies a specific version > 1. if that version is available locally, use that > 1. if a user specifies a version range > 1. if that version can be satisfied locally, but not from hackage, use > the local version > 1. if a newer version on Hackage satisfies the dependency too, install > that. > > = background from duncan re gentoo = > I'm glad this is in, I just want to think about the user interface for a > moment; for these variations on installing/upgrading stuff, what mix of > top level commands or modifying flags they should use. > > So at the moment the behaviour is: > > {{{ > cabal install foo > }}} > > means install the package foo only if it is not already installed. If a > newer version is available it is ignored. Though if someone specifies > cabal install foo-1.1 then that really will be installed, even if foo-1.0 > is installed already. This is probably not what most people want (see > #168 & #198). > > {{{ > cabal upgrade > }}} > > means upgrade all upgradable packages. Presumably we upgrade them in > dependency order. > > There are more variations that people would probably like so the question > is, what variations, and how should the user interface allow those things > to be expressed. > > One data point that I am familiar with is gentoo's package manager. It > has a number of variations: > > {{{ > emerge foo > }}} > > means install or re-install package foo. So if a newer one is available, > that newer one will be installed. This is the behaviur that bugs #168 & > #198 are asking for. If foo is already installed and no later version is > available then it is re-installed. The default behavior is not to upgrade > dependencies of foo even if updates are available, that is we > install/upgrade the minimum number of packages necessary to install the > package requested. > > {{{ > emerge foo --update > }}} > > changes the behavior so that foo is not re-installed if it is already > installed. Remember the default behavior was to reinstall foo if it was > the latest version. > > This is probably the most controversial behasvour. It'd make a lot of > sense to reverse the default of this mode and make --update the default > and have something like --force-reinstall to re-install the same version > that is already installed. > > {{{ > emerge foo --deep > }}} > > This modifies the behaviour to also update dependencies. So this updates > the maximal number of packages that are used directly or indirectly by > package foo. > > There are also a couple meta-packages. One emerge world which is all > packages that have ever been explicitly requested (ie not including > packages that were merely dependencies of requested packages). That > detail is probably not necessary, but we could do with an everything > target. > > So in this gentoo semantics, we'd express the new upgrade command by > {{{ > emerge world --update --deep > }}} New description: I'm consolidating #168 and #197 here. = Use cases = * "cabal install world --deep" (upgrades all packages, whether required or not) * do we delete obsolete packages too? * "cabal install world" (upgrades only "interesting" packages and any required upgrades) * "cabal install foo" (upgrades foo and any required upgrades from foo) * "cabal install foo --deep" (upgrades foo and all its dependencies whether required or not) = Definitions = * '''Interesting packages''' are packages that a user specifically requests, rather than a package that's installed because of a dependency. * If someone specifies a version number, is that version itself "interesting"? * '''Obsolete packages''' are packages which were installed as a dependency on an interesting package, but are no longer depended on by any interesting package. * '''required upgrades''' - if the new version of foo requires a new version of Bar, then we are required to upgrade bar. = Niggly Questions = * Rebuilding packages * If Foo depends on Bar, and Bar gets upgraded for whatever reason, should we rebuild Foo, even if it wasn't upgraded, so it uses the new Bar? * This obviously could require rebuilding all the way up the dependency tree. * Deleting packages: * Do we delete obsolete packages? * If we rebuild packages as above, do we delete old versions of uninteresting packages, considering them obsolete? * Do we delete old versions of interesting packages? = behavior of "install foo" = if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that. = background from duncan re gentoo = I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use. So at the moment the behaviour is: {{{ cabal install foo }}} means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies cabal install foo-1.1 then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198). {{{ cabal upgrade }}} means upgrade all upgradable packages. Presumably we upgrade them in dependency order. There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed. One data point that I am familiar with is gentoo's package manager. It has a number of variations: {{{ emerge foo }}} means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested. {{{ emerge foo --update }}} changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version. This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed. {{{ emerge foo --deep }}} This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo. There are also a couple meta-packages. One emerge world which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target. So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 1 17:36:00 2008 From: trac at galois.com (Hackage) Date: Tue Jan 1 17:30:00 2008 Subject: [Hackage] #198: outline for revamp of "cabal install" and upgrade behavior In-Reply-To: <042.3a89c9de745ec8db0eb2c32f82e4c7fe@localhost> References: <042.3a89c9de745ec8db0eb2c32f82e4c7fe@localhost> Message-ID: <051.431e4dfe3e5066205eadfbd557e21994@localhost> #198: outline for revamp of "cabal install" and upgrade behavior ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Old description: > I'm consolidating #168 and #197 here. > > = Use cases = > * "cabal install world --deep" (upgrades all packages, whether required > or not) > * do we delete obsolete packages too? > * "cabal install world" (upgrades only "interesting" packages and any > required upgrades) > * "cabal install foo" (upgrades foo and any required upgrades from foo) > * "cabal install foo --deep" (upgrades foo and all its dependencies > whether required or not) > > = Definitions = > * '''Interesting packages''' are packages that a user specifically > requests, rather than a package that's installed because of a dependency. > * If someone specifies a version number, is that version itself > "interesting"? > * '''Obsolete packages''' are packages which were installed as a > dependency on an interesting package, but are no longer depended on by > any interesting package. > * '''required upgrades''' - if the new version of foo requires a new > version of Bar, then we are required to upgrade bar. > > = Niggly Questions = > * Rebuilding packages > * If Foo depends on Bar, and Bar gets upgraded for whatever reason, > should we rebuild Foo, even if it wasn't upgraded, so it uses the new > Bar? > * This obviously could require rebuilding all the way up the > dependency tree. > * Deleting packages: > * Do we delete obsolete packages? > * If we rebuild packages as above, do we delete old versions of > uninteresting packages, considering them obsolete? > * Do we delete old versions of interesting packages? > > = behavior of "install foo" = > > if I have foo-1.0 installed, and foo-2.0 is available, "cabal install > foo" should upgrade foo to version 2.0 > > 1. If the user specifies a package without a version, and a newer > version is available on Hackage, that newer version should be installed. > 2. If the system is installing dependencies on "foo", if the dependency > can be satisfied locally, do not install the "hackage" version, even if > it's newer. > 1. If a user specifies a specific version > 1. if that version is available locally, use that > 1. if a user specifies a version range > 1. if that version can be satisfied locally, but not from hackage, use > the local version > 1. if a newer version on Hackage satisfies the dependency too, install > that. > > = background from duncan re gentoo = > I'm glad this is in, I just want to think about the user interface for a > moment; for these variations on installing/upgrading stuff, what mix of > top level commands or modifying flags they should use. > > So at the moment the behaviour is: > > {{{ > cabal install foo > }}} > > means install the package foo only if it is not already installed. If a > newer version is available it is ignored. Though if someone specifies > cabal install foo-1.1 then that really will be installed, even if foo-1.0 > is installed already. This is probably not what most people want (see > #168 & #198). > > {{{ > cabal upgrade > }}} > > means upgrade all upgradable packages. Presumably we upgrade them in > dependency order. > > There are more variations that people would probably like so the question > is, what variations, and how should the user interface allow those things > to be expressed. > > One data point that I am familiar with is gentoo's package manager. It > has a number of variations: > > {{{ > emerge foo > }}} > > means install or re-install package foo. So if a newer one is available, > that newer one will be installed. This is the behaviur that bugs #168 & > #198 are asking for. If foo is already installed and no later version is > available then it is re-installed. The default behavior is not to upgrade > dependencies of foo even if updates are available, that is we > install/upgrade the minimum number of packages necessary to install the > package requested. > > {{{ > emerge foo --update > }}} > > changes the behavior so that foo is not re-installed if it is already > installed. Remember the default behavior was to reinstall foo if it was > the latest version. > > This is probably the most controversial behasvour. It'd make a lot of > sense to reverse the default of this mode and make --update the default > and have something like --force-reinstall to re-install the same version > that is already installed. > > {{{ > emerge foo --deep > }}} > > This modifies the behaviour to also update dependencies. So this updates > the maximal number of packages that are used directly or indirectly by > package foo. > > There are also a couple meta-packages. One emerge world which is all > packages that have ever been explicitly requested (ie not including > packages that were merely dependencies of requested packages). That > detail is probably not necessary, but we could do with an everything > target. > > So in this gentoo semantics, we'd express the new upgrade command by > {{{ > emerge world --update --deep > }}} New description: I'm consolidating #168 and #197 here. = Use cases = * "cabal install world --deep" (upgrades all packages, whether required or not) * do we delete obsolete packages too? * "cabal install world" (upgrades only "interesting" packages and any required upgrades) * "cabal install foo" (upgrades foo and any required upgrades from foo) * "cabal install foo --deep" (upgrades foo and all its dependencies whether required or not) = Definitions = * '''Interesting packages''' are packages that a user specifically requests, rather than a package that's installed because of a dependency. * If someone specifies a version number, is that version itself "interesting"? * '''Obsolete packages''' are packages which were installed as a dependency on an interesting package, but are no longer depended on by any interesting package. * '''required upgrades''' if the new version of foo requires a new version of Bar, then we are required to upgrade bar. * '''Minimal upgrade''' do the minimal necessary installs/upgrades to install a target package. This means prefering installed packages to packages from hackage even if the version on hackage is newer. * '''Maximal upgrade''' do the maximal upgrades to install a target package. So all dependencies are upgraded too, even if later versions are not required. This means prefering the latest available package irrespective of wether some version is already installed. = Niggly Questions = * Rebuilding packages * If Foo depends on Bar, and Bar gets upgraded for whatever reason, should we rebuild Foo, even if it wasn't upgraded, so it uses the new Bar? * This obviously could require rebuilding all the way up the dependency tree. * Deleting packages: * Do we delete obsolete packages? * If we rebuild packages as above, do we delete old versions of uninteresting packages, considering them obsolete? * Do we delete old versions of interesting packages? = behavior of "install foo" = if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 1. If the user specifies a package without a version, and a newer version is available on Hackage, that newer version should be installed. 2. If the system is installing dependencies on "foo", if the dependency can be satisfied locally, do not install the "hackage" version, even if it's newer. 1. If a user specifies a specific version 1. if that version is available locally, use that 1. if a user specifies a version range 1. if that version can be satisfied locally, but not from hackage, use the local version 1. if a newer version on Hackage satisfies the dependency too, install that. = background from duncan re gentoo = I'm glad this is in, I just want to think about the user interface for a moment; for these variations on installing/upgrading stuff, what mix of top level commands or modifying flags they should use. So at the moment the behaviour is: {{{ cabal install foo }}} means install the package foo only if it is not already installed. If a newer version is available it is ignored. Though if someone specifies cabal install foo-1.1 then that really will be installed, even if foo-1.0 is installed already. This is probably not what most people want (see #168 & #198). {{{ cabal upgrade }}} means upgrade all upgradable packages. Presumably we upgrade them in dependency order. There are more variations that people would probably like so the question is, what variations, and how should the user interface allow those things to be expressed. One data point that I am familiar with is gentoo's package manager. It has a number of variations: {{{ emerge foo }}} means install or re-install package foo. So if a newer one is available, that newer one will be installed. This is the behaviur that bugs #168 & #198 are asking for. If foo is already installed and no later version is available then it is re-installed. The default behavior is not to upgrade dependencies of foo even if updates are available, that is we install/upgrade the minimum number of packages necessary to install the package requested. {{{ emerge foo --update }}} changes the behavior so that foo is not re-installed if it is already installed. Remember the default behavior was to reinstall foo if it was the latest version. This is probably the most controversial behasvour. It'd make a lot of sense to reverse the default of this mode and make --update the default and have something like --force-reinstall to re-install the same version that is already installed. {{{ emerge foo --deep }}} This modifies the behaviour to also update dependencies. So this updates the maximal number of packages that are used directly or indirectly by package foo. There are also a couple meta-packages. One emerge world which is all packages that have ever been explicitly requested (ie not including packages that were merely dependencies of requested packages). That detail is probably not necessary, but we could do with an everything target. So in this gentoo semantics, we'd express the new upgrade command by {{{ emerge world --update --deep }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Jan 4 10:55:56 2008 From: trac at galois.com (Hackage) Date: Fri Jan 4 10:49:54 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.b276a2fbee988bc0ccda2b97268185b1@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Changes (by guest): * ghcversion: 6.8.1 => 6.8.2 Comment: cabal should not need to pass `$HOME/Library/Frameworks` to ghc. ghc itself should pass `-F$HOME/Library/Frameworks` to gcc and the linker on Macs. See my (most recent) file `DriverPipeline.hs` in http://hackage.haskell.org/trac/ghc/ticket/1395 Christian (.Maeder@dfki.de) -- Ticket URL: Hackage Hackage: Cabal and related projects From igloo at earth.li Fri Jan 4 11:49:59 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 4 11:43:51 2008 Subject: building only the docs In-Reply-To: <1198954850.5982.165.camel@localhost> References: <72158021-C8A1-4783-91A8-D7D5DBB67EA2@gmail.com> <20071224121026.GA31548@matrix.chaos.earth.li> <1198954850.5982.165.camel@localhost> Message-ID: <20080104164959.GA7731@matrix.chaos.earth.li> On Sat, Dec 29, 2007 at 07:00:49PM +0000, Duncan Coutts wrote: > > On Mon, 2007-12-24 at 12:10 +0000, Ian Lynagh wrote: > > > > Related to this, there'e no way to install only the docs or only the > > binaries when both are built, as far as I know. This isn't a huge > > problem, but it ought to be easy to fix and it would be nice to have. Oh, another thing that would make my life a lot easier is a flag for whether or not to install the license file. > > It would have made things slightly simpler for me when building separate > > -doc and -dev Debian packages for Cabal libraries, and it also would > > mean we could do the right thing in GHC's "make install-docs". > > cabal install --docs --everything-else > > What would the user interface be? Are there any other categories than > docs? OTTOMH, there's a tree of things like: all docs haddock-interfaces html license binaries library executables executable=foo executable=bar although we don't necessarily have to be as granular as that. > Is it additive, subtractive? Can the default be explained in terms > of the new proposed flags? As long as docs, license and binaries can be (de)selected individually I don't really mind. If you want a concrete suggestion, we could have --foo and --no-foo for each thing, with the default being --all and the commandline being processed left-to-right, e.g. cabal install --no-haddock-interfaces --docs --no-html would install all (which wouldn't actually contain anything) docs (which wouldn't actually contain anything) haddock-interfaces license everything under binaries Thanks Ian From igloo at earth.li Fri Jan 4 12:08:26 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 4 12:02:18 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <1198978845.5982.187.camel@localhost> References: <79d7c4980711281437q95fa804h66d992709a349b@mail.gmail.com> <1196332390.21580.25.camel@localhost> <79d7c4980711290318w1f13e442g33c7c4b0ef14a514@mail.gmail.com> <1196338485.21580.41.camel@localhost> <125EACD0CAE4D24ABDB4D148C4593DA9049E915A@GBLONXMB02.corp.amvescap.net> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> Message-ID: <20080104170826.GA7601@matrix.chaos.earth.li> On Sun, Dec 30, 2007 at 01:40:44AM +0000, Duncan Coutts wrote: > > One bit I'm less sure about is the handling of paragraphs in comments. > Currently the code transforms: > > blah blah > > blah blah > > into > > -- blah blah > > -- blah blah > > but it transforms > > blah blah > > blah blah > > into > > -- blah blah > -- > -- blah blah > > spot the difference? Yeah, just white space. The completely blank line > separates the paragraphs into two comments which haddock will treat > differently from a single comment. I think both your examples should be treated the same, although I don't know whether they should be treated as one or two comments. Invisible whitespace is generally ignored elsewhere in Haskell, e.g. when determining if a literate comment is next to a bird track, or after a \ starting a string gap, the rationale being that if you can't see a difference then there shouldn't be one. Thanks Ian From trac at galois.com Fri Jan 4 12:49:47 2008 From: trac at galois.com (Hackage) Date: Fri Jan 4 12:43:40 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.6a5105cd920921cee9befccd227e2bcf@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): I don't know much about frameworks, could someone tell me: 1. How are framework paths supposed to be found generally? 1. Are their locations fixed or do their location vary from one machine to the next? 1. Are frameworks versioned? 1. Can we find frameworks at configure time rather than failing at link time? If framework paths vary from one machine to another then putting "framework-dirs:" in the .cabal file would not make a lot of sense. If they cannot be found automatically and require extra information from the user then perhaps it should be a configure option. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri Jan 4 13:01:23 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 4 12:55:15 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <20080104170826.GA7601@matrix.chaos.earth.li> References: <79d7c4980711281437q95fa804h66d992709a349b@mail.gmail.com> <1196332390.21580.25.camel@localhost> <79d7c4980711290318w1f13e442g33c7c4b0ef14a514@mail.gmail.com> <1196338485.21580.41.camel@localhost> <125EACD0CAE4D24ABDB4D148C4593DA9049E915A@GBLONXMB02.corp.amvescap.net> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> <20080104170826.GA7601@matrix.chaos.earth.li> Message-ID: <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> In message <20080104170826.GA7601@matrix.chaos.earth.li> Duncan Coutts , Alistair Bayley , cabal-devel@haskell.org writes: > > spot the difference? Yeah, just white space. The completely blank line > > separates the paragraphs into two comments which haddock will treat > > differently from a single comment. > > I think both your examples should be treated the same, although I don't > know whether they should be treated as one or two comments. Alistair, can you remind us why we need the ability to break paragraphs into multiple comments rather than a single comment? Or is it just that we need to be able to have a comment followed by a blank line and then code. eg blah blah > some code into -- blah blah some code rather than: -- blah blah -- some code is that all? I think that so long as we can avoid generating spurious comment-next-to-code errors, the above distinction is irrelevant. We could avoid comment next to code errors by using an extra comment/blank state for blank lines trailing comments. They'd be transformed into comments but could transition to > bird track lines without a code-next-to-comment error. Perhaps I'll send a patch to implement that. > Invisible whitespace is generally ignored elsewhere in Haskell, e.g. > when determining if a literate comment is next to a bird track, or after > a \ starting a string gap, the rationale being that if you can't see a > difference then there shouldn't be one. I agree, whatever distinction might be necessary it should not be done on the basis of something that's invisible. Duncan From trac at galois.com Fri Jan 4 19:15:05 2008 From: trac at galois.com (Hackage) Date: Fri Jan 4 19:08:56 2008 Subject: [Hackage] #203: Find out what we can learn from ruby gems Message-ID: <043.29d9b1710a1ff651815ee270a6cebd9e@localhost> #203: Find out what we can learn from ruby gems ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------+------------------------------------------------------ [http://rubygems.org/ Ruby Gems] is superficially a similar system for Ruby as Cabal + cabal-install + HackageDB is for Haskell. This task is to do some research to compare two systems to find out what lessons we can learn from Ruby Gems. The findings should be recorded on the [wiki:RubyGems] wiki page -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Jan 5 14:20:55 2008 From: trac at galois.com (Hackage) Date: Sat Jan 5 14:14:44 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.44e0acd85e9807821db55985e3e7dfc6@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): Replying to [comment:3 duncan]: > I don't know much about frameworks, could someone tell me: Briefly: A framework is a directory ending in `.framework` which stores the header and object files associated with a library. Saying `"-framework GNUreadline"` is like saying `"-lreadline"`. Saying `"-F$HOME/Library/Frameworks"` is like saying `"-I$HOME/includes -L$HOME/lib"` . > 1. How are framework paths supposed to be found generally? > 1. Are their locations fixed or do their location vary from one machine to the next? The frameworks themselves are found automatically by `gcc` and `ld`, as long as they're stored in either `/System/Library/Frameworks` (for Apple's use only) or `/Library/Frameworks` (for user-installed frameworks). Sometimes they are stored in other standard locations: - $HOME/Library/Frameworks (if you don't have administrator access) - /Network/Library/Frameworks (if the framework should be shared by several users on a network) The problem is that the compiler and linker don't search those folders by default (although the runtime dynamic loader does). So calling `gcc` with `-F$HOME/Library/Frameworks` tells it to search that folder for any required frameworks. Another reason to use a nonstandard location is testing a build against a new version of a framework. > 1. Are frameworks versioned? Yes, and you can distribute one framework which contains multiple versions. The technical details are at http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html > 1. Can we find frameworks at configure time rather than failing at link time? > If framework paths vary from one machine to another then putting "framework-dirs:" in the .cabal file would not make a lot of sense. If they cannot be found automatically and require extra information from the user then perhaps it should be a configure option. As I said above, the `-F` flag is the equivalent of the `-I` and `-L` flags. So I think that `framework-dirs` should be in the `cabal` file just like `include-dirs` and `extra-lib-dirs` are. -Judah -- Ticket URL: Hackage Hackage: Cabal and related projects From alistair at abayley.org Sat Jan 5 18:14:44 2008 From: alistair at abayley.org (Alistair Bayley) Date: Sat Jan 5 18:08:32 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> References: <79d7c4980711281437q95fa804h66d992709a349b@mail.gmail.com> <1196338485.21580.41.camel@localhost> <125EACD0CAE4D24ABDB4D148C4593DA9049E915A@GBLONXMB02.corp.amvescap.net> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> <20080104170826.GA7601@matrix.chaos.earth.li> <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> Message-ID: <79d7c4980801051514m106a4f47r3128b5d13a60a05@mail.gmail.com> Duncan, Sorry, I haven't had time to look at your patch yet. Still on holiday. > Alistair, can you remind us why we need the ability to break paragraphs into > multiple comments rather than a single comment? One example: In Takusen's Database.Enumerator module we use named chunks. The chucks are all placed at the end of the file. A given chunk may contain many paragraphs, but it must consist of a single comment block. Separate chunks must be in separate comment blocks (I assume; I haven't actually tested this). Another example: Let's say you want to produce this .hs output for Haddock: -- | A description of x -- -- some more comments about x x = ... Now imagine you want to produce this .hs: -- | A description of x -- some comments which are interesting but we don't want Haddock to use them x = ... What do you write in your .lhs file to produce these outputs? I chose a fairly simple rule: a line containing some whitespace chars continued the current comment block, while a truly empty line ended it. > > Invisible whitespace is generally ignored elsewhere in Haskell > > I agree, whatever distinction might be necessary it should not be done on the > basis of something that's invisible. Yes, choosing to use non-empty whitespace (to indicate that a comment block is not finished) might well be a poor design decision. Another possibility is to use a line containing a single period as a continuation line e.g. line 1 . line 2 becomes -- line 1 -- -- line 2 ... while whitespace only just outputs an empty line (no comment). Do you think that is a better choice? The extra state idea might be an improvement over the current design. Currently we have to look ahead in the comment state to decide to transition to the blank or comment states. An extra state would probably avoid the lookahead. I'll try it out to see how well it works. Alistair From trac at galois.com Sun Jan 6 00:58:58 2008 From: trac at galois.com (Hackage) Date: Sun Jan 6 00:52:44 2008 Subject: [Hackage] #204: should setting user-prefix in ~/.cabal/config work? Message-ID: <042.d7718dd94772380071129e7a86c7c2aa@localhost> #204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ Setting user-prefix in .cabal/config leads to the following error: {{{ wolverian@puni:~$ cabal info xmonad Warning: Error parsing config file /home/wolverian/.cabal/config: On line 5: Parse of field 'prefix' failed: Warning: Using default configuration. }}} I don't think the file format is documented anywhere, but a bit of poking in the source and a Google led me to believe that this should work. My config file looks like this: {{{ wolverian@puni:~$ cat .cabal/config compiler: GHC repos: hackage.haskell.org:http://hackage.haskell.org/packages/archive cachedir: "/home/wolverian/.cabal/packages" user-install: true user-prefix: "/home/wolverian" hackage-username: "" hackage-password: "" }}} This is with up-to-date (as of today) Cabal and cabal-install from Darcs: {{{ wolverian@puni:~$ cabal --version cabal-install version 0.4.1 using version 1.3.2 of the Cabal library }}} And my GHC is a local (in ~) GHC 6.8.2: {{{ wolverian@puni:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} -- wolverian[[BR]] ilmari.vacklin@cs.helsinki.fi -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sun Jan 6 00:59:41 2008 From: trac at galois.com (Hackage) Date: Sun Jan 6 00:53:28 2008 Subject: [Hackage] #204: should setting user-prefix in ~/.cabal/config work? In-Reply-To: <042.d7718dd94772380071129e7a86c7c2aa@localhost> References: <042.d7718dd94772380071129e7a86c7c2aa@localhost> Message-ID: <051.c317c91f469cc2352a407f01c963dd99@localhost> #204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by guest): * version: 1.2.3.0 => HEAD -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sun Jan 6 08:22:25 2008 From: trac at galois.com (Hackage) Date: Sun Jan 6 08:16:12 2008 Subject: [Hackage] #204: should setting user-prefix in ~/.cabal/config work? In-Reply-To: <042.d7718dd94772380071129e7a86c7c2aa@localhost> References: <042.d7718dd94772380071129e7a86c7c2aa@localhost> Message-ID: <051.58d0e2ccb8eb77b0779f66a8e4acc185@localhost> #204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): That is indeed supposed to work. We'll have to investigate. -- Ticket URL: Hackage Hackage: Cabal and related projects From igloo at earth.li Sun Jan 6 10:56:54 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 6 10:50:41 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <79d7c4980801051514m106a4f47r3128b5d13a60a05@mail.gmail.com> References: <1196338485.21580.41.camel@localhost> <125EACD0CAE4D24ABDB4D148C4593DA9049E915A@GBLONXMB02.corp.amvescap.net> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> <20080104170826.GA7601@matrix.chaos.earth.li> <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> <79d7c4980801051514m106a4f47r3128b5d13a60a05@mail.gmail.com> Message-ID: <20080106155654.GA1616@matrix.chaos.earth.li> On Sat, Jan 05, 2008 at 11:14:44PM +0000, Alistair Bayley wrote: > > Yes, choosing to use non-empty whitespace (to indicate that a comment > block is not finished) might well be a poor design decision. Another > possibility is to use a line containing a single period as a > continuation line e.g. > > line 1 > . > line 2 I think we do this in Cabal descriptions (copying the design from Debian package's descriptions), so this would be consistent with that. It gets my vote! Thanks Ian From trac at galois.com Mon Jan 7 09:30:43 2008 From: trac at galois.com (Hackage) Date: Mon Jan 7 09:24:27 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.677da0db3228991ec7eadbb8b5e48506@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by duncan): Correct me if I'm wrong... So we already have a frameworks field in the .cabal file. So we know which frameworks we need. gcc/ghc knows where to find these frameworks at compile and link time if they are installed in the standard place (now that ghc tells gcc to look in $HOME/Library/Frameworks). So is the only problem that we cannot find frameworks if they are installed in non-standard locations? If so then I do not see that adding a framework-paths field to the .cabal file will help since if it's a non- standard path then it varies from one machine to another so putting it in the .cabal file is pointless. If we really have a need to find framworks in non-standard places then perhaps a configure flag is in order. The point about include-dirs and extra-lib-dirs is that they are for dirs that are standard locations across machines, eg /usr/include/mysql. Or if they have to be found on each machine then the values can be filled in using custom code in Setup.hs or a ./configure script. This might be useful to frameworks too if there is some way of finding them automatically. Am I still not understanding the problem? -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 7 10:15:58 2008 From: trac at galois.com (Hackage) Date: Mon Jan 7 10:09:42 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.71dcfa43443188052c1648fa063ded35@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): So far, I've seen no application of the -framework-path of ghc (except maybe to pass `$HOME/Library/Frameworks`) and also no use of the package.conf entry `frameworkDirs` (I think, it may be nuked.) Frameworks are usually in standard places. Christian (.Maeder@dfki.de) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 7 12:34:21 2008 From: trac at galois.com (Hackage) Date: Mon Jan 7 12:28:04 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.8967bb6b7955591a6253276de687bfd2@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): > So far, I've seen no application of the -framework-path of ghc (except maybe to pass `$HOME/Library/Frameworks`) and also no use of the package.conf entry `frameworkDirs` (I think, it may be nuked.) Frameworks are usually in standard places. > > Christian (.Maeder@dfki.de) When I was testing problems with `GNUreadline.framework`, I often wanted a way to link against a second version of the framework in a nonstandard location. For example, if I was booting ghc-6.9 with ghc-6.2, I wanted ghc-6.2 to use the old version of `GNUreadline.framework` but ghc-6.9 to use the new version. So I definitely think it's useful. But I would be happy with Duncan's suggestion to make it a configure flag instead of a .cabal file field, as long as: 1. Cabal provides that functionality automatically (without me having to manually edit an autoconf script) 2. The results of that flag end up in ghc's `package.conf` `frameworkDirs` field. -Judah -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 7 12:43:37 2008 From: trac at galois.com (Hackage) Date: Mon Jan 7 12:37:21 2008 Subject: [Hackage] #189: Handle framework paths (-F) in Cabal In-Reply-To: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> References: <042.8cdc419bd269d78bbbefd9078ef29fc6@localhost> Message-ID: <051.49df00164aa125f54bae554871ba5651@localhost> #189: Handle framework paths (-F) in Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Mac OS ----------------------------+----------------------------------------------- Comment (by guest): There's another use for -framework-path that I just thought of: Apple provides old versions of the system frameworks, e.g. on my 10.4 machine I have `/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/` which is not searched by default. -Judah -- Ticket URL: Hackage Hackage: Cabal and related projects From david.waern at gmail.com Tue Jan 8 16:28:44 2008 From: david.waern at gmail.com (David Waern) Date: Tue Jan 8 16:22:23 2008 Subject: Patch for more liberal parsing of build-tools Message-ID: Patch attached. David -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-liberal-build-tool-names.patch Type: text/x-patch Size: 27587 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080108/38f6d269/cabal-liberal-build-tool-names-0001.bin From duncan.coutts at worc.ox.ac.uk Wed Jan 9 08:39:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 9 08:34:17 2008 Subject: Tests in Cabal In-Reply-To: <4784A184.6080708@iee.org> References: <4784A184.6080708@iee.org> Message-ID: <1199885961.7279.125.camel@localhost> On Wed, 2008-01-09 at 10:27 +0000, Adrian Hey wrote: > Is this really the way tests are supposed to be included? > > It doesn't seem workable to me. I wonder if it would be better to just > build the lib first (without tests) and then separately build one or > more test executables? > > What does everyone else do about this? I've only seen one package that actually uses tests integrated into the Setup.hs. So it seems everyone just runs tests manually. This is a fairly large hole in the Cabal story at the moment imho. Part of the problem is that we don't support custom Setup.hs stuff very well, we encourage people to use the simple build system. But for tests, even if it used the simple build system we'd end up making it use the custom flavour just to run some tests. It's not very satisfactory. I wonder if we shouldn't move tests into their own file completely. The problem always with custom Setup.hs scripts is that they're the first point of entry, and if it does not compile then everything is stuffed and you don't get a good error message. Duncan From lemming at henning-thielemann.de Wed Jan 9 08:49:08 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 9 08:45:59 2008 Subject: Tests in Cabal In-Reply-To: <1199885961.7279.125.camel@localhost> References: <4784A184.6080708@iee.org> <1199885961.7279.125.camel@localhost> Message-ID: On Wed, 9 Jan 2008, Duncan Coutts wrote: > On Wed, 2008-01-09 at 10:27 +0000, Adrian Hey wrote: > > > Is this really the way tests are supposed to be included? > > > > It doesn't seem workable to me. I wonder if it would be better to just > > build the lib first (without tests) and then separately build one or > > more test executables? > > > > What does everyone else do about this? > > I've only seen one package that actually uses tests integrated into the > Setup.hs. So it seems everyone just runs tests manually. This is a > fairly large hole in the Cabal story at the moment imho. > > Part of the problem is that we don't support custom Setup.hs stuff very > well, we encourage people to use the simple build system. But for tests, > even if it used the simple build system we'd end up making it use the > custom flavour just to run some tests. It's not very satisfactory. > > I wonder if we shouldn't move tests into their own file completely. ... as it is planned for executables, right? I used the Cabal test mechanism once, but it was not portable between different versions of Cabal. Thus I added an Executable stanza to the Cabal file and run the resulting test binary by darcs. Of course I think that in the long run tests should be managed by Cabal somehow in order to let Hackage check uploaded packages against their test suites or in order to let compiler implementors check whether new compiler versions break existing code. From ross at soi.city.ac.uk Wed Jan 9 08:54:37 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 9 08:48:19 2008 Subject: Tests in Cabal In-Reply-To: <1199885961.7279.125.camel@localhost> References: <4784A184.6080708@iee.org> <1199885961.7279.125.camel@localhost> Message-ID: <20080109135437.GA7571@soi.city.ac.uk> On Wed, Jan 09, 2008 at 01:39:21PM +0000, Duncan Coutts wrote: > I've only seen one package that actually uses tests integrated into the > Setup.hs. So it seems everyone just runs tests manually. This is a > fairly large hole in the Cabal story at the moment imho. > > Part of the problem is that we don't support custom Setup.hs stuff very > well, we encourage people to use the simple build system. But for tests, > even if it used the simple build system we'd end up making it use the > custom flavour just to run some tests. It's not very satisfactory. > > I wonder if we shouldn't move tests into their own file completely. The > problem always with custom Setup.hs scripts is that they're the first > point of entry, and if it does not compile then everything is stuffed > and you don't get a good error message. Yes, I think a file-level hook for tests is the way to go. From duncan.coutts at worc.ox.ac.uk Wed Jan 9 09:18:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 9 09:11:58 2008 Subject: patch applied (cabal): Allow symbol characters (e.g '+') in the components of a build-tool name Message-ID: <20080109141818.GA25713@haskell.galois.com> Tue Jan 8 13:12:18 PST 2008 David Waern * Allow symbol characters (e.g '+') in the components of a build-tool name M ./Distribution/PackageDescription.hs -1 +1 M ./Distribution/ParseUtils.hs -2 +20 From duncan.coutts at worc.ox.ac.uk Wed Jan 9 19:09:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 9 19:03:19 2008 Subject: patch applied (cabal-install): Added support for users behind proxy servers, reading system settings from the env var on unix or registry on windows Message-ID: <20080110000943.GA5708@haskell.galois.com> Fri Dec 21 12:15:00 PST 2007 * Added support for users behind proxy servers, reading system settings from the env var on unix or registry on windows M ./Hackage/Fetch.hs -8 +5 A ./Hackage/HttpUtils.hs M ./Hackage/Upload.hs -2 +5 M ./cabal-install.cabal +7 From alistair at abayley.org Thu Jan 10 09:25:41 2008 From: alistair at abayley.org (Alistair Bayley) Date: Thu Jan 10 09:19:16 2008 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <20080106155654.GA1616@matrix.chaos.earth.li> References: <1196338485.21580.41.camel@localhost> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> <79d7c4980712170808s5bb92b3ye42c2758b1472836@mail.gmail.com> <1198978845.5982.187.camel@localhost> <20080104170826.GA7601@matrix.chaos.earth.li> <20080104180123.711D3500A6@webmail217.herald.ox.ac.uk> <79d7c4980801051514m106a4f47r3128b5d13a60a05@mail.gmail.com> <20080106155654.GA1616@matrix.chaos.earth.li> Message-ID: <79d7c4980801100625w29126a81s72148ffbe8146847@mail.gmail.com> > > Yes, choosing to use non-empty whitespace (to indicate that a comment > > block is not finished) might well be a poor design decision. Another > > possibility is to use a line containing a single period as a > > continuation line e.g. > > I think we do this in Cabal descriptions (copying the design from Debian > package's descriptions), so this would be consistent with that. It gets > my vote! I have implemented this, and made a couple of other changes: - use a single period on a line to indicate that we want to continue the comment block (like cabal does) - don't indent code relative to comments, because Haddock doesn't like this - reverse Left and Right cases in the Either returned by unlit, so that they're consistent with Either conventions (Left == failure, Right = success) - reclassify is simpler because there's no need for lookahead for the blank-followed-by-code case I've also updated the test module and the calling code in ppUnlit in PreProcess (because the Left and Right cases are reversed). I wanted to send a separate patch for each source file, but my darcs-fu is poor, and darcs insisted on including a bunch of older patches which are already in my repo and the main cabal repo. So it's all in one fat patch, which seems to include a bunch of older patches it depends on. I don't know why this is; I expected that "darcs pull" would have updated my repo w.r.t. the main cabal repo, so that this wouldn't be necessary. I'll try to get Haddock 2 soon and see how it fares with .lhs input. Alistair -------------- next part -------------- A non-text attachment was scrubbed... Name: unlit_period_for_blank_comment.patch Type: application/octet-stream Size: 58970 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080110/e29a4f42/unlit_period_for_blank_comment-0001.obj From trac at galois.com Thu Jan 10 10:03:55 2008 From: trac at galois.com (Hackage) Date: Thu Jan 10 09:57:27 2008 Subject: [Hackage] #205: Remove BSD4 from Cabal.Distribution.License.License Message-ID: <042.b91e983ab5e53ab640affb017cc3b382@localhost> #205: Remove BSD4 from Cabal.Distribution.License.License ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- I doubt any Haskell software actually uses the BSD4 license, and it is likely to confuse users as it looks like a newer version of BSD3. Currently we have {{{ data License = ... | BSD3 | BSD4 }}} so I propose moving to one of {{{ data License = ... | BSD3 data License = ... | BSD data License = ... | BSD3 | OldBSD data License = ... | BSD | OldBSD data License = ... | NewBSD | OldBSD }}} (http://www.opensource.org/licenses/alphabetical lists it as "New BSD license") All but the first will require changing a number of packages. We could leave the old BSD3 name as deprecated for a while, though. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Jan 10 11:34:08 2008 From: trac at galois.com (Hackage) Date: Thu Jan 10 11:27:40 2008 Subject: [Hackage] #205: Remove BSD4 from Cabal.Distribution.License.License In-Reply-To: <042.b91e983ab5e53ab640affb017cc3b382@localhost> References: <042.b91e983ab5e53ab640affb017cc3b382@localhost> Message-ID: <051.55c99d0ed71e7edf6dba0f5fc7ad7f14@localhost> #205: Remove BSD4 from Cabal.Distribution.License.License ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): We may also want to add some other common licenses, eg MIT and perhaps also support licenses with version numbers, ie (L)GPL. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:38:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:31:34 2008 Subject: patch applied (cabal): Export the Flag constructors Message-ID: <20080110203800.GA32208@haskell.galois.com> Thu Jan 10 09:51:23 PST 2008 Duncan Coutts * Export the Flag constructors M ./Distribution/Simple/Setup.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:38:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:31:34 2008 Subject: patch applied (cabal): Un-deprecate configCompilerAux Message-ID: <20080110203802.GA32230@haskell.galois.com> Thu Jan 10 09:51:48 PST 2008 Duncan Coutts * Un-deprecate configCompilerAux but make it do something sensible with the ProgramConfiguration M ./Distribution/Simple/Configure.hs -3 +3 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:38:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:31:42 2008 Subject: patch applied (cabal): Make --user --global change the default prefix Message-ID: <20080110203804.GA32246@haskell.galois.com> Thu Jan 10 11:38:30 PST 2008 Duncan Coutts * Make --user --global change the default prefix Previously --user and --global didn't mean what it looks like they mean, instead of doing a per-user or a global installation they just meant to register in the per-user or global package databases (and to allow dependencies to be satisfied from the per-user or global db) With this patch --user / --global means to do a per-user or global install so in addition to the package db differences it also sets the default installation prefix. This prefix can of course still be overridden using the --prefix= flag. The global prefix is as before, the default per-user prefix is $HOME/.cabal on Unix and on Windows it's something like: C:/Documents And Settings/$user/Application Data/cabal (using getAppUserDataDirectory "cabal"). This is the per-user prefix that cabal-install currently uses. We can change it if people think it's not good. M ./Distribution/Simple/Configure.hs -2 +6 M ./Distribution/Simple/InstallDirs.hs -3 +7 M ./Distribution/Simple/Setup.hs -9 +11 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:38:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:31:43 2008 Subject: patch applied (cabal): Bump minor version number due to more minor api and behaviour changes Message-ID: <20080110203805.GA32263@haskell.galois.com> Thu Jan 10 12:11:17 PST 2008 Duncan Coutts * Bump minor version number due to more minor api and behaviour changes M ./Cabal.cabal -2 +2 M ./Makefile -2 +2 M ./releaseNotes -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:47:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:41:22 2008 Subject: patch applied (cabal-install): Significantly refactor configuration handling Message-ID: <20080110204749.GA32490@haskell.galois.com> Thu Jan 10 09:56:34 PST 2008 Duncan Coutts * Significantly refactor configuration handling ConfigFlags is not used in any of the modules that do the real work, instead we just pass in the necessary information. Renamed ConfigFlags to SavedConfig and moved it's definition into the Config module. Also change what information is kept in the Repo type so that it knows the local path too. A PkgInfo now also knows which Repo it is from. M ./Hackage/Config.hs -99 +114 M ./Hackage/Dependency.hs -17 +20 M ./Hackage/Fetch.hs -27 +32 M ./Hackage/Index.hs -9 +7 M ./Hackage/Info.hs -14 +19 M ./Hackage/Install.hs -40 +62 M ./Hackage/List.hs -4 +5 M ./Hackage/Setup.hs -33 +2 M ./Hackage/Types.hs -31 +51 M ./Hackage/Update.hs -6 +6 M ./Hackage/Upgrade.hs -6 +9 M ./Hackage/Upload.hs -60 +36 M ./Main.hs -69 +65 M ./cabal-install.cabal -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:47:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:41:23 2008 Subject: patch applied (cabal-install): Remove redundant code an re-enable accidentally disabled code Message-ID: <20080110204751.GA32512@haskell.galois.com> Thu Jan 10 10:01:37 PST 2008 Duncan Coutts * Remove redundant code an re-enable accidentally disabled code M ./Hackage/Install.hs -21 M ./Main.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 15:47:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 15:41:25 2008 Subject: patch applied (cabal-install): Depend on latest development version of Cabal lib Message-ID: <20080110204752.GA32529@haskell.galois.com> Thu Jan 10 12:37:11 PST 2008 Duncan Coutts * Depend on latest development version of Cabal lib M ./cabal-install.cabal -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 21:58:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 21:51:35 2008 Subject: patch applied (cabal): We default configUserInstall to False so we should not set configPackageDB Message-ID: <20080111025805.GA6341@haskell.galois.com> Thu Jan 10 18:37:33 PST 2008 Duncan Coutts * We default configUserInstall to False so we should not set configPackageDB because we use the value of configUserInstall to set the default value for configPackageDB, and any value the user sets will override that. M ./Distribution/Simple/Setup.hs -1 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 21:58:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 21:51:37 2008 Subject: patch applied (cabal): Warn if a build-type is not specified. We want all packages to use this now. Message-ID: <20080111025806.GA6366@haskell.galois.com> Thu Jan 10 18:39:17 PST 2008 Duncan Coutts * Warn if a build-type is not specified. We want all packages to use this now. M ./Distribution/PackageDescription.hs -5 +8 M ./Distribution/Simple/SetupWrapper.hs -1 +2 From duncan.coutts at worc.ox.ac.uk Thu Jan 10 21:58:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 10 21:52:00 2008 Subject: patch applied (cabal-install): Fix getting verbosity flags Message-ID: <20080111025829.GA6423@haskell.galois.com> Thu Jan 10 18:56:34 PST 2008 Duncan Coutts * Fix getting verbosity flags M ./Main.hs -4 +5 From trac at galois.com Sat Jan 12 13:04:07 2008 From: trac at galois.com (Hackage) Date: Sat Jan 12 12:57:35 2008 Subject: [Hackage] #53: if cabal get update needs to run, say so In-Reply-To: <043.98b4a309fa1764c924ed90e332c97073@localhost> References: <043.98b4a309fa1764c924ed90e332c97073@localhost> Message-ID: <052.a121cab6ec4fbe56c4dc5efedc28e10c@localhost> #53: if cabal get update needs to run, say so ---------------------------------+------------------------------------------ Reporter: ijones | Owner: ijones Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: cabal-install tool | Version: Severity: major | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * status: new => closed * resolution: => fixed Comment: We currently get: {{{ $ cabal install cabal-upload Warning: The package list does not exist. Run 'cabal update' to download it. cabal: Unresolved dependencies: cabal-upload -any }}} I misunderstood the request. The original request was just to say when the package list is missing. I interpreted it as knowing to update the package list based on a request to install something that was on the server but not in the current package list, which is rather harder. So closing this one as it's fixed. Though we could probably do better, it should be an error straight off rather than a warning followed by another error. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Jan 12 13:06:46 2008 From: trac at galois.com (Hackage) Date: Sat Jan 12 13:00:13 2008 Subject: [Hackage] #204: should setting user-prefix in ~/.cabal/config work? In-Reply-To: <042.d7718dd94772380071129e7a86c7c2aa@localhost> References: <042.d7718dd94772380071129e7a86c7c2aa@localhost> Message-ID: <051.e3294fb1e60d9fb4d89ec7d8c924df64@localhost> #204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): Ah, I see. The problem is that user-prefix: does work and just prefix: does not. That's a recent unintentional change. So the default config file that was generated previously that used just prefix: is now getting rejected. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Jan 12 13:09:22 2008 From: trac at galois.com (Hackage) Date: Sat Jan 12 13:02:48 2008 Subject: [Hackage] #131: cabal-install should rebuild dependants when a package is upgraded In-Reply-To: <045.7d2c0b99d931af8cc880702184abf639@localhost> References: <045.7d2c0b99d931af8cc880702184abf639@localhost> Message-ID: <054.66bb7903e60f1ecf234a24e67be41315@localhost> #131: cabal-install should rebuild dependants when a package is upgraded ---------------------------------+------------------------------------------ Reporter: bringert | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): We'll need to know what the dependencies of installed packages are. ghc- pkg can tell us this information, though it requires calling {{{ghc-pkg describe $pkgname}}} once for every package, which takes a while. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Jan 12 13:11:09 2008 From: trac at galois.com (Hackage) Date: Sat Jan 12 13:04:38 2008 Subject: [Hackage] #106: Two new commands: list and uninstall In-Reply-To: <042.554de9a5a5b537dfc51c3e135ea8111d@localhost> References: <042.554de9a5a5b537dfc51c3e135ea8111d@localhost> Message-ID: <051.6930ece14b5988b12a4b17b48701fb31@localhost> #106: Two new commands: list and uninstall ---------------------------------+------------------------------------------ Reporter: guest | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): Uninstall is tricky because currently we do not keep any record of what files we install or where we install them. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Jan 12 13:14:07 2008 From: trac at galois.com (Hackage) Date: Sat Jan 12 13:07:37 2008 Subject: [Hackage] #56: hackageDB should not accept a package if it is not installable In-Reply-To: <043.b78cc7bfc9ce2f369c822c35f8c95dec@localhost> References: <043.b78cc7bfc9ce2f369c822c35f8c95dec@localhost> Message-ID: <052.da6755b7f461f731a6421eb044ae79d3@localhost> #56: hackageDB should not accept a package if it is not installable --------------------------------+------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux --------------------------------+------------------------------------------- Comment (by duncan): One option here is to put newly uploaded packages into a separate category and not move them over into the main repo until there are some number of successful build reports. This would depend on hackage/cabal-install build reporting (ticket #184). That'd reduce the load on a central hackage server. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sun Jan 13 10:06:28 2008 From: trac at galois.com (Hackage) Date: Sun Jan 13 09:59:50 2008 Subject: [Hackage] #206: cabal-install should be able to generate haddock docs Message-ID: <042.d4da69b9c59eebb92853bd4c2508f379@localhost> #206: cabal-install should be able to generate haddock docs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ It would be really cool if it could keep an index up to date as well. (I like to have offline docs for all installed packages, but it's a headache to keep current.) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sun Jan 13 12:18:29 2008 From: trac at galois.com (Hackage) Date: Sun Jan 13 12:11:54 2008 Subject: [Hackage] #206: cabal-install should be able to generate haddock docs In-Reply-To: <042.d4da69b9c59eebb92853bd4c2508f379@localhost> References: <042.d4da69b9c59eebb92853bd4c2508f379@localhost> Message-ID: <051.dc6c9f2992e1113d8ae2df6dde92bf8a@localhost> #206: cabal-install should be able to generate haddock docs ---------------------------------+------------------------------------------ Reporter: guest | Owner: duncan Type: enhancement | Status: assigned Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * status: new => assigned * owner: => duncan Comment: I guess for a per-user install it could live in $HOME/.cabal/share/doc/index.html but that's no good for a global install since we cannot steal that name. So where would such an index go? Note, the same applies to a hoogle index too of course. The user interface should probably be a flag that we can set in the config file and override on the command line. That UI principle would also apply for a setting to always run tests. -- Ticket URL: Hackage Hackage: Cabal and related projects From thomas.dubuisson at gmail.com Sun Jan 13 15:45:21 2008 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sun Jan 13 15:35:28 2008 Subject: #176 Cabal verbosity message patch Message-ID: <1200257121.3949.9.camel@localhost> See attached patch fixing Ticket 176 - just a simple additional string on printout w/ magic number. Figured making Verbosity derive Enum / making the functions talk in Enum/succ terms was excessive. TomMD -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-verbosity-message.patch Type: text/x-patch Size: 28319 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080113/22abd7fc/cabal-verbosity-message-0001.bin From trac at galois.com Sun Jan 13 16:34:26 2008 From: trac at galois.com (Hackage) Date: Sun Jan 13 16:28:06 2008 Subject: [Hackage] #118: Cabal eats leading '.'s from .cabal file In-Reply-To: <051.2bcf25683cc97518f807d110738da3c8@localhost> References: <051.2bcf25683cc97518f807d110738da3c8@localhost> Message-ID: <060.d5d002759bdf59eb1373542c9043f280@localhost> #118: Cabal eats leading '.'s from .cabal file -----------------------------+---------------------------------------------- Reporter: igloo@earth.li | Owner: ijones Type: defect | Status: closed Priority: high | Milestone: Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------+---------------------------------------------- Comment (by guest): Fixed in filepath 1.2 -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Sun Jan 13 16:54:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 13 16:47:38 2008 Subject: patch applied (cabal): Inform users of max verbosity (fixes ticket 176) Message-ID: <20080113215416.GA11051@haskell.galois.com> Sun Jan 13 12:35:36 PST 2008 thomas.dubuisson@gmail.com * Inform users of max verbosity (fixes ticket 176) M ./Distribution/Verbosity.hs -1 +2 From duncan.coutts at worc.ox.ac.uk Sun Jan 13 18:19:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 13 18:13:05 2008 Subject: [Haskell-Cafe] Add "number of downloads" to hackageDB page? In-Reply-To: <837db430801131418v5e4d5ebehe096d7f57f6f6392@mail.gmail.com> References: <837db430801131418v5e4d5ebehe096d7f57f6f6392@mail.gmail.com> Message-ID: <1200266381.5639.60.camel@localhost> On Sun, 2008-01-13 at 23:18 +0100, Hugh Perkins wrote: > I seem to remember a thread about this a while back actually, but... > > Any chance of adding the number of downloads to the hackageDB page? > > For those packages that are included in ghc, hugs etc, perhaps add a > green tick with "included in ghc", "included in hugs", etc? > > That way it should be relatively easier to know for newbies which > packages are more or less mature/stable. That is indeed the highest priority for hackage at the moment, that is, getting enough information onto the hackage pages for people to make sensible decisions about what packages to choose. This is also closely related to measuring package QA, ie what packages work on what platforms. > Optional: perhaps include a tick-box/dropdown to only show packages > with more than a certain (configurable) number of downloads? There are loads of great ideas like these floating around and we've had a few discussions on what the most important ones are and how to go about implementing them. The block to progress is enough people with enough time to actually implement these suggestions. So let me take this opportunity to invite everyone who is interested in improving hackage to speak up. If you're interested you should: * Join the cabal-devel mailing list * Take a look at the feature requests in the hackage trac and make sure all your suggestions are properly documented * Post to cabal-devel to say that you're interested and we can discuss things in more detail and suggest where to start and what approach to take http://www.haskell.org/mailman/listinfo/cabal-devel http://hackage.haskell.org/trac/hackage At the moment I am particularly keen on the idea of getting cabal-install to send build reports back to the hackage server and then using that information to show what packages work on what platforms (where platform is the os, compiler version etc etc). So if someone is interested in helping with that then do get in touch. Duncan From trac at galois.com Sun Jan 13 19:32:58 2008 From: trac at galois.com (Hackage) Date: Sun Jan 13 19:26:20 2008 Subject: [Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? Message-ID: <042.8aaa909fe85372a1536842252cfc27f7@localhost> #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: misc | Version: HEAD Severity: normal | Keywords: tags source tagfile Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------+------------------------------------------------- == Introduction == I personally depend on tags because the source code only tells what is really going on. So it would be incredible useful to not only get information using ghci after loading libs but also beeing able to jump to all functions you might be using anywhere (The only solution providing this in all cases is uning tags, right? Because cpp defines can introduce new functions.. To be able to jump to the code source must be installed along with libs (the way you can optionally install haddock docs) == Use case: == setup configure --with-tags --install-source (or something like that) setup build && setup install do this for each dependency given in the .cabal file (VIM:) let tags+=system('ghc-pkg --query-tagfile-location haskell98-1.0.0.0') == Issues: == * Which tool to generate tag files? * ghc(i) when targeting ghc * the hasktags program shipping with ghc * some others? * Tagfile path type relative or absolute? * absolute: After moving/ installing the sources the tagfile must be patched * relative: Do editors take the right base directory to find source files? * When to invoke the tagfile generating program? * Perfect case would be after all preprocessing has been done (Thus the tagging program should understand line number changing comments!) * Template Haskell? ( This is really tricky I think ) * Hmm sorted tagfiles would be useful as well :) == alternatives ? == If you do not think this is useful (mandatory?) how do you lookup code? (Yes I know hoogle :) perhaps using Eclipse or Visual Studio? I'd like to start implementing this somehow the next weeks. So don't hesitate and start discussing Marc Weber -- Ticket URL: Hackage Hackage: Cabal and related projects From marco-oweber at gmx.de Sun Jan 13 19:50:15 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Jan 13 19:43:40 2008 Subject: [Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? In-Reply-To: <042.8aaa909fe85372a1536842252cfc27f7@localhost> References: <042.8aaa909fe85372a1536842252cfc27f7@localhost> Message-ID: <20080114005015.GA26840@gmx.de> Discussion moved to the haskell mailinglist. I'll try keeping the Trac page up to date by adding summaries Marc Weber From marco-oweber at gmx.de Sun Jan 13 19:52:39 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Jan 13 19:46:03 2008 Subject: [Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? In-Reply-To: <20080114005015.GA26840@gmx.de> References: <042.8aaa909fe85372a1536842252cfc27f7@localhost> <20080114005015.GA26840@gmx.de> Message-ID: <20080114005239.GB26840@gmx.de> On Mon, Jan 14, 2008 at 01:50:15AM +0100, Marc Weber wrote: > Discussion moved to the haskell mailinglist. Sorry for this inconvinience. I think haskell-cafe is the better choice right now Marc From trac at galois.com Sun Jan 13 20:03:36 2008 From: trac at galois.com (Hackage) Date: Sun Jan 13 19:56:58 2008 Subject: [Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? In-Reply-To: <042.8aaa909fe85372a1536842252cfc27f7@localhost> References: <042.8aaa909fe85372a1536842252cfc27f7@localhost> Message-ID: <051.b598dd7bfb5a4f6b128d99689e3c63b2@localhost> #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: misc | Version: HEAD Severity: normal | Resolution: Keywords: tags source tagfile | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------------+----------------------------------------- Comment (by guest): Most of the discussion will take place on haskell-cafe (mailinglist). -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 14 07:11:42 2008 From: trac at galois.com (Hackage) Date: Mon Jan 14 07:05:02 2008 Subject: [Hackage] #204: should setting user-prefix in ~/.cabal/config work? In-Reply-To: <042.d7718dd94772380071129e7a86c7c2aa@localhost> References: <042.d7718dd94772380071129e7a86c7c2aa@localhost> Message-ID: <051.fb17b49f4597ea2d61665def9b7bd6b6@localhost> #204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by guest): The version I was running at the time of reporting rejected both forms. I'll try upgrading to the latest Darcs soon. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Mon Jan 14 09:16:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 14 09:09:37 2008 Subject: patch applied (cabal-install): Allow finding the proxy to fail without failing overall Message-ID: <20080114141615.GA29234@haskell.galois.com> Sun Jan 13 12:16:27 PST 2008 Duncan Coutts * Allow finding the proxy to fail without failing overall On windows, if looking up the info in the registry failed then we failed overall. Now we just don't use the proxy. Also refactored a bit. M ./Hackage/HttpUtils.hs -38 +37 From duncan.coutts at worc.ox.ac.uk Mon Jan 14 09:16:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 14 09:09:38 2008 Subject: patch applied (cabal-install): Set the user install flag when restoring saved config Message-ID: <20080114141617.GA29256@haskell.galois.com> Mon Jan 14 06:13:13 PST 2008 Duncan Coutts * Set the user install flag when restoring saved config M ./Hackage/Config.hs +1 From duncan.coutts at worc.ox.ac.uk Mon Jan 14 09:44:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 14 09:37:27 2008 Subject: patch applied (cabal-install): After refactoring the http proxy code we don't need the unix package Message-ID: <20080114144400.GA30766@haskell.galois.com> Mon Jan 14 06:23:01 PST 2008 Duncan Coutts * After refactoring the http proxy code we don't need the unix package Which was just being used for an exception-free version of getEnv but we have to cope with exceptions anyway for the Win32 registry. M ./cabal-install.cabal -2 From duncan.coutts at worc.ox.ac.uk Mon Jan 14 09:44:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 14 09:37:28 2008 Subject: patch applied (cabal-install): Fix compilation on windows Message-ID: <20080114144401.GA30788@haskell.galois.com> Mon Jan 14 06:34:56 PST 2008 Duncan Coutts * Fix compilation on windows Silly #ifdefs making things harder to test. M ./Hackage/HttpUtils.hs +1 From trac at galois.com Mon Jan 14 09:50:20 2008 From: trac at galois.com (Hackage) Date: Mon Jan 14 09:43:40 2008 Subject: [Hackage] #205: Remove BSD4 from Cabal.Distribution.License.License In-Reply-To: <042.b91e983ab5e53ab640affb017cc3b382@localhost> References: <042.b91e983ab5e53ab640affb017cc3b382@localhost> Message-ID: <051.6d8aae7c3df2e7816e6277087aa4a166@localhost> #205: Remove BSD4 from Cabal.Distribution.License.License ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: Linux ----------------------------+----------------------------------------------- Comment (by duncan): For example of probably confusion see: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hbeat-0.1 The LICENSE file included in that package seems to be BSD3. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 14 12:36:48 2008 From: trac at galois.com (Hackage) Date: Mon Jan 14 12:30:10 2008 Subject: [Hackage] #167: cabal-install should treat package names case insenitively in the UI wherever possible In-Reply-To: <043.eaf95369a72a3fed3e19098f88752288@localhost> References: <043.eaf95369a72a3fed3e19098f88752288@localhost> Message-ID: <052.b014dd916ac6ab7724564db979516305@localhost> #167: cabal-install should treat package names case insenitively in the UI wherever possible ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by guest): (from BMeph) One of the relevant issues I see, is that doing a {{{cabal list}}} will not only give any package of that name, upper or lower case, but any package with that character sequence in the package name - e.g., {{{cabal list tv}}} lists both TV and the GuiTV packages. This seems to me to be a reasonable behavio(u)r from the standpoint of searching for a package, of which its precise name one is unsure. Knowing that I can do a {{{cabal list HXT}}} after an unsuccessful "install" to find the proper package name, is a beneficial service to me. Also, knowing that {{{cabal list}}} will give me that name, to be used in a {{{cabal install}}} reassures me that should two packages come along with near-identical names (HTTP, anyone?), that I can identify which one I want and get it with the {{{cabal install}}}. The greater particularity (?) of "cabal install"'s parameter should be documented, but I would rather it not be changed. However, when not finding a package , the error message it gives seems misleading/unhelpful to a worse degree than some of GHCi's ones. The error message should be changed, or somehow re-worked for a more informative response. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 14 14:05:30 2008 From: trac at galois.com (Hackage) Date: Mon Jan 14 13:58:51 2008 Subject: [Hackage] #58: darcs integration idea: track location of darcs repo, create new repo In-Reply-To: <043.6583bf82ef1497f4ce27dc570194f6ee@localhost> References: <043.6583bf82ef1497f4ce27dc570194f6ee@localhost> Message-ID: <052.1f3e1c7f3d292b27a8aa0f925f24c2a4@localhost> #58: darcs integration idea: track location of darcs repo, create new repo --------------------------------+------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux --------------------------------+------------------------------------------- Comment (by duncan): We need a spec for how we should specify the source control in a .cabal file. Here are some questions to consider. They are not necessarily all requirements. * what are the use cases? * what kinds of integration would we like with other tools, eg hackage or cabal-install. * how to specify the kind of source control being uses, eg darcs, svn, git etc. Though it's for hackage to support darcs better than others we should allow all necessary info for other systems to be specified in the .cabal file for other tools to take advantage of. * how to specify the url, does that work for other SCMs? * what about tags or branches? * what if the package is not at the root of the repo but within some sub- dir? We may want to find it. * should we be specifying the repo/tag for the exact release? should we specify the branch this release was made from or the main development branch, or both? -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Jan 14 15:47:08 2008 From: trac at galois.com (Hackage) Date: Mon Jan 14 15:40:29 2008 Subject: [Hackage] #88: Stripping In-Reply-To: <055.8a351a03965fd17ad383f63cc40bfd0d@localhost> References: <055.8a351a03965fd17ad383f63cc40bfd0d@localhost> Message-ID: <064.c7907ca3ff7017a781052273a4e5fa0a@localhost> #88: Stripping ---------------------------------+------------------------------------------ Reporter: bjorn@bringert.net | Owner: ijones Type: enhancement | Status: new Priority: high | Milestone: Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by duncan): It seems that we cannot portably strip .a files. On solaris doing so removes the symbol index which is required for linking: {{{ If strip is executed on a common archive file (see ar(3HEAD)) in addition to processing the members, strip will remove the archive symbol table. The archive symbol table must be restored by executing the ar(1) command with the -s option before the archive can be linked by the ld(1) com- mand. strip will produce appropriate warning messages when this situation arises. }}} With GNU strip it seems to be ok and only remove stuff from within the individual .o files within the .a archive. The `install` program that automake uses only seems to strip binary executables, not library archives so we should probably do the same. If you think otherwise then complain now. So I suggest we only strip on installation, that we do it by default and add an install flag to turn it off (eg some distro packaging systems prefer to manage striping themselves). -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 15 09:51:29 2008 From: trac at galois.com (Hackage) Date: Tue Jan 15 09:44:46 2008 Subject: [Hackage] #191: Hackage should check for common QA problems in ghc-options In-Reply-To: <043.1d79ebe82ae9b2113d9c0b7033be1a00@localhost> References: <043.1d79ebe82ae9b2113d9c0b7033be1a00@localhost> Message-ID: <052.0319a69ab6df5ec589e561352d79318a@localhost> #191: Hackage should check for common QA problems in ghc-options --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.1 | Platform: Linux --------------------------------+------------------------------------------- Old description: > Simple test that many packages have is dodgy ghc-options, or options that > would be suitable for development but not release. It should be easy to > check for these. > > Suggestions: > > {{{ghc-options: -Wall -Werror}}} is a very bad combination. It means the > package will break silently as soon as the next version of ghc adds a new > warning, which generally does happen every major release. > > {{{ghc-options: -fasm}}} is unnecessary and breaks on all arches except > for x86, x86-64 and ppc. > > {{{ghc-options: -O}}} is unnecessary since Cabal does that itself and it > prevents people from configuring with the {{{--disable-optimization}}} > flag. > > {{{ghc-options: -O2}}} may be necessary in some circumstances but people > should not use it routinely for the same reasons as -O and since -O2 take > a lot longer to compile most of the time and usually with little benefit. > > {{{ghc-options: -ffi}}} or {{{-fffi}}} use extensions: > ForeignFunctionInterface. > > Once #190 is implemented then {{{ghc-options: -fvia-C}}} will be > unnecessary too. New description: Simple test that many packages have is dodgy ghc-options, or options that would be suitable for development but not release. It should be easy to check for these. Suggestions: {{{ghc-options: -Wall -Werror}}} is a very bad combination. It means the package will break silently as soon as the next version of ghc adds a new warning, which generally does happen every major release. {{{ghc-options: -fasm}}} is unnecessary and breaks on all arches except for x86, x86-64 and ppc. {{{ghc-options: -O}}} is unnecessary since Cabal does that itself and it prevents people from configuring with the {{{--disable-optimization}}} flag. {{{ghc-options: -O2}}} may be necessary in some circumstances but people should not use it routinely for the same reasons as -O and since -O2 take a lot longer to compile most of the time and usually with little benefit. {{{ghc-options: -ffi}}} or {{{-fffi}}} use extensions: ForeignFunctionInterface. Once #190 is implemented then {{{ghc-options: -fvia-C}}} will be unnecessary too. == == Comment (by ross@soi.city.ac.uk): I think it's a library issue, specifically `parsePackageDescription` and `sanityCheckPackage` in `Distribution.PackageDescription`. If either of these functions fails, the HackageDB upload will fail and show the error. If they produce warnings, the upload succeeds but shows the warnings (as does check). Currently HackageDB has additional fatal errors for * version numbers like 00.02 that change when parsed and printed. and additional warnings for * missing Category, Description, Maintainer or Synopsis field. * over-long Synopsis field. * exposed modules that use unallocated top-level names in the module hierarchy. But there are quite a few packages in the archive that triggered these warnings. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Tue Jan 15 10:27:55 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 15 10:21:16 2008 Subject: patch applied (cabal-install): Use commandDefaultFlags = mempty rather than commandAddActionWithEmptyFlags Message-ID: <20080115152755.GA437@haskell.galois.com> Tue Jan 15 07:07:25 PST 2008 Duncan Coutts * Use commandDefaultFlags = mempty rather than commandAddActionWithEmptyFlags Simpler and simplifies the Command api in the Cabal lib M ./Hackage/Setup.hs -4 +6 M ./Main.hs -2 +2 From duncan.coutts at worc.ox.ac.uk Tue Jan 15 10:27:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 15 10:21:17 2008 Subject: patch applied (cabal-install): Remove unused var Message-ID: <20080115152757.GA460@haskell.galois.com> Tue Jan 15 07:08:38 PST 2008 Duncan Coutts * Remove unused var M ./Hackage/Install.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Tue Jan 15 10:27:58 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 15 10:21:18 2008 Subject: patch applied (cabal-install): Refactor proxy handling yet again Message-ID: <20080115152758.GA477@haskell.galois.com> Tue Jan 15 07:09:33 PST 2008 Duncan Coutts * Refactor proxy handling yet again This time to better handle parsing and warning about invalid proxy uris M ./Hackage/Fetch.hs -13 +15 M ./Hackage/HttpUtils.hs -23 +37 M ./Hackage/Update.hs -1 +1 M ./Hackage/Upload.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Tue Jan 15 10:28:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 15 10:21:23 2008 Subject: patch applied (cabal-install): Use proxy port number rather than ignoring it Message-ID: <20080115152800.GA493@haskell.galois.com> Tue Jan 15 07:10:33 PST 2008 Duncan Coutts * Use proxy port number rather than ignoring it M ./Hackage/HttpUtils.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Tue Jan 15 11:12:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 15 11:05:28 2008 Subject: patch applied (cabal-install): Don't verbosely display the http conversation chatter by default Message-ID: <20080115161212.GA1699@haskell.galois.com> Tue Jan 15 08:02:33 PST 2008 Duncan Coutts * Don't verbosely display the http conversation chatter by default Though do display it at deafening verbosity level. M ./Hackage/HttpUtils.hs -3 +10 M ./Hackage/Upload.hs -9 +7 From duncan.coutts at worc.ox.ac.uk Tue Jan 15 11:12:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 15 11:05:30 2008 Subject: patch applied (cabal-install): Set the useragent string to be "cabal-install/$version" Message-ID: <20080115161213.GA1721@haskell.galois.com> Tue Jan 15 08:03:47 PST 2008 Duncan Coutts * Set the useragent string to be "cabal-install/$version" eg, currently it is "cabal-install/0.4.2" M ./Hackage/HttpUtils.hs -1 +4 From trac at galois.com Tue Jan 15 12:13:07 2008 From: trac at galois.com (Hackage) Date: Tue Jan 15 12:06:24 2008 Subject: [Hackage] #176: Bad verbosity message lacks crucial detail In-Reply-To: <042.aaed79332724b9706d38d0b841a4ed8f@localhost> References: <042.aaed79332724b9706d38d0b841a4ed8f@localhost> Message-ID: <051.df779fc5cf1a7cab0ed713ba002f267a@localhost> #176: Bad verbosity message lacks crucial detail ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Resolution: fixed Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.6 | Platform: Windows ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Sun Jan 13 20:35:36 GMT 2008 thomas.dubuisson@gmail.com * Inform users of max verbosity (fixes ticket 176) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Jan 15 20:11:25 2008 From: trac at galois.com (Hackage) Date: Tue Jan 15 20:04:44 2008 Subject: [Hackage] #191: Hackage should check for common QA problems in ghc-options In-Reply-To: <043.1d79ebe82ae9b2113d9c0b7033be1a00@localhost> References: <043.1d79ebe82ae9b2113d9c0b7033be1a00@localhost> Message-ID: <052.d372a55641b3f29ee9c0c40b1a61a18d@localhost> #191: Hackage should check for common QA problems in ghc-options --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.1 | Platform: Linux --------------------------------+------------------------------------------- Comment (by duncan): Yes it is a lib issue. The code to do these checks should be in the library and used in hackagedb and cabal-install. However I think the interpretation of some of the checks should be different in the hackage context than in a private build context. So something that might be a warning in cabal locally, like a missing build- type should be a fatal error for hackagedb. Perhaps we should improve sanityCheckPackage or add an extra qaCheckPackage that gives enough info for hackage and cabal to react differently. That one about version number parsing should be integrated into the cabal lib. It's ticket 194#. -- Ticket URL: Hackage Hackage: Cabal and related projects From igloo at earth.li Wed Jan 16 15:39:37 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 16 15:32:50 2008 Subject: patch applied (cabal): Comment out an unused binding Message-ID: <20080116203937.GA4322@haskell.galois.com> Wed Jan 16 09:22:04 PST 2008 Ian Lynagh * Comment out an unused binding M ./Distribution/Simple/InstallDirs.hs -2 +3 From trac at galois.com Thu Jan 17 14:36:54 2008 From: trac at galois.com (Hackage) Date: Thu Jan 17 14:36:57 2008 Subject: [Hackage] #208: Support program prefixes and suffixes Message-ID: <043.79253c53dfc1e97be4dece9cacab0b65@localhost> #208: Support program prefixes and suffixes ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- GNU autoconf has these configure flags: {{{ `--program-prefix=prefix' Specifies a prefix which should be added to the name of a program when installing it. For example, using `--program-prefix=g' when configuring a program normally named `tar' will cause the installed program to be named `gtar' instead. `--program-suffix=suffix' Specifies a suffix which should be appended to the name of a program when installing it. }}} This would be handy for appending program versions to allow installing multiple versions of the same program. For example: {{{ cabal configure --program-prefix='$version' }}} So I can end up with `haddock-0.9` and `haddock-2.0.0.0` in my `~/bin` dir. Distros that use 'alternatives' systems might like to use this feature. This should be fairly easy to implement, as the prefix/suffix can be parsed and represented as a `PathTemplate`, which handles `$version` vars etc. The prefix/suffix would need to be propagated into the `LocalBuildInfo` (and probably var-substituted into an ordinary `String` at that point) and then used when generating the binary name. This would be particularly handy in combination with a cabal-install feature to symlink newly-installed versions of programs into an alternative directory. For example we might install versioned binaries into ~/.cabal/bin by default and symlink the latest into ~/bin. Or we might symlink versioned links to each version, and an unversioned link to the latest one that got installed. Anyway, there's room for exploration there as to the best default. -- Ticket URL: