cabal-install and executable dependencies
Many packages have dependencies on executable packages. There are currently three ways to specify the dependency: -Include it in the dependencies list, which will reinstall it every time. -Omit it, and the user will have to work it out when they see the Setup error message. -Some packages "cheat" by including a dummy library with the executable. I would like to propose that cabal do simple dependency checking for executables. If it exists in the path or cabal's bin directory, then the dependency it deemed satisfied. If it's in cabal's bin but not the path, the user should be warned. This doesn't support version bounds, but surely it's better than the current situation. I'm assume that this has been discussed some time before, but can't find any such discussion. -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-executable-dependenci... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
On 2013-08-25 at 09:50:19 +0200, harry wrote:
Many packages have dependencies on executable packages. There are currently three ways to specify the dependency:
-Include it in the dependencies list, which will reinstall it every time. -Omit it, and the user will have to work it out when they see the Setup error message. -Some packages "cheat" by including a dummy library with the executable.
I would like to propose that cabal do simple dependency checking for executables. If it exists in the path or cabal's bin directory, then the dependency it deemed satisfied.
Are you proposing that each package listed in 'build-depends' should be looked up for its executables (if it contains any), and check if those are available as installed executable? What should happen if the executable is not found?
If it's in cabal's bin but not the path, the user should be warned.
Why only warned? Shouldn't the dependency check rather fail then, as the executable most likely won't be found? What if the executable found via $PATH differs from the one in ~/.cabal/bin (or the respective sandbox `bin` folder?); should then be warned as well?
This doesn't support version bounds, but surely it's better than the current situation. I'm assume that this has been discussed some time before, but can't find any such discussion.
cheers, hvr
Herbert Valerio Riedel wrote
Are you proposing that each package listed in 'build-depends' should be looked up for its executables (if it contains any), and check if those are available as installed executable?
What should happen if the executable is not found? cabal will try to install it, the same as if a libarary was not found in the
If it's in cabal's bin but not the path, the user should be warned. Why only warned? Shouldn't the dependency check rather fail then, as the executable most likely won't be found? Yes, the installation should probably fail with a warning explaining what
Yes, although it might be worth having this as a separate (build-depends-executable?) section. package database. the problem is.
What if the executable found via $PATH differs from the one in ~/.cabal/bin (or the respective sandbox `bin` folder?); should then be warned as well? Not suggesting that cabal check versions, just whether an executable by the specified name is on the path. Looking in .cabal/bin if it isn't there is just to help diagnose a misconfigured path variable.
-- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-executable-dependenci... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
This requested feature seems to overlap with the build-tools section,
however I don't think cabal will attempt to auto-install executables listed
there.
I think build-depends and build-tools should be kept separate, but maybe if
an executable listed in build-tools isn't found, cabal could look for a
package with the same name on hackage and attempt to install that first?
On Sun, Aug 25, 2013 at 6:20 AM, harry
Herbert Valerio Riedel wrote
Are you proposing that each package listed in 'build-depends' should be looked up for its executables (if it contains any), and check if those are available as installed executable?
Yes, although it might be worth having this as a separate (build-depends-executable?) section.
What should happen if the executable is not found? cabal will try to install it, the same as if a libarary was not found in the package database.
If it's in cabal's bin but not the path, the user should be warned. Why only warned? Shouldn't the dependency check rather fail then, as the executable most likely won't be found? Yes, the installation should probably fail with a warning explaining what the problem is.
What if the executable found via $PATH differs from the one in ~/.cabal/bin (or the respective sandbox `bin` folder?); should then be warned as well? Not suggesting that cabal check versions, just whether an executable by the specified name is on the path. Looking in .cabal/bin if it isn't there is just to help diagnose a misconfigured path variable.
-- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-executable-dependenci... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
John Lato-2 wrote
This requested feature seems to overlap with the build-tools section, however I don't think cabal will attempt to auto-install executables listed there.
I think build-depends and build-tools should be kept separate, but maybe if an executable listed in build-tools isn't found, cabal could look for a package with the same name on hackage and attempt to install that first?
I'd forgotten about build-tools. Does it actually do anything? -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-executable-dependenci... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
On Mon, Aug 26, 2013 at 1:06 AM, harry
John Lato-2 wrote
This requested feature seems to overlap with the build-tools section, however I don't think cabal will attempt to auto-install executables listed there.
I think build-depends and build-tools should be kept separate, but maybe if an executable listed in build-tools isn't found, cabal could look for a package with the same name on hackage and attempt to install that first?
I'd forgotten about build-tools. Does it actually do anything?
It checks that the executable is available on the current path, and that it's within the given version bounds. I think that's all it does.
John Lato-2 wrote
I'd forgotten about build-tools. Does it actually do anything?
It checks that the executable is available on the current path, and that it's within the given version bounds. I think that's all it does.
How can it check an executable's version? -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-executable-dependenci... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
Hi, On 2013-08-26 at 12:03:06 +0200, harry wrote:
John Lato-2 wrote
I'd forgotten about build-tools. Does it actually do anything?
It checks that the executable is available on the current path, and that it's within the given version bounds. I think that's all it does.
How can it check an executable's version?
see https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Progr... cheers, hvr
Herbert Valerio Riedel wrote
https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Progr...
Ah, a hard-coded list :-) So I would like to propose that cabal should install build-tool dependencies automatically if it can find them on hackage, and that package authors should actually start listing them. I started this thread after numerous failed installations of packages which depended on some undeclared executable. (e.g. happstack, which has depends on hsx2hs, which in turns depends on happy, but none of this is declared in the cabal files.) -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-executable-dependenci... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
participants (3)
-
harry -
Herbert Valerio Riedel -
John Lato