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

[Michael Snoyman]

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?

I still maintain that new codebases should be creating freeze files (or
whatever we want to call them), and we need a community supported tool for
it. After speaking with various Haskell-based companies, I'm fairly certain
just about everyone's reinvented their own proprietary version of such a
tool.

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.

All of that said, I still think the only real solution is getting end users
off of Hackage. We need an intermediate, stabilizing layer. That's why I
started Stackage, and I believe that it's the only solution that will
ultimately make library authors and end-users happy. Everything we're
discussing now is window dressing.

My offer of cabal-timemachine was serious: I'll be happy to start that
project, and I *do* think it will solve many people's issues. I'd just like
it if it was released concurrently with cabal-freeze, so that once you
figure out the right set of packages, you can freeze them in place and
never run into these issues again.

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