'temporary' package

[Anthony Cowley]

> On May 10, 2014, at 5:10 PM, João Cristóvão <jmacristovao at gmail.com> wrote:
> 
> > It might be good to also mention a user's options for using their own fork of a package ...
> 
> I was going to say: perhaps an Wiki entry stating what to do in case the build fails, but of course, it turns out there is one already:
> 
> http://www.haskell.org/haskellwiki/Cabal/Survival
> 
> I would only add two steps:
> 1a) If the package has a github repository, check out if someone else already forked it (on github, not hackage) and check it out as a temporary solution or
> 1b) Do "cabal get -s package", and fix the package yourself, and...
> 2) with the use of cabal sandboxes, namely the "cabal sandbox add-source", the problem is easily solved.
> 
> I apply this most of the times I detect a package problem in parallel with notifying the author, and it has suited me well.
> Perhaps its just a case of forwarding the users to this page?
> 
> Cheers

First, I am completely against this 2 or 4 day turnaround time demand before taking over a package. Version bump uploads by a trustee are fine, but taking over a package should be a matter of months, not days.

I also agree with what João says here, and do the same myself. The one place this breaks down is when you want to push your package to hackage. In that case, you need a way of specifying a dependency that will allow your package to work until the upstream breakage is fixed by a maintainer. I can think of two options, both of which need some tooling help to be palatable, but maybe now is a good time for straw men.

One: depend upon a repository rather than a package on hackage. You can list a tag on your github fork of an upstream package as a dependency until a new version is pushed to hackage. I don't think this works now, and it opens a can of worms about supported version control systems, archival availability of those repositories, and overall duplicates some amount of the decision making that already goes into hackage.

Two: push a fork to hackage, but make it easier for a package author to hide (maybe eventually delete) a package from the hackage listing. We don't want to crush the package name space with every name suffixed with every developer's initials, but such a package can play a useful transitional role. This role's usefulness comes to an end when a maintainer upload is made, at which point one could prune the temporary name from the hackage listing. This hiding should be transitive, so the versions of my package that depended upon this temporary package would also be hidden, but the limited timeframe of these fixes should limit the impact.

I prefer option two, but it perhaps suggests a more pressing need for different ways of listing or searching hackage. Perhaps having a tag or category for temporary or personal forks that aren't included on the main list would meet this need.

Thoughts?

Anthony


> 2014-05-10 21:49 GMT+01:00 <amindfv at gmail.com>:
>> It might be good to also mention a user's options for using their own fork of a package while waiting for an update on hackage. Part of peoples' frustration seems to be coming from a feeling that they're blocked on waiting for the package to be updated.
>> 
>> Tom
>> 
>> 
>>> El May 10, 2014, a las 15:35, Carter Schonwald <carter.schonwald at gmail.com> escribió:
>>> 
>>> Let's update that policy with your and Edwards remarks?
>>> 
>>>> On Saturday, May 10, 2014, Erik Hesselink <hesselink at gmail.com> wrote:
>>>> On Sat, May 10, 2014 at 8:11 PM, Gershom Bazerman <gershomb at gmail.com> wrote:
>>>> > I understand that Max did a bunch of very important work, then became
>>>> > occupied with other things in the world. And in the long term, that needs to
>>>> > be sorted out. But in the short term, a four-day-notice policy is silly. And
>>>> > furthermore, even though there's nothing _wrong_ with forking promiscuously,
>>>> > it tends to create a mess, to no good end.
>>>> 
>>>> Just a small note since this was mentioned a couple of times: as
>>>> hackage admins we don't have a 'four-day-notice policy'. The package
>>>> takeover procedure [0] just says 'a while', and we've taken this to
>>>> mean at least 2-3 weeks to account for vacations, other absences,
>>>> general busyness etc.
>>>> 
>>>> Erik
>>>> 
>>>> [0] http://www.haskell.org/haskellwiki/Taking_over_a_package
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140510/a8656b20/attachment-0001.html>