Re: windows cabal binaries and upcoming cabal-install release

On Fri, Nov 9, 2018 at 5:32 AM Gershom B wrote: > No binaries were built for the 2.4.0.0 release -- I assume with the > upcoming release we'll have proper binaries. ...actually they were; we're transitioning to move the binary hosting to http://downloads.haskell.org and I failed to setup the

Re: Upgrading Stack to Cabal 2.2

On Tue, Feb 20, 2018 at 2:47 PM, Michael Snoyman wrote: > If I could make a request, it would be that, in > the future, new runtime behavior come with a new function name, to convert > runtime errors into compile time errors. Well, this is one of the primary reasons we have

Re: building a project with new-* commands

Hi! On 2016-09-16 at 14:34:14 +0200, Ramakrishnan Muthukrishnan wrote: [..] > I will try building and trying the `master' branch. Thanks again. That's generally recommended with new-build at this point, since a lot of things have improved in cabal 1.25/master since cabal 1.24; Also, I'd also

Re: pre-710 compatibility stuff

On 2015-10-24 at 15:05:44 +0200, Thomas Tuegel wrote: [...] > MIN_VERSION_base is defined by Cabal, so it is not available during > bootstrapping. yes, and that's why we have a cabal_macros_boot.h in GHC's build-system for bootstrapping purposes,

HEAD-UPS: IRC presence for Haskell Infrastructure Hackathon 11-11th Oct 2015

Hi, as you may know, https://skillsmatter.com/conferences/7316-haskell-infrastructure-hackathon-2015 is starting right now! Attendees will be directed to the #hackage/freenode channel for task coordination, support, and counseling... It'd be great if those of you with some experience with

Please help beta test no-reinstall Cabal (was: Cabal and simultaneous installations of the same package)

Good news, everyone! ...you may be interested to know this has finally come to fruition (just in time for HIW): http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/ Cheers, hvr On 2015-03-23 at 09:45:48 +0100, Simon Peyton Jones wrote: Dear Cabal developers You'll

Re: Making cabal-install SSL capable

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 versions of cabal-install could automatically set an incorrect username/password in the ~/.cabal/config

Re: Making cabal-install SSL capable

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 off so easily, which may still leak unencrypted basic-auth credentials for the years to come. Just saying... I

Re: Making cabal-install SSL capable

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, which accounts for 6 of the dependencies listed there). I will point out- as Gershom already did- that in many cases it's

Re: Making cabal-install SSL capable

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 still stands. I did a quick check trying to find out the additional dependencies (relative to what

Re: Please review: new wiki page with release instructions

On 2015-03-16 at 08:14:06 +0100, Johan Tibell wrote: In order to allow other people than me to make releases in the future, I tried to write down a step-by-step guide to making a release (the page is linked from the wiki homepage): https://github.com/haskell/cabal/wiki/Making-a-release I'd

Re: The bootstrap.sh script has to go

On 2014-12-30 at 21:23:19 +0100, Jake Wheat wrote: [...] Simplify the bootstrap.sh process: * always use a fixed set of versions of packages for the dependencies For me, the primary use-case of `bootstrap.sh` is to be able to build a matching `cabal-install` executable for a given major GHC

Re: Upper bound on time in Cabal causes build failure

On 2014-12-17 at 11:14:36 +0100, Erik Hesselink wrote: It would perhaps be worth it for someone with the right permissions to edit the (five) old versions on hackage, and add upper bounds. That way cabal install wouldn't use this very old version assuming it works (it probably doesn't). FYI:

Re: Getting Cabal 1.2[12] ready for GHC 7.10.1 RC1

Hello Johan, ...how's progress for a Cabal RC to go w/ GHC 7.10.1 RC1? :-) On 2014-12-02 at 11:16:46 +0100, Johan Tibell wrote: I think I can have a RC out without 2 weeks. On Tue, Dec 2, 2014 at 8:53 AM, Luite Stegeman stege...@gmail.com wrote: On Mon, Dec 1, 2014 at 7:40 PM, Bardur

Re: Windows executable for just released cabal-install-1.20.0.1 needed

On 2014-05-05 at 04:15:55 +0200, Mikhail Glushenkov wrote: On 4 May 2014 10:57, Johan Tibell johan.tib...@gmail.com wrote: We can also provide a Linux executable, but I don't quite know how portable an executable would be if I build it on e.g. some specific version of Ubuntu? Attaching a

Re: cabal-install: Replacing HTTP with HTTPS

On 2014-04-01 at 22:43:47 +0200, Nikita Karetnikov wrote: Turns out cabal-install itself uses HTTP. (Try to grep for “hackage” in the source tree.) Is it due to the HTTP library, which doesn’t support HTTPS (4000.2.12 returns “user error (https not supported)”)? Is there any interest in

Re: Cabal File Pretty Printer

On 2014-02-27 at 20:23:59 +0100, Erik Hesselink wrote: On Wed, Feb 26, 2014 at 4:01 PM, Johan Tibell johan.tib...@gmail.com wrote: On Wed, Feb 26, 2014 at 3:51 PM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: 1. change `cabal init` to use the pretty printer. 2. expose the pretty

Re: cabal-install-1.18 on GHC-6.12

On 2013-10-28 at 09:31:49 +0100, Johan Tibell wrote: [...] Johan, was it you who cherry-picked it from master? Wasn't 1.18 supposed to still support 6.12? This is my fault. I don't know if it's worth another Cabal release to fix it though. 6.12 is more than 3 years old now. Fwiw, GHC

Re: Keeping the cabal website in the git repo

On 2013-09-08 at 07:49:57 +0200, Johan Tibell wrote: While the sources of some of the documentation is already in git, much of the website (http://www.haskell.org/cabal/) isn't. I suggest we check it in under a website/ directory, next to the Cabal and cabal-install directories. Fyi/btw,

Re: be friendlier to user (was Re: What's next?)

On 2013-09-07 at 09:00:47 +0200, Sergei Trofimovich wrote: [...] 2. Would be nice for cabal build somehow check that 'ghc --make' can't access files not present in .cabal file. That way amount of packages with missing uploaded tests could be shunken down. Otherwise we have

Re: Gearing up for a 1.18 release

On 2013-08-20 at 10:26:07 +0200, Mikhail Glushenkov wrote: On Mon, Aug 19, 2013 at 11:02 PM, Johan Tibell johan.tib...@gmail.com wrote: What's the status of this? 'cabal repl' seems to work fine with sandboxes. The backwards compat patch for #1214 is not yet done (I'm on it). Other than

Re: Adding tests for cabal-install

Jason Dagit dag...@gmail.com writes: [...] The risk of using the cabal-install modules as a library is that the API of cabal-install should be allowed to change freely between versions, potentially causing breakages in downstream tools. I think if that risk is understood by consumers of the

license cabal field for language bindings?

Hello Cabal Devs, Since the recurring topic of software licenses is being discussed on haskell-cafe again, I was wondering what the .cabal license-field should be for packages linking _directly_ to C-libraries, such as Haskell language bindings to C-libraries. To be more specific: As a

Re: A-posteriori .cabal updates don't help (much) with optimistic-upper-bounds

Malcolm Wallace malcolm.wall...@me.com writes: On 3 Dec 2012, at 11:35, Herbert Valerio Riedel wrote: 2) there's a package text-foo which depends on 'text = 0.10' (i.e. with no upper bound), for which N versions exist on Hackage (all with the same 'text = 0.10' constraint): 0.1.0