June 2011 - cabal-devel

[Hackage] #676: bash-completion gets confused by alias for rm
by Hackage 05 Jan '12

05 Jan '12

#676: bash-completion gets confused by alias for rm ---------------------------------+------------------------------------------ Reporter: benmachine | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: minor | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ---------------------------------+------------------------------------------ I have an alias for rm defined so that it is by default verbose (alias rm='rm -v' in my bashrc). When I do cabal install has<tab> I get something like: [ben@euler ~]$ cabal install hasbash: bad substitution: no closing "`" in `/tmp/cabal_completion.tD2o8O' It turns out that rm is helpfully going: removed `/tmp/cabal_completion.hb1zbc' and then cabal is trying to use this as part of the completion command - choking on the ` because bash thinks it is part of a substitution. So rm should probably explicitly discard its stdout. While I was there I noticed that "cat" is used redundantly. There's nothing really wrong with this so that part of the patch can be cut I suppose, but I thought it was neater to use bash's input redirection explicitly. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/676> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal"
by Hackage 05 Jan '12

05 Jan '12

#677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: Linux | ---------------------------------+------------------------------------------ I recently upgraded cabal-install and started getting this error: $ cabal install HDBC Resolving dependencies... cabal: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" I also get the same error when I try to install one of my own packages that depends on HDBC. I tried changing my HDBC dependency to == 2.2.2 as well as >= 2.2.6, but still get the same error for version 2.2.5. I have cabal-install version 0.6.2 and Cabal version 1.6.0.3. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/677> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #674: Findable extra documentation
by Hackage 05 Jan '12

05 Jan '12

#674: Findable extra documentation ----------------------------+----------------------------------------------- Reporter: jbapple | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a cabal package that should include extra documentation in the distribution. This documentation should not be written in Haddock. 1. There should be a field for this analogous to data-files or extra- source-files. The former is too much: the files do not need to be accessed by any Haskell runtime. The latter is not enough: it does not store the extracted files on the system on which the package is installed. 2. There should be a way for humans to find these files without loading up a GHC runtime or using Unix's "find". I suggest "cabal list" also shows, for installed packages with extra data or documentation files installed, where these files can be found. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/674> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #760: exclude all but latest documentation from search results
by Hackage 02 Dec '11

02 Dec '11

#760: exclude all but latest documentation from search results --------------------------------+------------------------------------------- Reporter: warren | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- When searching for haskell documentation on google, quite frequently the top search results are versions of the library documentation from the archives. For instance, when searching for Data.Vector, the top hit is version 0.5, whereas the latest is 0.7. Also, if the user selects the 0.7 version, it isn't obvious from the documentation that this version corresponds to the latest since it also appears in the archive (the url is http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data- Vector.html). So I'm wondering if it might not make sense to exclude all but the latest haddock documentation from search results by augmenting the robots.txt file. It might also make sense to provide alternate urls to the latest versions of documents. E.g. Starting from the http://hackage.haskell.org/package/vector page (which is the latest version), and clicking on Data.Vector, one is taken to http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data- Vector.html... but it might be better if this were http://hackage.haskell.org/packages/current/vector/doc/html/Data- Vector.html. This would allow for all files under /archive to be excluded. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/760> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #767: Highlighted source code on hackage.haskell.org mangles Unicode
by Hackage 09 Nov '11

09 Nov '11

#767: Highlighted source code on hackage.haskell.org mangles Unicode ----------------------------------+----------------------------------------- Reporter: andersk | Owner: Type: defect | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- On hackage.haskell.org, when you browse the source of a module that contains Unicode (e.g. [http://hackage.haskell.org/packages/archive/base- unicode-symbols/latest/doc/html/src/Data-Eq-Unicode.html Data.Eq.Unicode]), it is sent with a `Content-Type: text/html` header with no charset. There is a charset in the XML declaration `<?xml version="1.0" encoding="UTF-8"?>`, but that is ignored by Firefox because of the non-XML `Content-Type`. Therefore, the wrong encoding is detected and the Unicode symbols get mangled. Possible fixes include sending `Content-Type: text/html; charset=UTF-8`, or sending `Content-Type: application/xhtml+xml` so that the XML declaration is respected , or both (`Content-Type: application/xhtml+xml; charset=utf-8`), or adding equivalent `<meta http-equiv="Content-Type">` tags. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/767> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #821: Add support for Apache license
by Hackage 25 Oct '11

25 Oct '11

#821: Add support for Apache license ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have several projects licensed under the Apache license due to upstream dependencies, but Cabal doesn't know about it. This would be good to add for e.g. license compatibility checkers (I believe Galois has such a tool). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/821> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #857: Decide what to do about licenses
by Hackage 25 Oct '11

25 Oct '11

#857: Decide what to do about licenses ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently you can specify some partial info about a license in the .cabal file. It's not exhaustive and does not cover all licenses. It seems originally intended so that common licenses will be given the same name (so no confusion over "bsd" =? "BSD"). There are a number of outstanding requests for new licenses to be listed (#854 BSD2 & ISC, #821 Apache). This is based on users expecting that most licenses they might want should be listed. The current alternative of course is that they just list it as `OtherLicense`. So this all comes down to what do we want the license field for, what is it's purpose, does it have any semantics? Currently we can't really say that it has any reliable semantics (even if the info were accurate), it's really just a way to stop people spelling "GPL" wrong. It also serves a purpose to indicate what are recommended licenses, to work against license proliferation. So, should we move to a more accurate license system where you can express more precisely the licensing terms? Apart from listing more licenses this would mean we have to tackle: * multiple licenses (conjunctive): the distributor has to comply with multiple licenses, e.g. because different parts of the code have different licenses. * dual licensing (disjunctive): the distributor gets to pick which license to use * GPL open ended versions: The GPL recommends that authors license under terms like "Version X or any later version". This is a special kind of dual licensing, it's the infinite disjunction of all later versions of the license and of course those later versions are mostly unknown so it'd have to be handled specially. Then there's the issue in the BSD licenses that there's hardly any standard BSD3 license, people make up all kinds of variations. The 2-clause license is not actually (properly) listed by the FSF or the OSI (bizarrely the OSI has it listed but with the wrong text). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/857> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #847: Cabal ignores multiple test options given with "--test-option{, s}"
by Hackage 17 Jul '11

17 Jul '11

#847: Cabal ignores multiple test options given with "--test-option{,s}" ----------------------------+----------------------------------------------- Reporter: ttuegel | Owner: ttuegel Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When using {{{--test-option}}} or {{{--test-options}}} on the command line, {{{cabal test}}} only passes the last option given to the test executable. Thanks to waern for reporting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/847> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal): "build-tools-extend-namespace" and 2 others
by Duncan Coutts 08 Jul '11

08 Jul '11

Mon Oct 5 22:58:31 PDT 2009 intractable(a)gmail.com * build-tools-extend-namespace M ./Distribution/Simple/Configure.hs -9 +27 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Wed May 4 18:41:44 PDT 2011 intractable(a)gmail.com * intrapackage-deps-and-per-component-preprocessing This patch adds intrapackage dependency resolution so that components (libraries, exes, test suites) are build in the correct order. This mean it's now possible to have, e.g., executables that depend on other executables defined in the same package description: the build-tools namespace has been extended accordingly. Related to this change is the refactoring of the do-it-all preprocessSources function, formerly invoked by initialBuildSteps, into a a function preprocessComponent that is invoked when a component is being built. This lets us use executables defined in a package to be used as a custom preprocessor when building other components. Finally, a number of functions now operate on values of the sum type PackageDescription.Component rather than specifically operating on Library or Executable and so forth. M ./Distribution/PackageDescription.hs -11 +40 M ./Distribution/Simple/Build.hs -89 +88 M ./Distribution/Simple/Configure.hs -13 +45 M ./Distribution/Simple/Haddock.hs -94 +98 M ./Distribution/Simple/LocalBuildInfo.hs -1 +32 M ./Distribution/Simple/PreProcess.hs -66 +64 M ./Distribution/Simple/Program/Types.hs -1 +17 M ./Distribution/Simple/SrcDist.hs -5 +10 M ./Distribution/Simple/Utils.hs +1 M ./tests/suite.hs -2 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Sun May 8 12:09:44 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Do not include disabled tests into the component build graph M ./Distribution/PackageDescription.hs +1 M ./Distribution/Simple/Configure.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

3 3

Re: Any remaining test patches?
by Duncan Coutts 29 Jun '11

29 Jun '11

On 18 May 2011 15:01, Thomas Tuegel <ttuegel(a)gmail.com> wrote: > On Wed, May 18, 2011 at 4:34 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: >> Sorry for having to leave so abruptly yesterday. Could someone please >> summarize the discussion? Are we going with GetOpt? > > We didn't reach a decision; primarily, I think, because I had to leave > before Duncan really had a chance to review the patch. (There really > wasn't any discussion after you had to leave.) But, my understanding > of the discussion before you left is that Duncan would prefer a custom > solution, rather than GetOpt. (Duncan, please correct me if that isn't > the case). Ok, I've looked at the Distribution.TestSuite API and had a go at designing something along the lines of what I was thinking. I'll try and explain this design and compare three designs: Thomas's current patch, my prototype and the the test-framework test interface. So the design in the current patch is nice and short: class Testable t where name :: t -> String options :: [OptDescr (t -> t)] defaultOptions :: t -> IO [String] run :: t -> IO Result data Result = Pass | Fail ErrorMessage | Error ErrorMessage deriving (Read, Show, Eq) data Test = forall t. Testable t => Test t The test suite will then expose a value of type [Test]. So the interesting aspects are: * the API uses a type class and an existential wrapper to hide the specific type of each test. * the default options are obtained using IO * it uses GetOpt to accumulate key/value style string options into the test instance, which can then be run (Presumably at least the default options must be added before the test can be run.) Here's the equivalent bit of my design (the TestResult is the same): data TestInstance = TestInstance { run :: IO TestResult name :: String, concurrentSafe :: Bool, expectedFail :: Bool, options :: [OptionDescr] setOption :: String -> String -> Either String TestInstance } Minor difference: extra flags for indicating whether the test is safe for concurrent execution (e.g. if it's pure or has only local side effects) and whether the test case is in fact expected to fail (so numbers of expected vs unexpected failures can be reported). The first major difference is that we do the "OO" bit differently. Instead of using a type class and an existential wrapper, we use a record. These two styles are pretty similar but the record avoids the use of existential types. Since the test agents using this interface never know or need to know the actual type of the test (they will always use Test above and manipulate it via the type class interface) then there is no advantage to using a type class. The option setting is rather similar in both designs. In both you end up using a function of type String -> String -> Test -> Test to accumulate a key/value option pair into the test instance. This lets the user add any number of options before running the test. The slight difference in style is down to the different OO encoding (class based vs record based). The major difference with the options is of course how they are validated and described (which I have not yet detailed). GetOpt does not actually provide any validation of options, that is, for an option --foo=bar, there is no parsing/validation of the string "bar". GetOpt just parses the overall command line string ["--foo=bar", ...]. This setOption function gives the possibility of validating the value string and producing an error message. Note that I don't have an IO action to get any default options. In this design it must always be possible to run the test with no options supplied. Internally, if a test does need some options specified then it just has to fill them in with its internal defaults. So, all the options are just (String, String) key value pairs and we can validate them. Obviously we also need some discoverability of what options are available and some information to construct a sensible user interface (either command line, config file, web UI or IDE GUI). data OptionDescr = OptionDescr { optionName :: String, optionDescription :: String, optionType :: OptionType, optionDefault :: Maybe String } The name and description are much like in GetOpt. The optional default is purely informative, for user interfaces that are able to display defaults (eg a web form). The OptionType is to give a user interface some extra info on what is expected so that they can present an appropriate interface and do some up front validation. Of course the real validation is done via setOption, or for things that can only really be validated by doing IO (like reading files) then they have to be deferred to when the test is actually run. So this list is just informative: data OptionType = OptionFile { optionFileMustExist :: Bool, optionFileIsDir :: Bool, optionFileExtensions :: [String] } | OptionString { optionStringMultiline :: Bool } | OptionNumber { optionNumberIsInt :: Bool, optionNumberBounds :: (Maybe String, Maybe String) } | OptionBool | OptionEnum [String] | OptionSet [String] | OptionRngSeed You can imagine how each of these could be used as hints to make a more helpful web form or GUI interface. They could also let a command line ui do some up front validation too. The most general case is OptionString for when no more specific alternative is appropriate. Now, I also looked again at what test-framework does and it has some interesting things and some things that are unnecessary for our purposes. There are two things there that I think we should consider. The first is the grouping of tests into a related bundles, or in general a hierarchy: data Test = forall i r t. Testlike i r t => Test TestName t | TestGroup TestName [Test] | PlusTestOptions TestOptions Test So we either have a individual test or a group of tests (which themselves can contain groups etc). I'm sure this is nice for displaying in a UI what tests can be run and displaying results of a run. Imagine an interactive UI that lets the user select a group of tests to be run, or an html report showing results by group. We could do something like this: data Tests = Test TestInstance | TestGroup TestName [Tests] The PlusTestOptions is interesting. As I understand this, it is really from the point of view of the author of the test suite: they are providing additional default test options for this test or group of tests. I don't think this is necessary from the point of view of the test agent, they do not need to know this. The above could be lifted into a structure without PlusTestOptions simply by pre-applying the test options to that subtree. On the other hand, perhaps it is useful for an agent presenting a user interface to be able to know that a whole group of test all take the same set of options. So perhaps we should have: data Tests = Test TestInstance | TestGroup TestName [Tests] | ExtraTestOptions [OptionDescr] Tests So this means that all of the tests below this ExtraTestOptions take the given set of options. Then individual tests would usually have an empty options set, or perhaps just add one or two for that special case. This grouping of test options should enable better user interfaces. Another interesting part of test-framework is what you get when you run a test: runTest :: t -> IO (i :~> r, IO ()) So I the main point here is that it gives us progress / logging while the test is being run. The i :~> r thing is basically just a lazy list with values of type i spat out along the way and finally ending in a result of type r. The way it's done in test-framework is to have a pure i :~> r lazy list and a separate IO () action that does the real work. The IO action performs the test and pokes the results into a Concurrent.Chan. The i :~> r lazy list is extracted from the Chan using getChanContents. Honestly, I don't know why Max did it this way, seems to me a much more direct approach is: data TestProgress = Finished TestResult | Progress String (IO TestProgress) So it's not a lazy list, it's a list with explicit IO to get the tail. The test-framework approach could be lifted into this fairly easily I think. Note that this kind of progress reporting is actually quite important. You cannot have each test logging information to stdout if you're going to run any tests concurrently. But it is quite nice to see progress (e.g. from QuickCheck) for the tests that are currently running, which is exactly what test-framework does using a 'top' like console interface (you can imagine GUI ones too). Comments, thoughts on any/all of this appreciated. Duncan

5 13