Notice for package authors
Package authors, We are about to add an additional quality check in the Hackage upload process that will affect many packages. Hackage will require an upper bound on the version of the base package and reject packages that omit it. Lots of packages currently specify: build-depends: base or build-depends: base >= 3 This is bad. There is no way for the tools to discover if you mean base 3 or 4 and yet most packages break when we pick the wrong one. You must specify an upper bound so that your package does not break when the next major version of the base library is released. For example, if you've tested with base 3 and 4 then use: build-depends: base >= 3 && < 5 Or if it needs version 4 then use: build-depends: base == 4.* Background ---------- When base 4 was released with ghc-6.10.x the vast majority of packages would have broken were it not for a compatibility shim that we added to the cabal-install tool. It defaulted to picking base 3 when the version constraints did not otherwise specify the use of base 4. The same trick will not work when base 5 is released because it will likely not be possible to continue to ship base 3. It is also important that we start to move towards making the majority of packages compatible with base 4. cabal-install changes --------------------- We will shortly release a minor update to cabal-install to change the way it picks between base 3 and 4. Currently if it has the choice it picks version 3. However that is not optimal for cases like: build-depends: base >= 3 && < 5 where it is clear that it is supposed to work with both. In this case we should not be pessimistic in going with the old base 3 and should instead pick base 4. More precisely, we will only apply the compatibility shim when the version is unbounded above. When it is bounded above, as Hackage will soon require, the normal preference to use the latest version applies. If you'd like to help us check this feature is working properly then grab the latest darcs version of cabal-install (which needs the latest darcs version the Cabal lib). See also http://hackage.haskell.org/trac/hackage/ticket/485 Duncan
On Wed, 2009-06-03 at 11:36 +0100, Duncan Coutts wrote:
Package authors,
We are about to add an additional quality check in the Hackage upload process that will affect many packages. Hackage will require an upper bound on the version of the base package and reject packages that omit it.
The check is now active. If you upload and think that your package is rejected in error then please email the cabal-devel list or file a ticket: http://hackage.haskell.org/trac/hackage/ Note that currently "cabal upload [--check]" is pretty awful at reporting the package quality errors that hackage generates. The current workaround is to use -v3 to see the whole HTTP conversation, the tail of which will include package quality error messages. This should be improved for a future release (see ticket #549 if you'd like to work on it). Duncan
On Wed, 3 Jun 2009, Duncan Coutts wrote:
For example, if you've tested with base 3 and 4 then use:
build-depends: base >= 3 && < 5
Or if it needs version 4 then use:
build-depends: base == 4.*
It would be cool, if base-3 could be used with GHC-6.10 for packages that have not been updated so far. When I upload a base-3 package to Hackage today, it may be not be built by Hackage because Hackage only supports base-4 currently.
On Wed, 2009-06-03 at 23:15 +0200, Henning Thielemann wrote:
On Wed, 3 Jun 2009, Duncan Coutts wrote:
For example, if you've tested with base 3 and 4 then use:
build-depends: base >= 3 && < 5
Or if it needs version 4 then use:
build-depends: base == 4.*
It would be cool, if base-3 could be used with GHC-6.10 for packages that have not been updated so far.
Yes, that's how it works now if you're using cabal-install with ghc-6.10.
When I upload a base-3 package to Hackage today, it may be not be built by Hackage because Hackage only supports base-4 currently.
I'm missing something. The build client for hackage uses ghc-6.10.x which includes base 3 and 4. What problem are you seeing exactly? Duncan
[Not replying to haskell-cafe since not subscribed.] Duncan wrote:
There is no way for the tools to discover if you mean base 3 or 4 and yet most packages break when we pick the wrong one. You must specify an upper bound so that your package does not break when the next major version of the base library is released.
For example, if you've tested with base 3 and 4 then use:
build-depends: base >= 3 && < 5
Then ``build-depends'' is a misnomer because most packages will most likely not DEPEND on the fact that the used base package has version less than 5. This misnomer is one major source of my uneasiness with cabal. I would like to propose ``tested-with'' as a better name, and would like to see a way for users to easily test with a version I did not have avaliable, and report that back (perhaps to hackage). E.g., ./Setup configure --accept="base==5.9" ./Setup build ./Setup install ./Setup test ./Setup report-build-and-test-to-hackage (long name to make sure users know they are going to send a message.) The flag --accept would add a disjunction to the ``tested-with'' formula (to allow the build), in contrast with the semantics documented for the flag --constraint in the output of ./Setup --configure --help, which adds a conjunction. Probably a ``--force="base==5.9"'' would also make sense, it would then be an abbreviation for ``--accept="base==5.9" --constraint="base==5.9"''. (Sequence of the two flags would matter!) Of ocurse, I can, for example, honestly only write tested-with: base `elem` [2.1.1, 3.0.1.0, 3.0.3.1, 4.1.0.0] because those are the versions I happen to have lying around, and you probably would like to allow building with == 2.1.1.* || == 3.0.1.* || (>= 3.0.3.1 && < 3.0.4) || == 4.1.* without hesitation, and at least trying with (>= 2.1.1 && < 2.2) || (>= 3.0.1 && < 3.1) || == 4.1.* according to the version convention. But in general there is no guarantee that a give package actually implements that, or does hackage test for compliance with the version convention? Yet another problem is that if I write tested-with: pkg1 == v1_1 || == v1_2 ... pkg9 == v9_1 || == v9_2 , I probably won't have tested all 2^9 combinations... So I really want to write something like: tested-with: (pkg1 == v1_1 && pkg2 == v2_1) || (pkg1 == v1_1 && pkg2 == v2_2) || (pkg1 == v1_2 && pkg2 == v2_2) Then you may want to at least warn the user who has only (pkg1 == v1_2 && pkg2 == v2_1) installed... Wolfram
On Thu, 2009-06-04 at 09:13 +0000, kahl@cas.mcmaster.ca wrote:
[Not replying to haskell-cafe since not subscribed.]
Duncan wrote:
There is no way for the tools to discover if you mean base 3 or 4 and yet most packages break when we pick the wrong one. You must specify an upper bound so that your package does not break when the next major version of the base library is released.
For example, if you've tested with base 3 and 4 then use:
build-depends: base >= 3 && < 5
Then ``build-depends'' is a misnomer because most packages will most likely not DEPEND on the fact that the used base package has version less than 5.
It depends on how much base 5 changes from 4 as to the likelihood of the package breaking. Looking back at the days of base 2, I think retrospectively we can reasonably say that all the packages that used "build-depends: base >=2" really did "DEPEND" on the fact that the used base package has version less than 3. The transition to base 3 was very disruptive, only the most trivial programs did not break. It's true that it's pessimistic and based on future unknowns. Other people have also suggested that it should not be "depends" but something else to say that it's a speculative upper bound rather than a known one based on testing.
This misnomer is one major source of my uneasiness with cabal.
The upper bound bits specifically or generally using version ranges? Version ranges do only make sense when you know the versioning policy of the package you're depending on, so that you know how changes in future versions of the package will be reflected in version number changes.
I would like to propose ``tested-with'' as a better name, and would like to see a way for users to easily test with a version I did not have avaliable, and report that back (perhaps to hackage).
Certainly speculatively trying with later versions and reporting is a useful thing. Doing it via hackage build clients and emailing authors would be nice.
Of ocurse, I can, for example, honestly only write
tested-with: base `elem` [2.1.1, 3.0.1.0, 3.0.3.1, 4.1.0.0]
because those are the versions I happen to have lying around, and you probably would like to allow building with
Given that you know the versions that worked and you know that the package in question is following the PVP (otherwise none of this makes sense) then you can derive the upper bounds you're interested in.
But in general there is no guarantee that a give package actually implements that, or does hackage test for compliance with the version convention?
Right, it only makes sense if you know the versioning policy of the package. In particular we know base follows the PVP. An idea is to let packages opt-in to following a named version policy (eg the PVP).
Yet another problem is that if I write
tested-with: pkg1 == v1_1 || == v1_2 ... pkg9 == v9_1 || == v9_2
, I probably won't have tested all 2^9 combinations...
Yes, we have to assume some kind of independence. Clearly version numbers are an approximation of precise type (and semantic) interfaces. It's not a total solution but should help significantly reduce the number of packages that needlessly break in confusing ways when end-users upgrade things. We're certainly not trying to suppress ideas or work on better, more complete solutions. In the mean time we're trying to reduce the expected pain of breakage at major transitions. Duncan
participants (3)
-
Duncan Coutts -
Henning Thielemann -
kahl＠cas.mcmaster.ca