qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

[Michael Snoyman]

On Tue, Feb 25, 2014 at 6:38 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> This thread is kinda missing an important point.
>
> Namely that on hackage now, the admins and trustees have the power to edit
> the cabal files to fix broken constraints. (As do maintainers of their own
> packages)
>
> Whether relaxing incorrectly conservative or over strengthening overly lax
> constraints, this now doesn't require a rerelease to "fix".  There are
> valid reasons of provinence for why that might not make sense in all case
>
> Unless I'm missing the point, doesn't that solve most of the matter?
> -carter
>
>
>
The question would still remain: who's responsible for making those
changes, and what is the default position for the version bounds? We could
default to leaving version bounds off, and add them after the fact as
necessary. This would reduce developer and Hackage maintainer overhead, but
some users may get the "scary" error messages[1]. Or we could default to
the PVP approach, and then increase the work on developers/maintainers,
with the flip side that (1) users will never get the "scary" error
messages, and (2) until developers/maintainers make the change, users may
be blocked from even attempting to compile packages together.

There's also the issue that, currently, Hackage2 has turned off developer
abilities to change version bounds, so all of the version tweaking onus
would fall to admins and trustees.

Overall, I don't see this as a big improvement over the PVP status quo.
It's not any harder for me to upload version 1.0.2.1 of a package with a
tweaked version bound than to go to the Hackage web interface and manually
edit version 1.0.2's cabal file. What I see the editing feature as very
useful for is if we want to add upper bounds after the fact.

Michael

[1] Which I still think have value, since they are far more informative to
a package author.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/a911f8d6/attachment.html>