- cabal-devel - Haskell.org

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 20 Apr '12

20 Apr '12

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by DavidMazieres): * status: closed => reopened * resolution: fixed => Comment: At the very least there is still a documentation bug here, as it is impossible to figure out how to enable this feature automatically. I've tried adding each of the following to $HOME/.cabal/config, and none of them work: haddock-hyperlink-source: True hyperlink-source: True flags: --haddock-hyperlink-source flags: haddock-hyperlink-source flags: --hyperlink-source flags: hyperlink-source The correct incantation, whatever it is, should be added as a comment to the default .cabal/config file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:18> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #534: cabal haddock should --hyperlink-source by default
by Hackage 20 Apr '12

20 Apr '12

#534: cabal haddock should --hyperlink-source by default ----------------------------------+----------------------------------------- Reporter: adamvo | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Comment(by bfr): I have created a new feature request for adding a configuration item for this, see #941. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/534#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #921: cabal build should imply cabal configure
by Hackage 20 Apr '12

20 Apr '12

#921: cabal build should imply cabal configure ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal build` should run `cabal configure` if needed, even if the user never ran `cabal configure` manually before. Right now `cabal build` without `cabal configure` gives: {{{ cabal: Run the 'configure' command first. }}} We should simply run `cabal configure` automatically, with no flags set. If the user wants different flags he/she can run `cabal configure` manually. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/921> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #661: optionally select the oldest available dependencies rather than the newest
by Hackage 20 Apr '12

20 Apr '12

#661: optionally select the oldest available dependencies rather than the newest ----------------------------+----------------------------------------------- Reporter: benmachine | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When developing a package, you want to specify as wide a range of build- depends as possible, but it's often quite tedious to keep checking if your latest development effort hasn't made your package incompatible with some ancient version of a library you use. In view of this I think it would be helpful to have an option that asks cabal configure to pick the oldest possible version of each dependency, so you could quickly and easily ensure that at least the two endpoints are covered. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/661> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

cabal patch to improve "cabal update" behavior.
by Eyal Lotem 19 Apr '12

19 Apr '12

I built a preliminary prototype of "cabal update" enhancements: A) Using a Lazy I/O bytestring with the HTTP download, so that it can do a streaming-decompress on-the-fly (This gives a 30% speedup on my machine) B) Using the bytestring-progress library to show a useful progress report on the whole process. Unfortunately, due to the PVP, the version constraints are (as usual) over-restrictive, so they need to be relaxed. Until the fix is put on hackage, you have to install bytestring-progress from https://github.com/Peaker/bytestring-progress C) It's quick&dirty (Proof of concept), because: C.1) No version constraints on bytestring-progress C.2) Using hSetBuffering on stdout and ANSI terminal codes, which may be problematic in different kinds of terminals C.3) The only way to disable it is setting verbosity=quiet. It probably deserves its own option I hope it's a useful demonstration of the utility of this, though. It makes "cabal update" something I'd dread a little less to run :) Also, I was wondering why there's no monad for the passing of Verbosity around to so many functions. Then I could easily add more options that go around to control things like whether to show progress bars... Eyal

2 1

Re: [Hackage] #380: Ability to blacklist packages that are on hackage
by Hackage 18 Apr '12

18 Apr '12

#380: Ability to blacklist packages that are on hackage ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Changes (by kosmikus): * milestone: cabal-install-0.16 => cabal-install-0.14.2 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/380#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #408: cabal install / cabal update should give warning when preferred versions will result in something other than the latest version on hackage
by Hackage 18 Apr '12

18 Apr '12

#408: cabal install / cabal update should give warning when preferred versions will result in something other than the latest version on hackage ---------------------------------+------------------------------------------ Reporter: tphyahoo | Owner: duncan coutts Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Changes (by kosmikus): * milestone: cabal-install-0.16 => cabal-install-0.14.2 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/408#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Move to github or other collaboration site
by Eyal Lotem 17 Apr '12

17 Apr '12

Hey, I am personally finding the process of contributing to cabal much more painful than it would be if it were on github. I think the project is losing on contributions, and that's a shame, for the following reasons: A) A contributor isn't certain his contribution will be accepted, and if it isn't, his effort is in vain. He may very well give up before starting. With github, worst-case he can maintain a hosted fork, and point people to it. B) Even if it is accepted, *until* it is, he has no easy way of pointing people to his fork, unlike on github. C) Making a pull request is much easier and less trouble than registering to a mailing list, and the overheads associated with communicating email patches. I think most collaborators will gladly spend hours improving cabal, but would rather not spend minutes on patch sending overheads. Please move development of cabal to github or at least a darcs-hosting site where it is easy to make hosted forks and send pull requests. Eyal

3 2

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 16 Apr '12

16 Apr '12

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: | Platform: ---------------------------------+------------------------------------------ Comment(by DavidMazieres): Can someone comment as to how to use the new feature. I've tried putting a bunch of stuff in ~/.cabal/config, but can't get it to hyperlink-source by default. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:17> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 16 Apr '12

16 Apr '12

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by kosmikus): * status: new => closed * resolution: => fixed Comment: Seems to work. Closing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:16> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0