April 2010 - cabal-devel

[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

[Hackage] #665: Confusion situation when linking ./dist/setup/setup is interrupted
by Hackage 05 Mar '12

05 Mar '12

#665: Confusion situation when linking ./dist/setup/setup is interrupted ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If one accidentally interrupts cabal when it's linking `./dist/setup/setup` then you can end up with the file existing it not being executable. This leads to a confusing situation for the user. Running `cabal install` or `cabal configure` will fail silently. Running with -v indicates that something returns exit code 127. This corresponds to a permission error when trying to execute `./dist/setup/setup` Two improvements could be made: * Report the failure to execute `./dist/setup/setup` * If ghc is interrupted when creating `./dist/setup/setup`, cabal should delete the file, if it exists. That way, cabal will recompile on the next invocation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/665> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #669: Allow cabal-install's package build location to be set
by Hackage 05 Mar '12

05 Mar '12

#669: Allow cabal-install's package build location to be set ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Apparently some systems mount /tmp such that one cannot create and run executables. This is clearly problematic for cabal-install because it needs somewhere to build packages. http://article.gmane.org/gmane.comp.lang.haskell.cafe/73517 It may be useful for cabal-install to have a config setting to specify where to do package builds (for downloaded packages). If not specified this would default to the temp dir as now. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/669> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #670: cabal-install should warn about common problem after installing progs
by Hackage 05 Mar '12

05 Mar '12

#670: cabal-install should warn about common problem after installing progs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ There are a few common problems have when installing programs. * target bindir (or symlink-bindir) is not on the `$PATH` so they cannot run the program after installation. * target bindir is on the `$PATH` but the installed program is masked by the presence of the same named prog in a dir that is earlier on the `$PATH`. For example `/usr/local/bin/cabal` and `~/.cabal/bin/cabal`, the latter might have just been installed but the earlier one will still be picked up. * the shell keeping a cache of name -> path and so not picking up a new program. Eg in the above example, even if `~/.cabal/bin/` comes first on the `$PATH`, if bash has the mapping `cabal` -> `/usr/local/bin/cabal` then it will not notice when `~/.cabal/bin/cabal` is installed. The fix here is to run `hash -r`. The only time we might want to tell users to run `hash -r` is if the program did not previously exist and if it gets installed in a location that is earlier on the `$PATH` than an existing installed instance (which may thus be in the cache). Sadly we cannot query sh to find out what its cache holds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/670> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #667: Improve tools to manage ad-hoc package releases
by Hackage 05 Jan '12

05 Jan '12

#667: Improve tools to manage ad-hoc package releases ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Hackage is suited for major software releases by package maintainers. It is not suited to distributing betas, daily snapshots or random forks, or patches of existing releases. For example a user may have some patch or bugfix for a package that they need. It takes time for maintainers to review and integrate these. Sometimes maintainers have little time, or they disagree with a patch approach or quality. It is right that maintainers have control over what is released on hackage. However there is a need for decentralised, ad-hoc and short term releases. We do not want to encourage the pollution of the package namespace with lots of short-term forks. One solution is to let users post package forks on their own webspace. We would want to extend cabal so that people can run: {{{ cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix- blah-1.0.1.tar.gz }}} This makes it very decentralised. We may want to add some feature to hackage package pages to link to third-party forks. In addition to hosting and installing single packages it would be useful to be able to publish package collections. Of course this is exactly what a hackage archive is. We should provide easy tools to make and manage hackage archives that can be hosted on dumb http file servers. Going one step further, the hackage index format should be extended to make it more RESTful by including links to tarballs rather than just assuming that tarballs are found relative to the index file using some fixed layout. This would allow people to publish indexes that span multiple servers. This gets close to the concept of a package "search path" promoted by the searchpath project (http://searchpath.org/) Additonally, an index should allow us to point to source control repos rather than just to release tarballs. This kind of index would be useful for nighly builds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/667> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #671: better error message for broken build tools
by Hackage 05 Jan '12

05 Jan '12

#671: better error message for broken build tools ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Consider: {{{ Configuring haskell-src-exts-1.9.0... setup: happy version >=1.17 is required but the version of /usr/local/bin/happy could not be determined. }}} The actual problem is: {{{ /usr/local/bin/happy: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory }}} We could produce a better error message in this situation. If we get a non-0 exit code when we check the `--version` then we can probably safely report that the program is probably broken. Of course if we get some result text back and we cannot extract and parse the version number then that's different. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/671> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #663: Setup.hs doesn't look into ~/.cabal/bin for build tools.
by Hackage 05 Jan '12

05 Jan '12

#663: Setup.hs doesn't look into ~/.cabal/bin for build tools. ----------------------------------+----------------------------------------- Reporter: Axel Simon | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Cabal currently only checks the current PATH for buildtools. If the user installs and new pre-processor with the default --user installation, these tools wind up in ~/.cabal/bin. However, cabal doesn't find these unless ~/.cabal/bin has been added to the PATH. This is irritating since it is then not possible to make a library depend on a cabal package that contains it's build tools: Even if cabal-install installs the build tools first, building the library still fails since the tools cannot be found. The solution is very simple: Add ~/.cabal/bin to the search path when looking for build tools! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/663> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #666: configure should warn about using base 3
by Hackage 24 Sep '10

24 Sep '10

#666: configure should warn about using base 3 ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- http://haskell.org/pipermail/haskell-cafe/2010-April/076823.html For backwards compatibility we make cabal-install prefer base 3 if there is no upper bound on the version of base. This is necessary however it is also confusing. People writing new packages should be getting base 4. We want to encourage people to use base 4, as version 3 is deprecated. We should make `cabal configure` warn if base 3 is selected since this is deprecated. The message should indicate the appropriate solution, ie to put an upper bound on the version of base. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/666> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #668: Update simple distribution for LHC
by Hackage 29 Apr '10

29 Apr '10

#668: Update simple distribution for LHC ----------------------------------+----------------------------------------- Reporter: dmp | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.12.1 Platform: Mac OS | ----------------------------------+----------------------------------------- Cabal needs some updates for its LHC support. Two changes are needed (and implemented in the attached patch): 1) Change the hackRtsPackage to not fail with an error. The hackRtsPackage function was previously throwing an error when it found zero or more than one rts packages. The rts package is not needed in lhc, so the error is now ignored. This change now matches the behavior in the GHC distribution (Distribution/Simple/GHC.hs) 2) Change the value passed to the odir for compiling C files. The current code was doing a version check to catch a bug with GHC < 6.4. Since lhc is only version 0.9, it was also failing on the version check and passing an incorrect value to odir. Changed to use the correct value as with GHC > 6.4. I have attached a patch against the 1.8 branch that implements these changes. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/668> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #289: symlink binaries into ~/bin
by Hackage 29 Apr '10

29 Apr '10

#289: symlink binaries into ~/bin ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Changes (by gwern): * cc: gwern0@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/289#comment:19> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0