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

[Michael Snoyman]

On Wed, Feb 26, 2014 at 8:03 AM, John Lato <jwlato at gmail.com> wrote:

> On Tue, Feb 25, 2014 at 9:25 PM, Michael Snoyman <michael at snoyman.com>wrote:
>
>>
>>
>> On Wed, Feb 26, 2014 at 1:28 AM, MightyByte <mightybyte at gmail.com> wrote:
>>
>>> On Tue, Feb 25, 2014 at 4:51 PM, Vincent Hanquez <tab at snarc.org> wrote:
>>> >
>>> > I'm not saying this is not painful, but i've done it in the past, and
>>> using
>>> > dichotomy and educated guesses (for example not using libraries
>>> released
>>> > after a certain date), you converge pretty quickly on a solution.
>>> >
>>> > But the bottom line is that it's not the common use case. I rarely
>>> have to
>>> > dig old unused code.
>>>
>>> And I have code that I would like to have working today, but it's too
>>> expensive to go through this process.  The code has significant value
>>> to me and other people, but not enough to justify the large cost of
>>> getting it working again.
>>>
>>>
>>
>> I think we need to make these cases more concrete to have a meaningful
>> discussion. Between Doug and Gregory, I'm understanding two different use
>> cases:
>>
>> 1. Existing, legacy code, built again some historical version of Hackage,
>> without information on the exact versions of all deep dependencies.
>> 2. Someone starting a new project who wants to use an older version of a
>> package on Hackage.
>>
>> If I've missed a use case, please describe it.
>>
>> For (1), let's start with the time machine game: *if* everyone had been
>> using the PVP, then theoretically this wouldn't have happened. And *if* the
>> developers had followed proper practice and documented their complete build
>> environment, then PVP compliance would be irrelevant. So if we could go
>> back in time and twist people's arms, no problems would exist. Hurray,
>> we've established that 20/20 hindsight is very nice :).
>>
>> But what can be done today? Actually, I think the solution is a very
>> simple tool, and I'll be happy to write it if people want:
>> cabal-timemachine. It takes a timestamp, and then deletes all cabal files
>> from our 00-index.tar file that represent packages uploaded after that
>> date. Assuming you know the last date of a successful build, it should be
>> trivial to get a build going again. And if you *don't* know the date, you
>> can bisect until you get a working build. (For that matter, the tool could
>> even *include* a bisecter in it.) Can anyone picture a scenario where this
>> wouldn't solve the problem even better than PVP compliance?
>>
>
> This scenario is never better than PVP compliance.  First of all, the user
> may want some packages that are newer than the timestamp, which this
> wouldn't support.  As people have already mentioned, it's entirely possible
> for valid install graphs to exist that cabal will fail to find if it
> doesn't have upper bound information available, because it finds other
> *invalid* graphs.
>
> And even aside from that issue, this would push the work of making sure
> that a library is compatible with its dependencies onto the library
> *users*, instead of the developer, where it rightfully belongs (and your
> proposal ends up pushing even more work onto users!).
>
> Why do you think it's acceptable for users to do the testing to make sure
> that your code works with other packages that your code requires?
>

You're not at all addressing the case I described. The case was a legacy
project that someone is trying to rebuild. I'm not talking about any other
case in this scenario. To repeat myself:

> 1. Existing, legacy code, built again some historical version of Hackage,
without information on the exact versions of all deep dependencies.

In *that specific case*, why wouldn't having a tool to go back in time and
build against a historical version of Hackage be *exactly* what you'd need
to rebuild the project?


>
>> For (2), talking about older versions of a package is not relevant. I
>> actively maintain a number of my older package releases, as I'm sure others
>> do as well. The issue isn't about *age* of a package, but about
>> *maintenance* of a package. And we simply shouldn't be encouraging users to
>> start off with an unmaintained version of a package. This is a completely
>> separate discussion from the legacy code base, where- despite the valid
>> security and bug concerns Vincent raised- it's likely not worth updating to
>> the latest and greatest.
>>
>
> Usually the case is not that somebody *wants* to use an older version of
> package 'foo', it's that they're using some package 'bar' which hasn't yet
> been updated to be compatible with the latest 'foo'.  There are all sorts
> of reasons this may happen, including big API shifts (e.g. parsec2/parsec3,
> openGL), poor timing in a maintenance cycle, and the usual worldly
> distractions.  But if packages have upper bounds, the user can 'cabal
> install', get a coherent package graph, and begin working.  At the very
> worst, cabal will give them a clear lead as to what needs to be updated/who
> to ping.  This is much better than the situation with no upper bounds,
> where a 'cabal install' may fail miserably or even put together code that
> produces garbage.
>
> And again, it's the library *user* who ends up having to deal with these
> problems.  Upper bounds lead to a better user experience.
>

I disagree with that assertion. I get plenty of complaints from users about
trying to install packages and getting "confusing error messages" about
cabal plan mismatches. I don't disagree that the PVP does make the user
experience better in some cases. What I disagree with is the implication
that it makes the user experience better in *all* cases. This is simply not
a black-and-white issue.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/3b210322/attachment-0001.html>