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

[Gregory Collins]

On Tue, Feb 25, 2014 at 1:16 PM, Vincent Hanquez <tab at snarc.org> wrote:

> On 2014-02-25 19:23, Gregory Collins wrote:
>
>>
>> That's because you maintain a lot of packages, and you're considering
>> buildability on short time frames (i.e. you mostly care about "does all the
>> latest stuff build right now?"). The consequences of violating the PVP are
>> that as a piece of code ages, the probability that it still builds goes to
>> *zero*, even if you go and dig out the old GHC version that you were using
>> at the time. I find this really unacceptable, and believe that people who
>> are choosing not to be compliant with the policy are BREAKING HACKAGE and
>> making life harder for everyone by trading convenience now for guaranteed
>> pain later. In fact, in my opinion the server ought to be machine-checking
>> PVP compliance and refusing to accept packages that don't obey the policy.
>>
> If you're going to dig an old ghc version, what's stopping you from
> downloading old packages manually from hackage ? I'm sure it can even be
> automated (more or less).
>

The solver can't help you here. Like I wrote in my last message to Michael:
if I depend on foo-1.2, and foo-1.2 depends on "bar", and "bar-2.0" comes
out that breaks "foo-1.2", what can I do? I have to binary search the
transitive closure of the dependency space because the solver cannot help.

However, I don't think we should optimise for this use case; I'ld rather
> use maintained packages that are regularly updated. And even if I wanted to
> use an old package, provided it's not tied to something fairly internals
> like GHC's api or such, in a language like haskell, porting to recent
> version of libraries should be easier than in most other language.
>
> Furthermore, some old libraries should not be used anymore. Consider old
> libraries that have security issues for example. Whilst it's not the
> intent, It's probably a good thing that those old libraries don't build
> anymore, and people are forced to move to the latest maintained version.
>
> The PvP at it stand seems to be a refuge for fossilised packages.


I care much more about programs than about libraries here. Most Haskell
programs that were ever written never made it to Hackage. I don't
understand the point about old libraries: people will stop using libraries
that aren't updated by their maintainers, or someone else will take them
over.

 Like Ed said, this is pretty cut and dried: we have a policy, you're
>> choosing not to follow it, you're not in compliance, you're breaking stuff.
>> We can have a discussion about changing the policy (and this has definitely
>> been discussed to death before), but I don't think your side has the
>> required consensus/votes needed to change the policy. As such, I really
>> wish that you would reconsider your stance here.
>>
>
> "we have a policy".
>
> *ouch*, I'm sorry, but I find those biggoted views damaging in a nice
> inclusive haskell community (as I like to view it).
>

I don't see what bigotry or inclusiveness has to do with this. This is a
conversation between insiders anyways :)

While we may have different opinions, I think we're all trying our best to
> contribute to the haskell ecosystem the way we see fit.


Of course, nobody's saying otherwise. People arguing for the omission of
upper bounds often point to breakage caused by the PVP -- I just want to
make it clear that people who ignore PVP cause breakage too, and this
breakage is worse (because it affects end users instead of Haskell nerds,
who know how to fix it). See e.g.
https://github.com/snapframework/cufp2011/issues/4 for an instance where
one of your packages broke a program of mine for no reason. This program
would have continued building fine basically forever if you'd followed the
PVP.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/9d812365/attachment.html>