Some possible solutions for the dependency issues
Hi, so with all the furor over dependency hell I've been thinking about how to address the issue. I've come up with an approach that I'm willing to try to implement, if it's sensible. First is using explicitly versioned libraries and executables. For example, using 'alex-3.0.2' instead of just 'alex'. Next is implementing the suggestion for soft and hard upper bounds. Hard upper bounds would be denoted by a duplicated first character of the relevant operator, ie, <<, <<=, ===. Finally, if an install fails because of dependency versioning issues, automated support for fixing these issues would kick in, probably after prompting the user if they want to attempt it, or after issuing a command such as 'cabal repair'. There would be integration with bug reporting and bug report search so that if there are problems that are more than the user wants to deal with the bug report could be submitted easily. This functionality would be available with the command 'cabal submit-issue'. If the repair was successful patches would be submitted to the maintainer after checking that similar patches haven't been submitted already. Maybe it could be useful for cabal to provide convenient means of communicating with the package maintainer. For example, instead of having to subscribe to the mailing list for gtk 'cabal submit-issue' would present the results of search to see if the issue was already brought up. If the user doesn't think anything relevant came up they could then be presented with a form for filing a bug report. After that the user would be kept in the loop without having to subscribe to the mailing list. So does this sound like a useful solution?
On Sat, Aug 25, 2012 at 6:56 AM, Chris Moline
Hi, so with all the furor over dependency hell I've been thinking about how to address the issue. I've come up with an approach that I'm willing to try to implement, if it's sensible.
I'd like to elaborate on what I said. A goal of mine is to have every package using the most recent versions of their dependencies. I have a script whose basic functionality is mostly finished. What it does is fetch the latest version of a package, then update its build dependencies to use the most recent versions and then compile, failing if there are errors or warnings. If the build fails the most recent copy of the source code is obtained using the relevant version control command and I tinker with it trying to get it to compile. If it's too difficult I stick it in the ignore list, otherwise I generate a patch and submit it. This shouldn't take too long because most errors and warnings are trivial, for example using mkTyCon3 instead of mkTyCon or importing catch from the right module. After I make my first pass through the archive I will have a utility that follows the rss feed and recompiles all packages that depend on the new package. At this time I will start running any test suites these packages have and then running hlint on them. I imagine fixing all the hlint suggestions will take a long time. So I'm thinking the install strategy for cabal-install could simply be install the latest versions of the dependencies. Previously installed packages could continue to use the older versions of dependencies they were compiled against. We could track whether a package was installed by the user or automatically as a dependency, that way we could have an update commmand that will install the latest versions of any out-of-date packages and any automatically installed packages that are no longer depended on could then be removed. So between this script of mine, adapting packages to use explict versions of libraries and executables, and hard constraints to inhbit buggy interactions we should be able to have a nice experience with cabal-install.
participants (1)
-
Chris Moline