I can no longer maintain containers

Edward Z. Yang ezyang at mit.edu
Mon Apr 4 07:14:01 UTC 2016

When I first added the reexport feature, I didn't realize that it would
have this PVP problem.  That is quite troublesome!

However, I don't think the situation is bad as suggested here:

    * It is true that you have to keep updating the shim-package,
      but it's just one shim-package release per sub-package
      release.  So it's just a constant factor increase in work.

    * The point of the shim-package is for compatibility with people who
      don't know about the subpackages.  So, for example, if you're
      paying enough attention to know that you specifically need
      containers-graph, you are also paying enough attention to
      atomize the dependencies.

So this does seem to suggest the reexport feature is mostly only good
for compatibility shims (with users encouraged to switch to not use this
shim as soon as possible) but that seems like exactly the situation
here.  But I haven't used the reexport feature in practice so I will
defer to those of you who have.  Maybe there is something we can do to
make this situation better; it does sound like Cabal should warn in
this situation (a reexport of something whose version bounds are not
tight enough).


Excerpts from Herbert Valerio Riedel's message of 2016-04-03 23:59:25 -0700:
> On 2016-04-04 at 02:09:26 +0200, David Feuer wrote:
> > Note: the containers package itself would become a dependencies-only shim,
> > perhaps under CLC maintenance.
> ...that might sound good at first, but you'd want to use Cabal 1.22+
> module-reexport feature otherwise you're forced to use PackageImports
> when you depend on both 'containers' and one of the sub-packages.
> making a shim-package 'containers' would require to have rather tight
> bounds to satisfy the PVP, because as soon as you re-export
> dependencies' modules/APIs, you get into the transitive-dependency API
> leakage problem. So at the very least you'd need to use minor-version
> bounds, as otherwise you'd violate the PVP for the containers package.
> Moreover, a containers version would still have a bit of wiggle
> room as it re-exposes an API from its own depdencenies which is only
> defined up to the patch-level. Maybe there's a problem with
> containers-graph and for some reason you need or later,
> so now you'd need to depend on both
> 'containers == 0.6.*' and 'containers-graph >= && < 0.6'
> Moreover, the shim-package 'containers' would have to have to bump its
> minor version number each time a new minor version number of one of its
> sub-packages is released, while keeping single-minor-version-range
> constraints on its sub-packages.
> TLDR: PVP & re-exporting modules/APIs quickly leads to a huge mess and
>       is therefore best avoided if possible.

More information about the Libraries mailing list