[leftaroundabout]

The crypton package has switched from memory to its fork ram. yesod-static still imported Data.ByteArray from memory though, leading to a confusing error about a missing instance of ByteArrayAccess (Digest MD5), because ByteArrayAccess came from memory but crypton only defines an instance of the ram version of ByteArrayAccess.

Note: I haven't checked the ram package very closely to see whether the switch is actually a good idea. An alternative would be to define the instances elsewhere. But the argument of ram is that memory is now unsupported, so switching to another package is perhaps unavoidable in the long term.

Haven't bumped any versions or changelog, not sure that's applicable for a change like this?

[peti]

You might want to allow ram 0.22 here. The build works fine and that version is required to support the latest tls package.

[leftaroundabout]

Right.

[parsonsmatt]

Thanks, this looks good to me. Do you mind bumping the patch version here for yesod-static? I'll get a release out shortly.

[leftaroundabout]

@parsonsmatt I rebased on master (2223392, as of Monday) and set the version to 1.6.1.4, is that what you meant?

[parsonsmatt]

sounds great thanks! I'll release today once CI is green

[leftaroundabout]

Presumably ram would need to be added also to stack-lts-22.yaml. Is that the right procedure? I don't use Stack myself.

[juhp]

I think the testsuite needs fixes too.

[juhp]

Also please rename the issue to include "yesod-static"

[leftaroundabout]

@juhp ok.

I don't know what's the right procedure for the lts-23 builds, though.

[juhp]

@juhp ok.

I don't know what's the right procedure for the lts-23 builds, though.

Do you mean lts-24 or just crypton-1.0 in general?

crypton-1.1 should land in the next Stackage Nightly snapshot hopefully.

[leftaroundabout]

@juhp I mean the build with --resolver lts-23, which failed because it does not use stack-lts-22.yaml where all the extra-deps are specified, and thus doesn't have access to ram which is neither in lts-23 nor lts-24.

I see ram is now in Stackage Nightly, so it presumably shouldn't be a permanent extra-dep. Should there be an additional stack-lts-24.yaml, should the 22 version be renamed, or something different entirely?

[juhp]

Ah right, I think for now it might be enough to replace extra-deps: [] in stack.yaml with

extra-deps:
- ram-0.22.0

though it wouldn't hurt to update stack.yaml to lts-24 at some point.

(In principle we could add ram to lts-24, I am slightly divided on that though.)

[juhp]

(An alternative could be to jump stack.yaml to nightly for now)

[L0neGamer]

Is the intention to fix previous versions of yesod-static as well? If the bounds aren't well-defined, previous versions of yesod-static may be solved for and then fail in compilation.

[sternenseemann]

Why aren't you removing the dependency on memory? Seems like it is not necessary with crypton >= 1.1 at all, so probably an automatic Cabal flag should be used that switches between crypton >= 1.1, ram and crypton < 1.1, memory.

[leftaroundabout]

@sternenseemann I agree that's the proper thing to do, yes. I didn't do it because in the past I found such cabal-flag configuration a bit risky - works in principle fine, but would require careful testing with a bunch of different configurations. Certainly doable, but I didn't even know whether depending on ram would be considered a good idea at all. And, as I said I'm not really familiar with Stack-based workflows. It could be argued that it's more sensible to just purge memory entirely, require crypton >= 1.1 and depend on ram unconditionally.

[simonmichael]

Is this PR finished ? @parsonsmatt, perhaps it's time for a release ?

[simonmichael]

AI analysis of the situation:

The fix is written and approved

#1916 does the right thing, and @parsonsmatt approved it back on June 24 with "I'll release today once CI is green". The catch is that CI never ran: statusCheckRollup is empty on the head commit (23f8d63, June 29). It's a fork PR, so it's sitting behind the "Approve and run workflows" button. So the blocker isn't really CI, it's someone clicking that.

One line is still missing

#1916 makes ram an unconditional dependency, so every CI leg needs it resolvable. It was added to stack-lts-22.yaml but not to stack.yaml, which is what the --resolver lts-23 leg uses, and ram isn't in lts-23 or lts-24. @juhp already suggested this in July:

--- a/stack.yaml
+++ b/stack.yaml
-extra-deps: []
+extra-deps:
+- ram-0.22.0

ram-0.22.0 looks fine on the older legs, for what it's worth: cabal-version: 3.0, base <4.23 with no lower bound, and only bytestring/deepseq/ghc-prim as deps. Also note that all five legs resolve crypton 1.0.x, so CI never exercises the crypton-1.1 path anyway; it just needs to not break.

On the cabal flag suggestion

@sternenseemann's automatic-flag idea is nicer in principle and would drop the extra-dep entirely, but I don't think it should hold this up: Stack doesn't backtrack on automatic flags, it just takes the default, so default: True breaks the lts-16..23 legs and default: False would break a nightly leg. Seems better to merge #1916 as-is and revisit later.

Separately: a Hackage revision would unblock everyone today

Regardless of when the release happens, revising yesod-static 1.6.1.3 (and earlier) to crypton < 1.1 on Hackage would fix downstream solvers immediately, which is what @peti needs for openSUSE and what @simonmichael needs for hledger.