Re: [Haskell-cafe] Re: circular dependencies in cabal
Hi Duncan, I agree with your arguments. I think it is a less evil to disable 'cabal upgrade' until the problem is fixed. To have 'cabal upgrade' to ask for confirmation (and to allow user to select packages to be updated from the list) is even better. -- Valentyn. On Feb 3, 2009, at 2:04 AM, Duncan Coutts wrote: On Mon, 2009-02-02 at 19:16 -0800, Valentyn Kamyshenko wrote: Hi Duncan, The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages). Right, that's exactly what doesn't work well and that I'm proposing to temporarily disable. I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal. And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)? Yes and there are a couple of additional ways we could improve it. But I'm thinking it'd be better to release before those things are done, and so in the mean time disable upgrade. In the mean time we can make it list the available packages that are newer than the installed ones and you get to pick manually which ones are sensible to install. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: circular dependencies in cabal
Hi Duncan, The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages). I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal. And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)? -- Valentyn. On Feb 2, 2009, at 5:34 PM, Duncan Coutts wrote: On Tue, 2009-02-03 at 02:11 +0100, Achim Schneider wrote: Duncan Coutts wrote: That is probably how people are getting into this mess. Using upgrade is not necessarily such a good idea. It does not distinguish between the interesting packages you might want to upgrade and the core packages that your probably do not want to touch. There's no need to use cabal upgrade to get into this kind of mess, I successfully pulled conflicting cabal versions just by using cabal install. Indeed, it's just easier to shoot yourself in the foot using upgrade. Would anyone object if I disable the upgrade command in the next version and not re-enable it until it works? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] circular dependencies in cabal
So, in practical terms, you suggest that no new version of the package that ghc package depends on (directly or indirectly) should ever be installed? For example, as soon as process-1.0.1.1 is installed on my computer, I'll have this problem with every package that depends on "process"? Another question: would not cabal-install automatically fetch the most recent version of the "process" package, as soon as I will try to install a package that depends on it (such as, for example, "plugins")? -- Valentyn. On Feb 1, 2009, at 6:53 AM, Duncan Coutts wrote: On Sun, 2009-02-01 at 01:33 -0800, Valentyn Kamyshenko wrote: Hello all, when I tried to install plugins package with cabal, I've got the following error: # sudo cabal install plugins --global Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 For the most part I refer you to: http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html However the difference is that you've got this problem only within the global package db rather than due to overlap in the global and user package db. It looks like both versions of process package are currently required: It looks like you installed process-1.0.1.1 and then rebuilt almost every other package against it. Of course you cannot rebuild the ghc package but you did rebuild some of its dependencies which is why it now depends on multiple versions of the process package. Generally rebuilding a package without also rebuilding the packages that depend on it is a bit dodgy (it can lead to linker errors or segfaults). Unfortunately cabal-install does not prevent you from shooting yourself in the foot in these circumstances. Any suggestions? Aim for a situation where you only have one version of the various core packages. If you do not need to install packages globally then installing them per-user means you at least cannot break the global packages. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] circular dependencies in cabal
well, the first and most immediate problem is that I can not even fetch the package from hackage using cabal: # cabal fetch plugins Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 so, although I believe the problem with different versions of the same package to co-exist on my computer may be ignored in mane cases, this case makes life very inconvenient. -- Valentyn On Feb 1, 2009, at 1:57 AM, Marc Weber wrote: Any suggestions? a) ignore it and hope you don't get segfaults or problems. b) choose one process libraries and rebuild the other packages using that one. About a) I'm not totally sure what could happen. I just can say That i've used different cabal versions and it went fine. I guess that the problem is A using P-1.0 B using P-1.2 you using A and B, passing data indirectly from A to B and A and B having different compilation options or different behaviour. I'm not too sure about this. Maybe this can give you an idea what could happen. On the other hand you do use runXY or system from process only without passing data from one to the other so chances are good that your app will work nevertheless. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] circular dependencies in cabal
Hello all, when I tried to install plugins package with cabal, I've got the following error: # sudo cabal install plugins --global Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 It looks like both versions of process package are currently required: # ghc-pkg unregister process-1.0.1.0 ghc-pkg: unregistering process-1.0.1.0 would break the following packages: haddock-2.3.0 ghc-6.10.1 Cabal-1.6.0.1 gnuplot-0.2 pandoc-1.0.0.1 Graphalyze-0.5 haddock-2.4.1 kibro-0.4.2 panda-2008.11.7 (use --force to override) # ghc-pkg unregister process-1.0.1.1 ghc-pkg: unregistering process-1.0.1.1 would break the following packages: haddock-2.3.0 ghc-6.10.1 haskell-src-1.0.1.3 polyparse-1.1 Graphalyze-0.5 cpphs-1.6 hscolour-1.10.1 haddock-2.4.1 HaXml-1.19.4 hcheat-2008.11.6 rss-3000.1.0 kibro-0.4.2 panda-2008.11.7 haskell98-1.0.1.0 hxt-8.2.0 hcheat-2008.11.14 hxt-filter-8.2.0 xml- parsec-1.0.3 graphviz-2008.9.20 readline-1.0.1.0 uulib-0.9.5 derive-0.1.4 hslogger-1.0.6 MissingH-1.0.2.1 HStringTemplateHelpers-0.0.3 HSHHelpers-0.17 haskell-src-exts-0.4.4 haskell-src-exts-0.4.4.1 haskell-src-exts-0.4.5 ConfigFile-1.0.4 HStringTemplateHelpers-0.0.4 haskell-src-exts-0.4.6 kibro-0.4.3 panda-2008.12.16 HStringTemplateHelpers-0.0.6 SybWidget-0.4.0 wxcore-0.10.5 wx-0.10.5 xtc-1.0 HStringTemplateHelpers-0.0.8 wxcore-0.10.7 wx-0.10.6 HNM-0.1 HNM-0.1.1 wxcore-0.10.12 wxcore-0.11.0 wx-0.11.0 HSHHelpers-0.18 haskell-src-exts-0.4.8 darcs-2.2.0 hslogger-1.0.7 MissingH-1.0.3 HSH-1.2.6 HStringTemplateHelpers-0.0.10 HSHHelpers-0.19 hscolour-1.11 HNM-0.1.2 pandoc-1.1 mps-2008.11.6 hcheat-2008.11.25 panda-2009.1.20 testpack-1.0.0 convertible-1.0.1 gnuplot-0.3 HDBC-2.0.0 HDBC-2.0.1 HDBC-sqlite3-2.0.0.0 HDBC- postgresql-2.0.0.0 (use --force to override) Any suggestions? -- Valentyn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HDBC v2.0 now available
Thank you John, it worked like a charm :) -- Valentyn. On Jan 31, 2009, at 7:30 AM, John Goerzen wrote: Niklas Broberg wrote: Thanks for the hint for folks. Why would cabal-install select a different base than running Setup manually? Someone thought it was a good idea to make base-3 the preferred selection for cabal-install, to make the transition from base-3 to base-4 as smooth as possible. It may have worked for that, but it's causing a lot of problems now instead. Time for a new policy/version for cabal-install? I've just uploaded HDBC 2.0.1 to cabal, that has the same hack as extensible-exceptions. Would one of you that had trouble with cabal-install on 2.0.0 please test and let me know if it's better? Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HDBC v2.0 now available
Thanks, Krzysztof - it worked for me. Something is definitely wrong with cabal dependencies: even when HDBC-2.0.0 was installed, it tried to install it again (and failed) when I tried to install HDBC-postgresql and HDBC-sqlite3. Manual installation (./Setup configure; ./Setup build; ./Setup install) worked. Thank you for your help, -- Valentyn. On Jan 30, 2009, at 3:52 PM, Krzysztof Skrzętnicki wrote: On Sat, Jan 31, 2009 at 00:45, Krzysztof Skrzętnicki wrote: On Sat, Jan 31, 2009 at 00:07, Valentyn Kamyshenko wrote: Hello John, I'm trying to install the new version of HDBC on my Mac (ghc version is 6.10.1), and get the following error: # cabal upgrade --global Resolving dependencies... 'HDBC-2.0.0' is cached. Configuring HDBC-2.0.0... Preprocessing library HDBC-2.0.0... Preprocessing executables for HDBC-2.0.0... Building HDBC-2.0.0... [1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/ SqlValue.hs, dist/build/Database/HDBC/SqlValue.o ) [2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ ColTypes.hs, dist/build/Database/HDBC/ColTypes.o ) [3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/ Statement.hs, dist/build/Database/HDBC/Statement.o ) Database/HDBC/Statement.hs:113:9: Type constructor `Exception' used as a class In the instance declaration for `Exception SqlError' cabal: Error: some packages failed to install: HDBC-2.0.0 failed during the building phase. The exception was: exit: ExitFailure 1 I got the same error: Windows XP, GHC 6.10.1. For some reason imported Control.Exception module appears to be 6.8.* version. I found a (temporary) fix: change dependancy in .cabal file to state "base >= 4". Otherwise cabal-install selects base-3 which is the cause of the problems. All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HDBC v2.0 now available
Hello John, I'm trying to install the new version of HDBC on my Mac (ghc version is 6.10.1), and get the following error: # cabal upgrade --global Resolving dependencies... 'HDBC-2.0.0' is cached. Configuring HDBC-2.0.0... Preprocessing library HDBC-2.0.0... Preprocessing executables for HDBC-2.0.0... Building HDBC-2.0.0... [1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs, dist/build/Database/HDBC/SqlValue.o ) [2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs, dist/build/Database/HDBC/ColTypes.o ) [3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/ Statement.hs, dist/build/Database/HDBC/Statement.o ) Database/HDBC/Statement.hs:113:9: Type constructor `Exception' used as a class In the instance declaration for `Exception SqlError' cabal: Error: some packages failed to install: HDBC-2.0.0 failed during the building phase. The exception was: exit: ExitFailure 1 any suggestions? Thanks you, Valentyn. On Jan 30, 2009, at 1:28 PM, John Goerzen wrote: Hi everyone, I'm pleased to announce that HDBC v2.0 is now available. Simultaneously, HDBC-sqlite3, HDBC-postgresql, and HDBC-odbc v2.0 have also been uploaded. All may be found from Hackage, or at software.complete.org. A guide to new features and migration can be found at: http://software.complete.org/software/wiki/hdbc/NewIn20 A partial summary of it follows: New Features: * Pervasive Unicode support now part of the HDBC API and implemented by all backend drivers. Based on utf8-string and conversions between UTF-8 ByteStrings and Haskell Strings. * Full support for GHC 6.10 is new. Full support for GHC 6.8 is maintained. * Native support for the new exception handling in GHC 6.10, with CPP conditional compilation to continue supporting the old-style exceptions for users of GHC 6.8 or Hugs. * HDBC now has direct support for marshalling virtually all of the Data.Time.* types to and from SQL database date/time types. toSql and fromSql/safeFromSql now support conversions between Data.Time.* types and SqlValue. Conversions between System.Time.* types were present from the beginning and will remain. Automatic conversions are, of course, contingent on support in database engines and HDBC database backend drivers and may not be possible with all databases. * Major expansion of SqlValue to be able to carry date/time data to/from databases in terms of Data.Time.* types. + The old SqlTimeDiff and SqlEpochTime types continue to be present, but are deprecated and will be removed in a future. toSql no longer converts anything to them. The System.Time.* types are converted to the new Data.Time-based SqlValues. It should be exceptionally rare that any user code would use these types directly, but they are being retained in this version out of an abundance of caution. * Replace fromSql with safeFromSql, which returns Left on impossible conversions instead of raising an exception. + Wrote a new fromSql that behaves just like the old one, but is implemented in terms of safeFromSql. It converts the safeFromSql errors to exceptions. + The new structure made it possible to greatly enhance many error messages throughout the conversion process instances. + Removed SqlType typeclass. Re-implemented SqlValue conversions in terms of the generic infrastructure in the convertible package. Simplified code significantly due to this. * Lots of additional docs. * New skeleton test suite for HDBC itself (to be expanded upon later). Richer Date and Time Support HDBC 1.x had only two ways of getting dates and times between Haskell and a database: an epoch (an Integer representing the number of seconds since midnight Jan 1 1970 UTC) and an Integer representing a TimeDiff (a count of elapsed time). While this approach could represent a precise instant in time, it was not always the most helpful. Most notably, you might sometimes want to load date information without time, time without date, or record what timezone the time was measured within. HDBC can now convert all of these things with much greater precision. Thanks to Phil Wise for adding the first Unicode support (to HDBC-postgresql originally) and to Alson Kemp for adding the first advanced date/time marshalling support (also to HDBC-postgresql originally). The experience of adding these features to a single backend driver first made clear a good way to add them to HDBC API as a whole. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing
