The following reddit thread:
http://www.reddit.com/r/haskell/comments/e6o0y/ghc_701_released/c15s7rj
brought up some problems building cabal-install with GHC 7. I think
increasing the upper bounds on Cabal and cabal-install as below will
get them to compile with GHC 7.
Cabal:
filepath 1.2
direct
I'm in favor of adding support to Cabal to allow for this situation.
However: I highly doubt this will be the panacea as predicted. It's already
a huge source of confusion for people using GHCi what they get messages
about "ByteString is not ByteString." In fact, this confusion is so
prevalent that
On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones
wrote:
> It's already a huge source of confusion for people using GHCi what they
> get messages about "ByteString is not ByteString."
>
>
>
> Reading your blog post [1] it seems that we are addressing different
> questions:
>
> · My prop
On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley
wrote:
> The suggestion to use "cabal install --dependencies-only ..." instead
> of "cabal freeze" in that issue is really nicely presented. "cabal
> freeze" is close to the right thing, but it's just not as fully
> featured as "cabal install" (e.g.
On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley
wrote:
> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman
> wrote:
> >
> >
> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley
> > wrote:
> >>
> >> The suggestion to use "cabal install --dep
On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley wrote:
>
>
> On Mar 25, 2015, at 10:51 AM, Michael Snoyman wrote:
>
>
>
> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley
> wrote:
>
>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman
>> wrote:
>>
On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley wrote:
>
>
>
> On Mar 25, 2015, at 11:03 AM, Michael Snoyman wrote:
>
>
>
> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley wrote:
>
>>
>>
>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman
>>
00 PM Anthony Cowley wrote:
>
>
>
> On Mar 26, 2015, at 3:21 AM, Michael Snoyman wrote:
>
>
>
> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley wrote:
>
>>
>>
>>
>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman
>> wrote:
>>
>>
Would be easier to parse with the usual shell tools.
>
> Anthony
>
> On Mar 26, 2015, at 9:41 AM, Michael Snoyman wrote:
>
> Is the idea that you'd be able to make a query such as:
>
> GET
> https://www.stackage.org/lts/1.14/build-plan?package=foo&package=bar&pa
ly left
> out, but I'm on the road at the moment and not terribly capable of thought.
>
> Anthony
>
>
> On Mar 26, 2015, at 10:50 AM, Michael Snoyman wrote:
>
> And do you want the information on the core packages (e.g., base,
> template-haskell, containers) as well
OK, should be working now:
http://www.stackage.org/lts/build-plan?package=warp
On Thu, Mar 26, 2015 at 5:03 PM Michael Snoyman wrote:
> It's trivial for me to include them all, and equally trivial for me to
> call out which ones are shipped with GHC somehow (such as an extra flag on
+1. Oddly enough, I was just in the process of filing a bug report related
to this on something I discovered yesterday, namely that `cabal upload`
uses HTTP basic authentication over HTTP, exposing username/password to
anyone sniffing the connection.
I offered Duncan last week that I'd port cabal-
On Tue, Apr 28, 2015 at 11:12 AM Herbert Valerio Riedel
wrote:
> On 2015-04-28 at 06:08:38 +0200, Michael Snoyman wrote:
>
> [...]
>
> > I offered Duncan last week that I'd port cabal-install over to
> > http-client/http-client-tls to add SSL support. That offer st
On Tue, Apr 28, 2015 at 2:56 PM Thomas Tuegel wrote:
> On Tue, Apr 28, 2015 at 3:21 AM, Michael Snoyman
> wrote:
> > I have no intention of playing the "minimal dependency" game (though I
> don't
> > mind dropping data-default, which accounts for 6 of the
On Tue, Apr 28, 2015 at 4:22 PM Herbert Valerio Riedel
wrote:
> On 2015-04-28 at 10:21:04 +0200, Michael Snoyman wrote:
>
> [...]
>
> > I have no intention of playing the "minimal dependency" game (though I
> > don't mind dropping data-default, whi
> Well, not really. We have an ugly bootstrapping script that downloads
> the other dependencies:
> https://github.com/haskell/cabal/blob/master/cabal-install/bootstrap.sh
>
> Speaking of which...
>
> On Tue, Apr 28, 2015 at 7:38 AM, Michael Snoyman
> wrote:
> >
> >
On Tue, Apr 28, 2015 at 4:40 PM Gershom B wrote:
>
> In that case, perhaps we really should lean only towards the “shell out”
> solution. Or, I suppose, we could hide the ssl implementation behind a flag
> — but that feels rather awkward in comparison.
>
> So let’s try this: can anybody suggest a
On Tue, Apr 28, 2015, 6:08 PM Thomas Tuegel wrote:
> On Tue, Apr 28, 2015 at 8:52 AM, Michael Snoyman
> wrote:
> > Thank you :)
> >
> > Yes, the code is part of the stackage-server code base, available here:
> >
> >
> https://github.com/fpco/stackage-serv
On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel
wrote:
> On 2015-04-28 at 15:50:26 +0200, Michael Snoyman wrote:
>
> [...]
>
> >> PS: We shouldn't forget that there's also an existing deployed
> >> cabal-install user-base we can't get rid
On Wed, Apr 29, 2015 at 10:00 AM Herbert Valerio Riedel
wrote:
> On 2015-04-28 at 18:13:47 +0200, Michael Snoyman wrote:
>
> [...]
>
> > Your analysis is accurate. There are some interesting approaches we could
> > take to further mitigate things. For example: newer versi
-commons-0.1.12
http-client-0.4.11.2
http-client-openssl-0.2.0.1
On Tue, Apr 28, 2015 at 11:08 AM Herbert Valerio Riedel
wrote:
> On 2015-04-28 at 06:08:38 +0200, Michael Snoyman wrote:
>
> [...]
>
> > I offered Duncan last week that I'd port cabal-install over to
> > h
I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
planning that it would happen after the first few releases. I'm fine with
doing it starting with the next release if that's desired.
The cygwin/msys conflict is a problematic one. stack has more flexibility
addressing this
of GHC anywhere on your path.)
>
> On Sunday, July 12, 2015, Michael Snoyman wrote:
>
>> I'm +1 on nailing down an LTS release cycle, I've been pushing for it,
>> and planning that it would happen after the first few releases. I'm fine
>> with doing it s
A few months ago I noticed that pull request 2617[1] implements a change
I'd love to see in Cabal: not requiring a global package database for GHCs
that support this (7.6 and on). The change is small and self-contained, and
looks like a good one to me, but it hasn't been merged. Any chance someone
Hi all,
Oleg mentioned to me on Reddit that a 2.2 branch has been cut for Cabal,
and recommended we try to upgrade Stack to it. I'm sharing information here
on that process in case it's useful to others, either as feedback on the
API changes, or help for others going through similar upgrades. If a
as a concept (IIRC it's converted to
> LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be
> necessary if you plan to read (human readable) text back.
>
> Oleg
>
> On 20.02.2018 15:47, Michael Snoyman wrote:
> > Hi all,
> >
> > Oleg mentione
/blob/32fea06a1023a507d7dc16b29f5425
> 38c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246
>
>
> On 20.02.2018 19:45, Michael Snoyman wrote:
> > I'm sorry, I'm not quite sure I understand your recommendation. Are
> > you saying that I should ideally replace all
.Pretty.Pretty` instance (`prettyShow`).
>
> - Oleg
>
>
> On 20.02.2018 20:28, Michael Snoyman wrote:
> > Alright, I've updated the PR to use `Either SPDX.License License`:
> >
> > https://github.com/commercialhaskell/stack/pull/3878/commits/
> 6679aafe99a08
Looks like it came through safely to me!
On Tue, Jun 4, 2019, 2:03 AM Simon Peyton Jones via cabal-devel <
cabal-devel@haskell.org> wrote:
> Dear Cabal-devs
>
> My earlier messages to cabal-devel was flagged as spam by the time it
> reached Michael and Carter. (Perhaps others too.)
>
> Gershom h
29 matches
Mail list logo
