Re: hackage reverse dependencies

2013-10-14 Thread Gershom B
It seems to me that all we really need is a list of all first generation revdeps on a given package (any version), each specified maybe as (in pseudodata): type VersionRange = (Version,Version) type RevDep = (PackageName,[VersionRange]) RevDeps = [RevDep] (alt M.Map PackageName [VersionRange])

Re: [patch] lincenses warning

2015-03-06 Thread Gershom B
that if no other license is specified, ANY work is by definition all rights reserved! anyways, thats my 2cents for the evening cheers-Carter On Tue, Mar 3, 2015 at 1:56 PM, Gershom B wrote: Thanks for this patch! I've kicked off a discussion with hackage administrators and the haskell

Mentors and thoughts on a GSoC proposal?

2015-03-31 Thread Gershom B
Hi all! We have the following GSoC proposal submitted to us: https://gist.github.com/fugyk/37510958b52589737274 Is there anyone on the cabal-devel list who would like to join as a mentor either to comment on this proposal, or feels up to mentoring this proposal (if we are to accept it, it

An Easy Solution to PVP Bounds and Cabal Hell

2015-03-31 Thread Gershom B
Recently there has been some discussion about how we can fix the problem of “Cabal Hell”. Some people advocate restrictive upper bounds, to prevent packages from being broken by new updates. Some other people point out that too-restrictive bounds can lead to bad install plans, since some

Re: Cabal webpage on haskell.org

2015-03-22 Thread Gershom B
I’ve re-enabled the directory listings for  https://www.haskell.org/cabal/release/ (admins, note: I just changed the nginx.conf directly, we need to backport all our changes into the full deploy scripts…) —Gershom On March 15, 2015 at 3:18:52 AM, Miëtek Bak (mie...@bak.io) wrote: There are at

Re: [patch] lincenses warning

2015-03-03 Thread Gershom B
Thanks for this patch! I've kicked off a discussion with hackage administrators and the haskell committee about the general approach we want to take to the license situation on hackage, and how to properly document our policies. It seems to me that merging this makes sense regardless, but I don't

Re: Cabal webpage on haskell.org

2015-03-18 Thread Gershom B
Mitek: Go ahead and send on a public ssh key to admin@ and we'll get you access to that portion of the site. In terms of further contributions / places to start, Johan mentioned he would in particular appreciate help in automating this process:

Re: Cabal and simultaneous installations of the same package

2015-03-23 Thread Gershom B
On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones simo...@microsoft.com wrote: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by cabal hell, but the inability

Re: Making cabal-install SSL capable

2015-04-28 Thread Gershom B
I don’t think the issue of http libraries as a foundational core library is very important. I suspect it would be possible to do a minimal http transport over tls, just as one can over HsOpenSSL, if that is how we decided to go. In the meantime, here are the first-order dependencies of tls

Making cabal-install SSL capable

2015-04-27 Thread Gershom B
So there are many discussions over various hackage security schemes, and there are a variety of takes on the different elements of how we could make package distribution more secure. However, everyone seems to agree that it would be unambiguously better if the cabal install executable were

Re: Making cabal-install SSL capable

2015-05-05 Thread Gershom B
Note that I’ve started some refactorings to support curl/wget/etc already. I’m not sure how best to keep these patches from stepping on one another’s toes. I’ll try to get my stuff to an unfinished, untested stopping point where nonetheless there is a clear extension point, and then perhaps a

Re: Making cabal-install SSL capable

2015-05-07 Thread Gershom B
On my branch now, everything should work: https://github.com/gbaz/Cabal/tree/https By should I mean the refactor is in place, and we have support for curl, wget, powershell, and insecure-http. You can pass a global flag to set your preferred transport (and it will not try insecure-http unless

Re: Cabal and simultaneous installations of the same package

2015-05-07 Thread Gershom B
For the info of all, here is the proposal: https://gist.github.com/fugyk/37510958b52589737274 The mentors are Ryan Trinkle and Thomas Tuegel. Hopefully as the project proceeds, Vishal will be checking in with us, asking questions and seeking clarification where necessary, etc. --Gershom On

Re: Making cabal-install SSL capable

2015-05-05 Thread Gershom B
to make it available for others interested in doing related work. Cheers, Gershom On Tue, May 5, 2015 at 10:15 AM, Gershom B gersh...@gmail.com wrote: Note that I’ve started some refactorings to support curl/wget/etc already. I’m not sure how best to keep these patches from stepping on one

Re: Making cabal-install SSL capable

2015-05-06 Thread Gershom B
...@gmail.com) wrote: On 6 May 2015 at 00:26, Gershom B wrote: Ok, on my https branch here: https://github.com/gbaz/Cabal/tree/https Looks like a good first step. Consider using machinery in Distribution.Simple.Program.Db for searching for curl/wget in path or in user-provided location

Re: Making cabal-install SSL capable

2015-05-18 Thread Gershom B
, someone can jump in and try to give a hand with the other two backends -- they're very close. -g On Fri, May 8, 2015 at 12:46 PM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: On 8 May 2015 at 00:14, Gershom B gersh...@gmail.com wrote: On my branch now, everything should work

Re: Making cabal-install SSL capable

2015-05-28 Thread Gershom B
Done: https://github.com/haskell/cabal/pull/2613 :-) --Gershom On Mon, May 18, 2015 at 4:15 PM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Hi, On 18 May 2015 at 20:22, Gershom B gersh...@gmail.com wrote: So perhaps we can just patch cabal to warn on using wget or powershell

Re: Request for feedback on spec/proposal for distributing package collections via hackage

2015-07-14 Thread Gershom B
and is there any point to having a collection without versions in it? (If Cabal syntax is extended to support depending on collections as well as packages, yes?) So I think another use-case for collections, besides version-locked, is sets of blessed packages. So we might want a collection for

Re: ANN: cabal-install-1.22.6.0 has been released

2015-11-09 Thread Gershom B
Well, it’s worse than that. The recent releases haven’t come with any official binaries at all. So if we wanted to make the official Cabal binaries more prominent (good idea) then we should actually generate and link to those binaries (which takes work). This relates to the discussion I’ve

Fwd: Haskell Platform Plans

2015-11-12 Thread Gershom B
Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and

Re: Improving the Get Haskell Experience

2015-07-12 Thread Gershom B
I’m ccing cabal-devel, as that list seems pertinent to this discussion too. In general I’m in favor of unifying efforts such as this. For windows, I’d still like the _option_ to get prebuilt library binaries for the full platform db. The modularity means that they can be just downloaded in a

Re: cabal-install rebooted?

2015-09-08 Thread Gershom B
That _does_ look simpler! However, I think there are multiple efforts underway towards the nix-style stuff. We had a GSoC on that for example. And in that workflow, if it all works out properly, then we end up with a situation where since the general-user-db has no conflicts, then sandboxes are

Global Constraints for Cabal

2015-09-10 Thread Gershom B
Hi all. I've got a branch of cabal with a new feature: https://github.com/gbaz/cabal/tree/constraints-config This lets you either pass `constraints-file` on the command line or in the ~/.cabal/config file. The constraints-file serves as a "default" cabal.config file for freezes should one not be

Re: Global Constraints for Cabal

2015-09-11 Thread Gershom B
I've changed Freeze.hs to also respect this flag, and submitted a pull request: https://github.com/haskell/cabal/pull/2820 --Gershom On Thu, Sep 10, 2015 at 6:45 PM, Gershom B <gersh...@gmail.com> wrote: > Hi all. I've got a branch of cabal with a new feature: > https://github.co

Re: Global Constraints for Cabal and also Release Plan?

2015-09-24 Thread Gershom B
On September 24, 2015 at 11:01:53 AM, Bardur Arantsson (s...@scientician.net) wrote: > On 09/22/2015 12:11 AM, Gershom B wrote: > [--snip--] > > > > The proposal there would be to add an env variable (perhaps > > CABAL_PATH_PREFIX) which, if it existed, would be adde

Re: Global Constraints for Cabal and also Release Plan?

2015-09-24 Thread Gershom B
On September 24, 2015 at 11:52:51 AM, Mikhail Glushenkov (the.dead.shall.r...@gmail.com) wrote: > On 24 September 2015 at 17:06, Gershom B wrote: > > So, I want MSys2 tools in my path but _only_ when I am building cabal > > packages, and not > otherwise. > >

Re: Global Constraints for Cabal and also Release Plan?

2015-09-25 Thread Gershom B
On September 24, 2015 at 12:16:29 PM, Mikhail Glushenkov (the.dead.shall.r...@gmail.com) wrote: > On 24 September 2015 at 17:56, Gershom B wrote: > > Consider for example if we have a configure build-type, that runs an > > autoconf script. > It is not enough that the

Re: Global Constraints for Cabal and also Release Plan?

2015-09-25 Thread Gershom B
On September 25, 2015 at 5:43:38 PM, Gershom B (gersh...@gmail.com) wrote: > Ah this looks like it only takes hold for the simple build-type and not > “build-type: configure” > for use with autoconf. (i.e. the “building network” case). I don’t quite see > what’s going > on

Global Constraints for Cabal and also Release Plan?

2015-09-21 Thread Gershom B
ase? -g On Fri, Sep 11, 2015 at 5:17 PM, Gershom B <gersh...@gmail.com> wrote: > I've changed Freeze.hs to also respect this flag, and submitted a pull > request: > > https://github.com/haskell/cabal/pull/2820 > > --Gershom > > On Thu, Sep 10, 2015 at 6:45 PM, Gersho

Re: [ANN] Cabal and cabal-install 1.24.0.0 have been released

2016-05-10 Thread Gershom B
the cabal-latest directory should probably be updated as well, and particularly the doc section: https://www.haskell.org/cabal/release/cabal-latest/ I also note that the docs haven't built on hackage for Cabal, and it would be nice to upload those I guess..? --gershom On Mon, May 2, 2016 at

Re: Wanted: cabal-install 1.24.0.0 binary for OS X

2016-05-05 Thread Gershom B
I've emailed Mikhail with a binary. Assuming it works, then nobody else should need to :-) Cheers, Gerhsom On Wed, May 4, 2016 at 3:30 PM, Mikhail Glushenkov wrote: > Hi *, > > I've uploaded cabal-install 1.24.0.0 binaries for Linux and Windows > (both i386 and

Re: Opening up Cabal development

2016-07-13 Thread Gershom B
On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezy...@mit.edu) wrote: The general notion sounds good to me. I’m semi-indifferent between (1) and (2) though conservatively lean towards the latter. > - The Travis build must always be green. We should prioritize > adding more tests for things we

Re: cabal release binaries for 1.24.0.2 ?

2017-01-11 Thread Gershom B
It seems like the binaries (aside from the os x one) aren't up yet. It would be good to have them for the new ghc and platform. --gershom On Sat, Jan 7, 2017 at 4:12 PM, Mikhail Glushenkov <mikhail.glushen...@gmail.com> wrote: > Hi, > > On 7 January 2017 at 21:02, Gershom B <

cabal release binaries for 1.24.0.2 ?

2017-01-07 Thread Gershom B
I noticed that there there are no binaries for 1.24.0.2 and in fact the webpage still links the source tarball for 1.24.0.1 as the latest? It would be good to get this fixed. —Gershom ___ cabal-devel mailing list cabal-devel@haskell.org

new cabal install binaries

2017-12-03 Thread Gershom B
when we build the new platform we're going to have new cabal-install binaries for 2.0.1.0. It would be better if we provided the same ones as provided on the cabal website. Is there anyone lined up to build any of these, or would you like the platform team to provide you with the binaries we build

draft proposal on provenance-qualified dependencies

2018-02-18 Thread Gershom B
Hey all, I mentioned (on the long SLURP thread) that I was thinking about a general proposal for provenance-qualified dependencies to reduce coupling in the haskell ecosystem. Having worked it out a bit, I think the bigger win is it also provides a way to specify dependencies on git repos, etc.,

Re: draft proposal on provenance-qualified dependencies

2018-02-23 Thread Gershom B
> Simon > > | -Original Message- > | From: cabal-devel [mailto:cabal-devel-boun...@haskell.org] On Behalf > | Of Gershom B > | Sent: 19 February 2018 00:26 > | To: cabal-devel <cabal-devel@haskell.org> > | Subject: draft proposal on provenance-qualified

Re: draft proposal on provenance-qualified dependencies

2018-03-13 Thread Gershom B
l > | users? > > Well I can say with certainty that it's insufficiently understood by /this/ > cabal user. > > I had no idea there could be more than one repo, which 'cabal update' caches > locally. > > Simon > > | -Original Message- > | From: Gershom

windows cabal binaries and upcoming cabal-install release

2018-11-08 Thread Gershom B
No binaries were built for the 2.4.0.0 release -- I assume with the upcoming release we'll have proper binaries. Just wanted to drop a note to _highly recommend_ that at least the windows cabal-install binaries in the next release be built with ghc 8.6.2 since I think that changes in the core

downloads.haskell.org now moved

2019-02-16 Thread Gershom B
The migration of the downloads box to packet is now done. Rather than uploading to downloads-origin.haskell.org, binaries should now go to downloads-packet-origin.haskell.org. The former will be decommissioned soon-ish. This applies for cabal and ghc binaries both. Login for the `cabal` and `ghc`

Re: [Patch] Fix estimator explanation

2019-02-05 Thread Gershom B
Sorry for the slow response time. I know you've been on this for a while. I've now committed those changes to master and they'll be in the next redeploy. Thanks! --Gershom On Sun, Feb 3, 2019 at 4:22 PM Francesco Ariis wrote: > > Good evening hackage developers, > please consider merging