Split UUID data type out into separate Cabal package

[BardurArantsson]

(STATUS: GOOD TO GO . See latest comment)

It includes a few of the commits from my "Cleanups" pull request (which should hopefully be uncontroversial), just as a matter of convenience. The diff might be easier to scan if you choose to merge that pull request first.

Anyway, this represents the initial stab at splitting the data type definitions from the UUID-generation code.

The gist of the changes is:

• I've create a new Data.UUID.Types module name space for the split-out data definitions.
• I've moved Builder to Data.UUID.Types.Internal. Since Builder wasn't being exported anyway this should not break API-compatibility.
• I've copied Data.UUID.UUID to Data.UUID.Types.UUID and changed the "new" Data.UUID.UUID to just reexport Data.UUID.Types.UUID. This should also preserve API-compatibility.
• I changed the name used for uuidType, but I'm not exactly sure if this is the right thing to do since the comment is a big cryptic. AFAIAA this shouldn't break anything unless these things have been serialized.
• To break the dependency between Data.UUID.Internal and Data.Word.Util, I've moved a function from the latter to the former. (Commit 12641b7.) I think it would make sense to cherry-pick this commit as-is at the current time.

What remains:

Splitting out tests/benchmarks which are relevant to Data.UUID.Types into their own separate tests. To be certain that this is done correctly, I'd like to start actually splitting things into separate .cabal files, so I need to know how you'd like the code organized -- in two separate git repositories or in two separate directories in a single repository? (As mentioned by e-mail, I think I'd prefer the latter since it's much easier to co-evolve code that way.)

I'd also like to get rid of the binary dependency from Data.UUID.Types, but I don't see any good way of doing it which doesn't require orphan instances. Any ideas? (I think I would propose just living with orphan instances and adding them directly to Data.UUID.UUID.) This isn't an insurmountable problem for my use case, but "binary" also drags in "containers", and I don't see any particular reason to give "binary" privileged status over other serialization approaches. (Interestingly, "binary" also doesn't appear to be in the Haskell Platform, so there's that.)

Any and all comments welcome :).

[BardurArantsson]

Hum, I see that the diff wasn't updated -- I'll just do a quick force push to force github to update the diff.

[BardurArantsson]

There we go. Diff looks a lot saner now :).

[BardurArantsson]

I gather there are no strong opinions on how to proceed? I think I'll try to do the two-packages-in-single-repository approach. (It can always be split out later. I had feared that the github diffs would be mangled by renames, but that doesn't appear to be the case.)

I'd also like ideas on the binary instance. (I'll obviously keep it in the uuid-types package initially.) I guess one valid approach might be to actually have uuid wrap the type exported by uuid-types in its own newtype, but that seems a bit icky...

[BardurArantsson]

OK, so here are the fully split packages. Notes:

• I split the benchmark such that the "generation" benchmarks are all in uuid even though one of them could theoretically be in uuid-types, it seemed like a better idea to keep them together. The rest are in uuid-types since they don't depend on anything else.
• Split tests "right down the middle" such that all tests only requiring uuid-types are done in that package and the remaining tests are done in uuid.
• Took the liberty of adding myself to CONTRIBUTORS.
• Tried to minimize dependencies in each of the two new .cabal files.

What remains:

• Travis configuration to build both packages properly. I'm not familiar with travis, but I found a blog post with instructions for multi-project builds, so I should be able to set this up. I'll look at that tomorrow.
• README.md needs updating (EDIT: Actually, I'm not sure it actually does.)
• the .gitignore file may need a little tidying. (Perhaps we should just have individual .gitignore files in each of the two subdirectories?)

[BardurArantsson]

Btw, gitk is a better at showing the diffs since it also detects "copy + modify", which I'm not sure github does.

[aslatter]

To answer many of your questions/concerns/&c.:

• Keeping the benchmarks together is fine. Running benchmarks is a developer exercise, and I expect both packages to be developed in concert.
• For the tests - I can go either way, split or not split. I think what you did was fine.
• I'm okay merging without perfect README and .gitignore files.
• I'd prefer keeping the binary instance non-orphan. It's true that it privileges one serialization library over the other (binary vs. cereal), but I think it's better than dropping the instance or leaving it orphan. There was supposedly work on unifying binary and cereal but I don't know what ever happened with that.

At some point I'll add big, scary warnings to Type.Internal telling folks not to use it, and also mark it "not home" for Haddocks, but that's also something I can merge without having up front.

[BardurArantsson]

OK, thanks for the commentary :). I'll try to get Travis working and we'll see where we stand. (Almost everything else can at the very least be deferred to later.)

[BardurArantsson]

OK, so I think I have the more-or-less the final version now. See the commit comment for e180cfe + diff (best viewed in gitk) for the final set of notes.

AFAICT this hasn't broken API compatibility, so I chose to bump "uuid" to 1.3.9. Perhaps we should be conservative about it and bump to 2.0.0, I'm not sure.

I did a few experiments with Travis, and arrived at the current solution as the most CPU-efficient. There's another option where more things are parallelized (via sandboxing and parallel builds for each of the two packages and "env:" in the Travis config), but in practice it seemed a lot slower, probably due to repeated downloading/compilation -- I think this is something we can revisit later if need be.

Let me know if there's anything that needs to be changed before merge... assuming the Travis build succeeds :)

[BardurArantsson]

Hum, playing around with using this from a different project, it strikes me that Data.UUID.Types.UUID for the main module in uuid-types looks a bit silly for a module name. I think I'll change it to Data.UUID.Types, so please hold off on merging for now. I'll probably get to this in a day or two.

[aslatter]

That seems reasonable to me.

[BardurArantsson]

Done.

[BardurArantsson]

Any remaining issues to you want taken care of before merging?

[aslatter]

Sorry for the delay on the merge! Everything looks okay, and the generated docs look good, too.

[BardurArantsson]

Great, thanks!