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

[MightyByte]

On Wed, Feb 26, 2014 at 4:56 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
> On Wed, Feb 26, 2014 at 10:36 AM, John Lato <jwlato at gmail.com> wrote:
>>
>> I had understood people talking about "legacy projects" to mean something
>> other than how you read it.  In which case, I would suggest that there is a
>> third use case, which IMHO is more important than either of the use cases
>> you have identified.  Here's an example:
>>
>> 1.  package foo-0.1 appears on hackage
>> 2.  package bar-0.1 appears on hackage with a dependency on foo >= 0.1
>> 3.  awesomeApp-0.1 appears on hackage, which depends on bar-0.1 and
>> text>=1.0
>> 4.  users install awesomeApp
>> 5.  package foo-0.2 appears on hackage, with lots of breaking changes
>> 6.  awesomeApp users notice that it sometimes breaks with Hungarian
>> characters, and the problem is traced to an error in text
>> 6.  text-1.0.0.1 is released with some bug fixes
>> 7.  awesomeApp users attempt to do cabal update; cabal install, which
>> fails inscrutably (because it tries to mix foo-0.2 with bar-0.1)
>>

There's another simpler example here where foo-0.2 breaks something and
because bar has no upper bound, awesomeApp's build spontaneously fails.  I
don't think it's reasonable to require that package authors specify dependency
bounds for the transitive closure of things they depend on.  That's
unintuitive and it doesn't scale well as the number of packages and average
number of dependencies in a single package increases.  The solver needs to
know that foo-0.2 is not known to work with bar.  We should not throw away
that information.  I've already encountered several cases complex enough that
cabal could not find a solution even though some existed.  We need to bound
this problem with as many tools as we can.

>
> IIUC, this is *exactly* the case of an unmaintained package. I'm not
> advocating leaving a package like bar-0.1 on Hackage without an upper bound
> on foo, if it's known that it breaks in that case. In order for the package
> to be properly maintained, the maintainer would have to (1) make bar work
> with foo-0.2, or (2) add an upper bound. So to me, this falls squarely into
> the category of unmaintained.

Calling that an unmaintained package is intellectually dishonest.  Any
reasonable definition of "unmaintained" will acknowledge that there will
always exist some nonzero amount of time between the time foo is updated and
the time bar and awesomeApp can be fixed without claiming that they are
unmaintained.  This is a fact of the reality we live in.  I strongly believe
that packages should not break spontaneously because of the actions of others.

> If package maintainers are not going to be responsive to updates in the
> Hackage ecosystem, then I agree that they should use the PVP. I also think
> they should advertise their packages as not being actively maintained, and
> people should try to avoid using them if possible. But if an author is
> giving quick updates to packages, I don't see a huge benefit to the PVP for
> users, and instead see some downsides (inability to test against newer
> dependencies), not to mention the much higher maintenance burden for library
> authors.

I'm sorry, but this is completely ridiculous.  There are life situations that
happen that preclude package updates.  And that doesn't mean that the package
is unmaintained.

Here's the other side of the story.  A large majority of snap's breakages have
been caused by dependencies that don't supply upper bounds such as
clientsession, cipher-aes, http-conduit, etc.  In fact, we switched from
http-conduit to http-streams precisely because of this problem.

If package maintainers are not going to be responsible and put proper upper
bounds for all their dependencies, then I think they should advertise their
packages as chronically unstable and likely to break anyone else that uses
them at a moment's notice.  People should avoid using them if possible.

The downsides that you're claiming aren't the fault of the PVP.  They are a
deficiency in our tooling, and fully locking down the transitive closure is
not a good solution.  What we need is a way to differentiate known bad upper
bounds from unverified upper bounds.  It could be something as simple as
allowing <! and < in the cabal file.  Then making the solver aware of this
distinction, so it can search the dependency graph in a more informed manner.

> That's what I'm disagreeing with. I do not believe that, overall, the PVP is
> giving users a better experience. I've had a huge downturn in reported
> errors with Yesod since I stopped strictly following the PVP. It's
> anecdotal, but everything in this thread is really anecdotal.

I suspect that the root cause for you holding tihs position is that you happen
to be operating in a relatively self-contained corner of the package space and
don't often depend on fast-moving packages that aren't under your control.