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
I've been happily using the curl backend for a bit now and it seems to work
fine, so I'd like to get this polished and committed.
Since the curl backend works, then even if the wget and powershell backends
aren't fully tested, the workaround can just be to tell users to install
curl and make sure
On 8 May 2015 at 00:14, Gershom B gersh...@gmail.com wrote:
On my branch now, everything should work:
https://github.com/gbaz/Cabal/tree/https
Thanks for working on this. I only had time to take a brief glance,
but everything looks good so far. Hope we can merge your patches soon.
(note that
Hi,
On 6 May 2015 at 20:08, Thomas Tuegel ttue...@gmail.com wrote:
The saved program configuration is not serialized in
`dist/setup-config`, [1] so it must be regenerated at runtime every
time, anyway.
We don't want to configure all known built-in programs on each 'cabal
upload', though, so
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
On 6 May 2015 at 00:26, Gershom B gersh...@gmail.com 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.
I'd also
On 6 May 2015 at 17:43, Gershom B gersh...@gmail.com wrote:
I’m less certain about the use of ProgramDB — the documentation suggests it
will only be populated from command line flags in the “configure” step, or
from .cabal files. Since upload/download do not take place in such settings,
I
On Wed, May 6, 2015 at 11:53 AM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
On 6 May 2015 at 17:43, Gershom B gersh...@gmail.com wrote:
I’m less certain about the use of ProgramDB — the documentation suggests it
will only be populated from command line flags in the “configure”
The “Transport” data type you suggest seems like a good refactor. I’m less
certain about the use of ProgramDB — the documentation suggests it will only be
populated from command line flags in the “configure” step, or from .cabal
files. Since upload/download do not take place in such settings, I
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
Ok, on my https branch here: https://github.com/gbaz/Cabal/tree/https
We have some initial support for multibackend downloads and uploads both.
Lots of bits are still missing, but the basic downloads work with curl and
wget both, and the basic uploads with curl.
The code regarding uploading
Hi,
On 4 May 2015 at 08:31, Michael Snoyman mich...@snoyman.com wrote:
Just a little update on this. I pinged the author of publicsuffixlist
(necessary for proper cookie domain handling) about removing the
data-default dependency, and after discussion we decided to just merge the
code into
Just a little update on this. I pinged the author of publicsuffixlist
(necessary for proper cookie domain handling) about removing the
data-default dependency, and after discussion we decided to just merge the
code into http-client instead. With that change, the full dependency list
for
As a user of both http-client and tls, I can vouch for having
very good experience with both, and I thank Michael
for his offer. I prefer that option.
However -
Both extra Haskell dependencies and C dependencies are a
problem for cabal-install.
The reason is that cabal is a basic requirement to
On Thu, Apr 30, 2015 at 5:12 AM, Yitzchak Gale g...@sefer.org wrote:
Both extra Haskell dependencies and C dependencies are a
problem for cabal-install.
The reason is that cabal is a basic requirement to
bootstrap a Haskell installation from scratch. So either of those
will make life very
On Apr 30, 2015 7:42 AM, Yitzchak Gale g...@sefer.org wrote:
Thomas Tuegel wrote:
Michael is putting together some tools for us that should make added
Haskell dependencies a non-issue from the standpoint of distributing
cabal-install. We already have a bootstrap script for this purpose,
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
On Wed, Apr 29, 2015 at 10:00 AM Herbert Valerio Riedel hvrie...@gmail.com
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 versions of
On Tue, Apr 28, 2015 at 4:40 PM Gershom B gersh...@gmail.com 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
On Tue, Apr 28, 2015 at 4:48 PM Thomas Tuegel ttue...@gmail.com wrote:
On Tue, Apr 28, 2015 at 8:40 AM, Gershom B gersh...@gmail.com wrote:
More troublesome, I recall that the current scheme for cabal is that it
is fully bootstrappable by only depending on GHC base libs and “vendored”
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
On Tue, Apr 28, 2015 at 4:22 PM Herbert Valerio Riedel hvrie...@gmail.com
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, which accounts for 6 of the
dependencies
On Tue, Apr 28, 2015 at 8:40 AM, Gershom B gersh...@gmail.com wrote:
More troublesome, I recall that the current scheme for cabal is that it is
fully bootstrappable by only depending on GHC base libs and “vendored”
dependencies?
Well, not really. We have an ugly bootstrapping script that
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
On Tue, Apr 28, 2015 at 3:21 AM, Michael Snoyman mich...@snoyman.com 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
On Tue, Apr 28, 2015 at 2:56 PM Thomas Tuegel ttue...@gmail.com wrote:
On Tue, Apr 28, 2015 at 3:21 AM, Michael Snoyman mich...@snoyman.com
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
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
On 28-04-2015 16:58, Duncan Coutts wrote:
On Mon, 2015-04-27 at 23:55 -0400, Gershom B wrote:
I would like to pursue getting SSL into cabal by any of these three
avenues. What do people feel about the relative tradeoffs of these
options? Honestly, I lean towards simply using the tls package,
On Mon, 2015-04-27 at 23:55 -0400, Gershom B wrote:
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
On Tue, Apr 28, 2015 at 8:52 AM, Michael Snoyman mich...@snoyman.com wrote:
Thank you :)
Yes, the code is part of the stackage-server code base, available here:
https://github.com/fpco/stackage-server/blob/master/Handler/BuildPlan.hs#L40
When I was working on this for Nix, I offered to make
On Tue, Apr 28, 2015, 6:08 PM Thomas Tuegel ttue...@gmail.com wrote:
On Tue, Apr 28, 2015 at 8:52 AM, Michael Snoyman mich...@snoyman.com
wrote:
Thank you :)
Yes, the code is part of the stackage-server code base, available here:
On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel hvrie...@gmail.com
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 off so easily, which may
still
On Tue, Apr 28, 2015 at 11:12 AM Herbert Valerio Riedel hvrie...@gmail.com
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 still stands.
I did a
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
On Tue, Apr 28, 2015 at 7:58 AM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
However, everyone seems to agree that it would be unambiguously better
if the cabal install executable were able to communicate over ssl.
Yeah.
Strongly +1'd. Following this track, if cabal's http handling
35 matches
Mail list logo
