Split up into point-free-{lib,doc,test} packages and reduce dependencies

[lexi-lambda]

This PR breaks up point-free into the usual package split, removes the dependency on cover altogether, and adjusts the library to use racket/base instead of racket to make it more lightweight.

With these changes, point-free-lib still has a build dependency on rackunit-lib because you seem to like to use inline tests using module+, so I decided not to break those out into separate modules. Otherwise, though, point-free-lib is now dependency-free.

Obviously, if you want to merge this PR, it will require some work on your end to update the package information on http://pkgs.racket-lang.org to add the new packages and reflect the new structure. However, once that’s done, it will be backwards compatible with existing users, since they will just depend on the point-free superpackage.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling 6242b60 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a282e89 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a282e89 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a282e89 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a282e89 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a282e89 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a282e89 on lexi-lambda:package-split into 5612552 on jackfirth:master.

[coveralls]

Coverage increased (+58.002%) to 98.148% when pulling a359b0a on lexi-lambda:package-split into 5612552 on jackfirth:master.

[AlexKnauth]

Is the -doc package necessary or can that code just be put in the main point-free package?

[lexi-lambda]

It could probably theoretically combined into one package but the package in the main distribution all use a separate -doc package by convention.

[jackfirth]

I'm not sure a split is necessary, as the built package server means installing with --binary-lib on the latest released Racket version avoids installing anything in build-deps. I'd rather see more work in Racket's package system for build servers in multiple racket versions, instead of more packages splitting up into -lib -doc and -test packages. However, if there's a specific need by a specific client package to avoid the build dependencies on older racket versions I'd find this reasonable.

[lexi-lambda]

I started typing out my feelings about installing build-deps via binaries being not well enough supported in certain configurations and not being good enough for me in those situations, but I think maybe we would disagree about that somewhat, so I should cut to the chase.

I don’t use much in point-free aside from ~>, so if you don’t want to split the package up to avoid these dependencies, I will stop depending on point-free and reimplement ~> in each package where I need it to keep my dependencies light. I don’t personally have any problem with doing that, so if you want to keep things the same, I’ll take that route. I just figured I’d offer to do the work to split the package up for you first.

[jackfirth]

I agree that binary installations aren't currently well supported in all configurations, but I think that's something that should / will change in the future. I don't have an interest in maintaining split packages. Instead I'd like to invest effort in removing the need for split packages for most users and use cases. I've opened #16 for making sure point-free's runtime dependencies only include base, which is the direction I'd like to pursue.

Maybe a point-free-thrush package that contains just the thrush combinator forms and no docs would suffice? That's a useful semantic split in my opinion, as those features are used vastly more often than everything else in point-free.

[lexi-lambda]

I agree that binary installations aren't currently well supported in all configurations, but I think that's something that should / will change in the future. I don't have an interest in maintaining split packages.

Alright. I’ll be willing to collapse my packages if/when that support improves, but in the meantime I feel like I have a responsibility to keep my dependencies light.

Maybe a point-free-thrush package that contains just the thrush combinator forms and no docs would suffice?

Eh, I think that sort of thing should be avoided. At that point, why not split your package? I don’t think having packages like left-pad is a good thing to emulate.