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

[Carter Schonwald]

cool, so is docmunch going to allocate some money or manpower to help out?
:)


On Thu, Feb 27, 2014 at 3:36 PM, Greg Weber <greg at gregweber.info> wrote:

>
>
>
> On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp <austin at well-typed.com>wrote:
>
>> Hi Greg,
>>
>> On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber <greg at gregweber.info> wrote:
>> > I actually think work on the a) cabal solver has been a distraction from
>> > more pressing issues: the need for sandboxes (that is done now) and
>> > reproducible builds (frozen dependencies). If you look at Ruby's
>> Bundler,
>> > which has been extremely successful, it has historically (maybe they
>> have a
>> > better solver now) been a dumb tool in terms of its solver that works
>> > extremely well. I think 90+% of this conversation is pretty wasteful,
>> > because once we have reproducible builds everything is going to change.
>> If
>> > the energy could be re-directed to being able to create reproducible
>> builds
>> > in Haskell, then we could figure out what the next most important
>> priority
>> > is.
>>
>> I'd like to carefully point out however, that it is not a zero-sum
>> game - work dedicated to improving the constraint solver is not work
>> which is implicitly taken away any other set of tools - like a
>> 'freeze' command. There is no 'distraction' IMO - it is a set of
>> individuals (or companies, even) each with their own priorities. I
>> think this is the sign of a healthy community, actually - one that
>> places importance on its tools and seeks to find optimal ways to
>> improve them in a variety of ways. A freeze command and an improved
>> solver are both excellent (and worthy) improvements.
>>
>
> I agree that it is not zero sum, but I do think that at some point the
> wrong priorities must have been chosen since I have to go to special effort
> to produce a consistent build. Also this is all getting mixed up with a lot
> of talk about PVP and other things whose relevance changes if the
> underlying installation machinery supports what every application developer
> should be doing.
>
>
>> In reality, bundler works precisely for the reason you said it did: it
>> avoids all the actually difficult problems. But that comes at a cost,
>> because Bundler for example can't actually tell me when things *are*
>> going to break. If I bump my dependencies, create a new Gemfile lock,
>> and test - it could all simply explode later on at runtime, even if it
>> could have been concluded from the constraints that it was all invalid
>> in the first place. The only thing bundler buys me is that this
>> explosion won't potentially extend to the rest of my global
>> environment when it happens. Which is a good thing, truth be told, and
>> why it is so popular - otherwise this happens constantly.
>>
>
> This wasn't my experience using bundler. Bundler supports conservative
> upgrades that create consistent packages. So if you want to upgrade
> something you place a range on it and ask Bundler to upgrade it. I don't
> doubt though that it may let you manually subvert the system.
>
>
>> These two concerns are, as far as I can see, in no way opposed in
>> spirit or practice, and suggesting one is essentially wasted effort
>> that distracts people - when I see no evidence of that - strikes me as
>> odd.
>>
>>
> I think the industrial Haskell group supported work on a better solver,
> which was definitely helpful, but I just think it would have been wiser to
> support work on consistent builds first. I agree that they can be worked on
> independently.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140227/7db04922/attachment-0001.html>