Can the build input restriction process == 1.1.* be relaxed? about optparse-applicative HOT 11 CLOSED

because process 1.0.1.5 is a base library of that compiler

Why exactly is it a problem? I've just installed a fresh process using ghc 7.0.4 without any problems:

% ghc --version    
The Glorious Glasgow Haskell Compilation System, version 7.0.4
% ghc-pkg list process
/home/feuerbach/local/ghc-7.0.4/lib/ghc-7.0.4/package.conf.d
   process-1.0.1.5
/home/feuerbach/.ghc/i386-linux-7.0.4/package.conf.d
   process-1.1.0.2

from optparse-applicative.

It is a problem, because code in 'base' or in GHC's library tree is
linked against process-1.0.1.5. (Otherwise, 'process' would not be
shipped with GHC.) If optparse-applicative is built against a different
version, then two incompatible versions of 'process' will eventually end
up being linked into the same binaries (one version via 'base' and the
other version via 'optparse-applicative'). That is very like to cause
undefined behavior, i.e segfaults and crashes.

from optparse-applicative.

But base doesn't depend on process, so it cannot be linked against (any particular version of) it.

from optparse-applicative.

The version of Cabal that's shipped with GHC 7.0.4 depends on process.

Why do you restrict process to version 1.1.x anyway? optparse-applicative typechecks and compiles just fine with older version of the library, so the restriction seems rather arbitrary to me?

from optparse-applicative.

The version of Cabal that's shipped with GHC 7.0.4 depends on process.

Well, it may only cause a problem if you build an application which depends on Cabal (not just uses Cabal to build itself), and even then you have an option to install a newer Cabal (which is also unproblematic).

To be clear, I'm all for relaxing the version bounds. I was just curious whether there's a genuine problem preventing anything that depends on the new process to be built with an older ghc.

Have you actually run into any problems, or do you just hesitate to upgrade the libraries?

from optparse-applicative.

Roman, is there any particular reason why you don't answer my question?

from optparse-applicative.

You mean this one?

Why do you restrict process to version 1.1.x anyway?

I thought it was addressed to Paolo, who maintains optparse-applicative.

from optparse-applicative.

Roman, it would have been good if you had said upfront that you don't maintain this library and that your interest in this issue is purely academic.

@pcapriotti, it seems to me like the restriction on process 1.1.x is unnecessary. The module compiles and works just fine with older versions of process, too. I'd suggest lifting this restriction to enable users older compilers to use it. (In my tests, even GHC 6.12.3 built that code without any problems).

from optparse-applicative.

I'm sorry if I confused you.

Could you still satisfy my academic interest?

from optparse-applicative.

@feuerbach, for people who know what they are doing and who are comfortable messing with cabal-install and ghc-pkg, it's possible to update Cabal and process and ensure that everything else which depends on those two libraries is re-built if necessary. It's a tedious process, IMHO, but it's possible to do it. From that point of view, you are right: the overspecified restriction on process doesn't prevent people from installing optparse-applicative with older versions of GHC per se.

In practice, however, not everyone is comfortable doing these kind of intricate updates. Many Haskell developers rely on packages that are distributed by their native package manager and don't use cabal-install at all. For those users, updating Cabal may not even be possible, because they cannot easily re-compile everything that might be affected by such an update.

Generally speaking, I am baffled that you suggest updating Cabal and re-compiling everything that depends on it to solve a problem which could be solved simply by changing one digit from 1 to 0 in the optparse-applicative.cabal file. The latter solution seems way more economic to me. Just my 2 cents.

from optparse-applicative.

@pcapriotti, it seems to me like the restriction on process 1.1.x is unnecessary. The module compiles and works just fine with older versions of process, too. I'd suggest lifting this restriction to enable users older compilers to use it. (In my tests, even GHC 6.12.3 built that code without any problems).

You're right, I'm not sure why I put that lower bound. I thought I tested on 7.0.4. Anyway, it should be ok now. I also updated the tests to work with 7.0.4.

Thanks!

from optparse-applicative.