Push new version to Hackage - Githubissues

creswick / cabal-dev

A wrapper program around cabal and cabal-install that maintains sandboxed build environments.

BSD 3-Clause "New" or "Revised" License

150 stars 24 forks source link

Push new version to Hackage #74

Open bgamari opened 11 years ago

bgamari commented 11 years ago

Currently the version on Hackage does not compile with GHC 7.6.

akaspin commented 11 years ago

Bump

jtdaugherty commented 11 years ago

In order to push a new release to Hackage, we need to be sure cabal-dev works on the two most recent Haskell Platform releases in addition to GHC 7.6. It's pretty clear that we have GHC 7.6 out of the way. Care to help us out and test on HP 2012.4.0.0 and HP 2012.2.0.0? Also, it needs to be tested on at least Linux and Windows, with OS X being valuable, too.

etrepum commented 11 years ago

Well, the current hackage version definitely does not work on OS X with HP 2012.4.0.0 prior to this commit https://github.com/creswick/cabal-dev/commit/80d7bc3c3ceef9deb9189cea87fb1fe3e50d6b4f#cabal-dev.cabal

Installing from source (415351d2) appears to work fine (ghc 7.4.2, HP 2012.4.0.0, Mac OS X 10.8.2, used homebrew to install ghc and haskell-platform)

$ git clone https://github.com/creswick/cabal-dev.git && (cd cabal-dev; cabal install)
Cloning into 'cabal-dev'...
[…]
Linking dist/build/cabal-dev/cabal-dev ...
Installing executable(s) in /Users/bob/.cabal/bin

etrepum commented 11 years ago

Just my opinion, but I think you should probably just push what you have now. If you broke HP 2012.2.0.0 on some platform, I'm sure you'll hear about it eventually. Keeping up with HP 2012.4.0.0 and newer GHC is probably much more important, people with old versions can always target some old version of cabal-dev on hackage until any backwards compatibility issues are sorted out.

spockz commented 11 years ago

I concur with etrepum, it is very inconvenient not to be able to build cabal-dev on a fresh HP2012.4.0.0 install.

etrepum commented 11 years ago

@jtdaugherty in #91 you mentioned that "some tests are failing" and this is the reason why there hasn't been a new release. Where can we find out more about the tests that are failing?

jtdaugherty commented 11 years ago

You can find out by running this from the root of the repository:

$ bin/runtests

etrepum commented 11 years ago

@jtdaugherty the failures seem to be timing related, probably cabal-dev is being executed in parallel with itself. I'll dig a bit deeper and submit a PR once I've figured it out.

etrepum commented 11 years ago

On further inspection, I believe that 00-index.cache is the problem in addSourceStaysSandboxed. Here's what I think is happening (all during the same second, let's call it M):

00-index.tar is created with an empty index (withTempPackage), this file has an mtime of M.
00-index.cache is created during the install that is expected to fail (withCabalDev assertExitsFailure ["install", pkgStr]). This file is empty and has an mtime of M.
00-index.tar is updated with the new package (withCabalDev assertExitsSuccess ["add-source", packageDir])), the mtime does not change since the clock is still at M. The problem is here, 00-index.cache still exists and is still considered to be valid but it's actually stale (and empty).
The test fails at withCabalDev assertExitsSuccess ["install", pkgStr, "--verbose=" ++ showForCabal v] because the (empty) 00-index.cache is incorrectly considered to be valid since it has the same mtime (M) as 00-index.tar.

I think any operation that updates 00-index.tar should probably just remove the cache file. Also, this appears to be a cabal-install bug, not a cabal-dev bug. My recommendation would be to include a workaround in the test suite for cabal-dev (e.g. manually delete or refresh the cache after the add-source) and file a bug against cabal-install.

ghost commented 5 years ago

bump