search

tomjaguarpaw / bluefin

MIT License
46 stars 6 forks source link

Why two packages instead of a public sub-library? #12

Closed michaelpj closed 2 months ago

michaelpj commented 2 months ago

I can't see a good reason not to have bluefin-internal as just a public sub-library of bluefin, unless it's actually advantageous to be able to mix-and-match versions. Which seems unlikely since AFAICT bluefin just re-exports bluefin-internal.

tomjaguarpaw commented 2 months ago

There will be times I will want to change bluefin-internal, for example to remove internals f and g and just use internal h instead (which is a generalization of both), without bumping the version of bluefin. Could I do that if bluefin-internal was a public sublibrary?

tomjaguarpaw commented 2 months ago

Similiarly, there will be times I will want to change bluefin (say to expose something previously not exposed) and therefore bump bluefin without bumping bluefin-internal.

michaelpj commented 2 months ago

Hmmm. Yes okay, if you want to a) expose bluefin-internal fully, b) version bluefin-internal fully following the PVP, c) not bump frequently; then I guess you do want to mix-and-match versions, which means you need two packages.

Personally I would probably just eat the costs, and either not expose bluefin-internal until it has settled down a bit, or just accept more major version bumps, but preferences differ.

tomjaguarpaw commented 2 months ago

Yes, this was my ultimate conclusion here: https://discourse.haskell.org/t/pvp-compliance-of-internal-modules/6784/7?u=tomjaguarpaw