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

On Wed, Feb 26, 2014 at 4:56 AM, Michael Snoyman wrote:

On Wed, Feb 26, 2014 at 10:36 AM, John Lato 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

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.