snap fails to install with upcoming aeson due to ByteString no longer a valid FromJSON

[ibotty]

Aeson recently dropped FromJSON ByteString instances (out of good reasons. see bos/aeson#126 (https://github.com/bos/aeson/issues/126)).

the following error is generated.

src/Snap/Snaplet/Auth/Types.hs:322:21:
    No instance for (ToJSON ByteString)
      arising from a use of `toJSON'
    Possible fix: add an instance declaration for (ToJSON ByteString)
    In the expression: toJSON x
    In an equation for `toJSON': toJSON (Role x) = toJSON x
    In the instance declaration for `ToJSON Role'

src/Snap/Snaplet/Auth/Types.hs:327:27:
    No instance for (FromJSON ByteString)
      arising from a use of `parseJSON'
    Possible fix: add an instance declaration for (FromJSON ByteString)
    In the second argument of `(.)', namely `parseJSON'
    In the expression: fmap Role . parseJSON
    In an equation for `parseJSON': parseJSON = fmap Role . parseJSON

I am pretty new in going through snap's internals, so please bear with my superficial investigation.

Role is only the tip of the iceberg though. There are quiet a few ByteStrings that want to get serialized to/from JSON. I expect that the following list is non-exhaustive, because I only looked at Snap (not all other Snap packages).

• Role can be fixed with type Text,
• Password seems to always be valid Utf8, so a Data.Text.Encoding.encodeUtf8 seem to suffice,
• userCurrentLoginIp, usrLastLoginIp can also be fixed with a few encodeUtf8, but it might be worthwhile to use a real IP type. (that would change quiet a few things I suppose)

see ibotty@a1800ed249d993fc172bb2ad9bc0073c5ed1379f for my attempt to fix this problem.

[mightybyte]

It fails to install because these aeson changes need to be released as aeson-0.7 to conform with the PVP. We will have to change eventually, so thanks for bringing this up. I think we may need to consider rethinking some of our approach.

[ozataman]

I think in general JSON is a bad way to store backend data; we shouldn't be using it as the out-of-the-box user store. (Yes I know that I was the one who designed/implemented the current JSON backend ;-) ) If nothing else, JSON's rejection of binary (non-utf8) data precludes it from being an arbitrary store of data.

I propose the following:

• Drop the roles field from snap's auth at least for now, as we are not any closer than 2 years ago to actually having a role system in place out of the box. If we ever get it, it might in any case be better to store the relevant data in a separate table, independent of the base auth system, but of course building on the auth system's AuthUser type.
• Switch to sqlite (and snaplet-sqlite) as the most lightweight backend for user auth with snap. This is what many other frameworks like Rails does. Point this out on the blog/docs/etc. If this is not lightweight enough, we can alternatively switch from JSON to SafeCopy (and probably acid-state).
• Spin off the json backend to a separate package (snap-auth-json or something like that) for backwards compatibility. I doubt anyone is actually using it for anything beyond toy mockups. Convert the needed fields to Text, which shouldn't break anything.

[ibotty]

just to make that clear, because i mixed versions up (my cabal copy was too old). aeson 0.6.2 is already released and does not contain that change. it is upcoming but it won't be 0.6.2, but 0.7 or whatever bryan o'sullivan decides.

[mightybyte]

@ibotty Correct. The PVP describes how version numbers should be bumped when releasing new versions. The first of the three rules says "If...instances were added or removed, then the new A.B must be greater than the previous A.B." If Bryan conforms to this rule, then the change in question will have to be released with at least version 0.7, and that falls outside the bounds currently accepted by snap.

However, this didn't have anything to do with your cabal copy being too old. It happened because Bryan hasn't bumped the version yet in aeson. In my projects, I usually try to make an appropriate version bump as soon as I make a change that needs it. That way, you would not have encountered the build error because aeson would already be at version 0.7 in the master branch (snap just would have used 0.6). But that's just my personal preference. Bryan may have his own established process for version bumps.