Loosen HaskellDB version constraint

[cscherrer]

The HaskellDB version dependency is a bit odd. Hackage has version 2.2.2, which doesn't build on the new ghc. Github has 2.2.3, which seems to build fine. But the current cabal file requires == 2.2.2.0.0.0.3.

Can this constraint be loosened at all? If 2.2.3 could work, it would be great to see >= 2.2.2.0.0.0.3 && < 2.4.

[tomjaguarpaw]

2.2.3 is certainly good enough currently. The problem is that we keep having to patch HaskellDB when we need to add new functionality to Opaleye. I'm not sure what the right approach to dealing with this is in the long term.

[tomjaguarpaw]

By the way, 2.2.2.0.0.0.3 is just an internal version number for us that doesn't exist in the outside world.

[bergmark]

There are some options:

1. Send pull requests and wait for releases
2. Maintain a pubic fork on github
3. Maintain a public fork on hackage
4. Drop the dependency
5. If the changes can be external, release an addon package

Pick your poison :-) 4 together with 1 is the nicest if it's possible...

I'd be fine with #2, git submodules and/or a local hackage server solves installation pains, if haskelldb development is slow it shouldn't be much work to maintain a fork. But you also have to consider whether to rename the package.

[dbp]

Just to follow up on this - the specified fork, at tomjaguarpaw/haskelldb, is now 2.2.3, which is not what opaleye depends on. So right now, following the instructions in the readme (on the dev branch) doesn't work - you need to either change opaleye (to take 2.2.3) or change haskelldb (to have the internal number). I'm not sure which should be changed (hence a comment, not a PR).

[tomjaguarpaw]

@dbp: README.md on the dev branch says "You should update karamaan-opaleye.cabal to depend on the version of haskelldb from that repository". Does that not work for some reason?

(Certainly this is not a good solution but I would like it to work at least!)

[tomjaguarpaw]

Having given this some more thought, I now wonder if renaming the package is the best way forward. I want the freedom to make changes that benefit Opaleye but do not necessarily benefit HaskellDB. The only downside to this is that users would not be able to use both Opaleye and the original HaskellDB in the same project (unless I renamed all the modules from Database.HaskellDB to Database.HaskellDBOpaleye, or whatever). However this is probably not a big deal because firstly I expect no one will want to do this, and secondly we'll probably keep almost complete compatibility with HaskellDB anyway.

Thoughts?

[bergmark]

We won't be using plain haskelldb!

On Wed, Aug 6, 2014 at 2:57 PM, tomjaguarpaw [email protected]
wrote:

Having given this some more thought, I now wonder if renaming the package is the best way forward. I want the freedom to make changes that benefit Opaleye but do not necessarily benefit HaskellDB. The only downside to this is that users would not be able to use both Opaleye and the original HaskellDB in the same project (unless I renamed all the modules from Database.HaskellDB to Database.HaskellDBOpaleye, or whatever). However this is probably not a big deal because firstly I expect no one will want to do this, and secondly we'll probably keep almost complete compatibility with HaskellDB anyway.

Thoughts?

Reply to this email directly or view it on GitHub:
#31 (comment)

[tomjaguarpaw]

The way to deal with this issue is to use the opaleye branch of tomjaguarpaw/haskelldb. It will always be kept up to date with what the dev branch of opaleye depends on.

https://github.com/tomjaguarpaw/haskelldb/tree/opaleye