Support persistent-2.14

[parsonsmatt]

This PR provides support for persistent-2.14 by CPPing in a GraphulaSafeToInsert type that is either an alias for SafeToInsert or const () :: Constraint.

Fixes #65

[parsonsmatt]

this is how i tested, can definitely back out

[pbrisbin]

IIUC, persistent-2.14 has landed in nightly (we got a notification about it breaking us), so the stack-nightly.yaml file should be a good test (and is run on CI).

[parsonsmatt]

so, technically, this is a change to the signature of the function, which is a breaking change

but also technically, it's only a breaking change if persistent itself is updated to 2.14. Otherwise this evaluates out to a () and should discharge

I can also do another approach where I CPP this in at each use-site, which will prevent the API from changing for users unless they are on persistent-2.14 anyway.

[pbrisbin]

I'm personally OK with us only doing a minor bump ourselves given this nuance. Curious what other Frecklers thing.

I don't think peppering the CPP around is worthwhile. I think we can either bend the rules or just do a major bump.

[mjgpy3]

Looks good to me! I'm gonna bring in @pbrisbin for the stack.yaml question.

[pbrisbin]

If I'm correct about this being exercised via stack-nightly.yaml, then I would indeed back out the stack.yaml change.

In other projects (e.g. yesod-auth-oauth) I've actually made a special stack-{dependency}-{version}.yaml and added it to the matrix, if I'm looking to "test ahead". So I might consider that if I'm not correct about how this is playing out in nightly.

Either way, not a big deal.

[pbrisbin]

I'm personally OK with us only doing a minor bump ourselves given this nuance. Curious what other Frecklers thing.

I don't think peppering the CPP around is worthwhile. I think we can either bend the rules or just do a major bump.

[parsonsmatt]

Hmm, GHC 8.6.5 and below don't support type A a = Eq a :: Constraint syntax.

[pbrisbin]

Ugh, I'm actually not a fan of this "Approve and run" stuff. Sorry for the delay, I'm back from PTO now, so will be more responsive.

[pbrisbin]

Well that's an interesting failure to only get in one resolver 🤔 is that a new (or improved) warning?

I don't mind disabling it as workaround -- I find the README.lhs specs can sometimes need that because the tricks needed to make the nice README can be not-great Haskell.

[parsonsmatt]

It may also be a problem with how persistent-2.14 is generating code, too.

[parsonsmatt]

Anything I can do to help move this forward?

[pbrisbin]

Sorry I lost track of this. I think we were waiting on you fixing the stack-nightly build-error; perhaps by disabling a warning by pragma in the README.lhs? The log has expired so I'm just going by my previous comment.

[parsonsmatt]

I think it will be very inefficient for me to fix a CI problem since I need manual approval for each CI run. Is there an easy way for me to test that locally?

[pbrisbin]

I think it will be very inefficient for me to fix a CI problem since I need manual approval for each CI run

I thought I only had to approve a PR/contributor once. It's every time? Sigh.

Is there an easy way for me to test that locally?

As far as I can tell, CI just runs stack --resolver nightly --stack-yaml stack-nightly.yaml build --fast --pedantic --test. Does that reproduce the error for you?

[parsonsmatt]

Hmm. brittany fails in the presence of CPP so restyled isn't going to work 🤔

[pbrisbin]

Restyled is not a Required Status, so all good there.

[pbrisbin]

Thanks!