heinrichapfelmus / vault Goto Github PK

The code of this package is very redundant, I suggest using CPP to refactor it, like this: Changaco/vault@master...factorize

Revision 2 of version 0.3.1.5 on Hackage disallows base-4.18, which is the version of base shipped in GHC 9.6.1. It would be nice if this version was supported.

There is a new major release of hashable. As far as I can see, bumping the upper bound is enough to support it.

Interestingly, this is actually causing problems at the moment (cabal-install is having a hard time finding installation plans, e.g. lambdabot/lambdabot#183).

For example, in #30, there is no indication whether the Travis build succeeded or not.

I have already experienced this in several other repos, and it has already caused me quite a bit of pain.

@HeinrichApfelmus, since you're the admin of this repo, I think only you can fix this. Could you try following the instructions that I posted in quchen/prettyprinter#172 (comment)?

(It looks like it is a missing file in the vault package, "IO.hs")

cabal install vault
Resolving dependencies...
Configuring vault-0.3.0.1...
Building vault-0.3.0.1...
Preprocessing library vault-0.3.0.1...

src/Data/Vault/Lazy.hs:6:0:
fatal error: IO.hs: No such file or directory
compilation terminated.
Failed to install vault-0.3.0.1
cabal: Error: some packages failed to install:
vault-0.3.0.1 failed during the building phase. The exception was:
ExitFailure 1

In an effort to make the reactive-banana library compile on UHC, I would like to include a variant of the vault package that doesn't use any GHC-specific functions. Of course, the best way to do this is to use the CPP preprocessor.

The only trouble is probably the ST monad which UHC likely doesn't have. However, I think that ST can be implemented in terms of unsafePerformIO, so it's easy to add it to the UHC libraries.

The package v0.3.1.5 excludes base-4.20, which is the version that ghc9.10 uses according to release notes

GHC 8.0 ships with base-4.9, which is disallowed by vault. A new release which can be used with GHC would be useful, and would allow me to test my downstream projects with GHC 8.0.

Trying to build version 0.2.0.3 on Windows

Not sure if it is a problem of vault and not of hackage itself - on page http://hackage.haskell.org/package/vault-0.3.0.2/docs/Data-Unique-Really.html link for Data.Unique contains local URI with file:// scheme

In vault-0.2 we had the module Data.Vault which was split into Data.Vault.Lazy and Data.Vault.Strict in vault-0.3. Can I have back a Data.Vault that re-exports either Data.Vault.Lazy and Data.Vault.Strict? This would be analogous to Data.Map that re-exports Data.Map.Lazy. It would both show the programmer the prefered Vault variant and allows him to support both vault-0.2 and vault-0.3 by importing Data.Vault.
However in order to allow simple version ranges like vault >=0.2 && <0.4 it would be necessary to deprecate vault-0.3 at Hackage.

I am unsure whether this is about reactive-banana or about vault. The issue originates here but shows in the other package.

Today, I manually installed packages into a fresh ghc-7.6.3 build to ultimately get a working reactive-banana package. The compiler is a custom version but corresponds to ghc-7.6.3 in functionality by default.

The manual installation was done using the following commands while standing in each package directory:
myGHC Setup.hs
./Setup configure --with-ghc=myGHC --global
./Setup build
./Setup register --inplace

Dependencies shown on hackage suggested the following installation order:
vault - text - hashable - unordered-containers - reactive-banana
This is wrong, as I found out later. The build of reactive-banana fails with error No instance for (Hashable Unique).
The vault cabal file specifies an additional vault dependency on hashable controlled by flag UseGHC (default true); if the flag is set, the instance will be declared. Rebuilding vault after the installation of hashable fixed the error, the build of reactive-banana went through.

So, where does a fix belong?
A fix inside reactive-banana would probably test the Hashable instance, but would not help users identify the issue. Better would be to make sure vault does not build with GHC when the flag was not unset explicitly. Ultimately, this might be a cabal issue? (too eagerly trying to install packages with flags that later create incompatibilities).

/ Jost

I don't see this addressed anywhere in the docs, and I assume that it isn't thread-safe, but I just wanted to check.

This seems to work, so a revision could be sufficient:

 % cabal get vault
Unpacking to vault-0.3.1.5/
 % cd vault-0.3.1.5 
 % cabal repl --allow-newer=vault:base