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

[Greg Weber]

That was the plan. I spend a large amount of company time contributing back
to open source. Originally I was going to spend some of it on helping
implement cabal freeze, but I left it in the hands of others that were more
capable and I haven't checked back in a long time.


On Thu, Feb 27, 2014 at 1:00 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 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/c2052948/attachment.html>