Should "std.net.curl" be moved from Phobos to Deimos?

[Andrei Alexandrescu]

On 11/25/13 1:34 AM, deadalnix wrote:
> On Monday, 25 November 2013 at 07:38:38 UTC, Jordi Sayol wrote:
>> As Jonathan M Davis said:
>> ---
>> Several of the main devs (including Walter) have stated that having
>> std.net.curl on Phobos was a mistake given all of the problems that
>> we've had with it on Windows and Linux as well, and at least some of
>> them have expressed a desire for it to be removed. I expect that
>> there's a good chance that it can and will be removed from Phobos if
>> brought up for discussion.
>>
>> Certainly, I think that it's clear that we will not add any further
>> external dependencies like curl, because curl has proven to be a big
>> problem. It's very desirable to have bindings and wrappers for C
>> libraries - but putting them in the standard library when it's not
>> guaranteed that the appropriate library is on the system by default
>> has proven to be too problematic, so they should be left to external
>> projects.
>> ---
>>
>> "std.net.curl" can also be moved from Phobos to Deimos.
>> Deimos can be rethink, i.e. new build master can add a make building
>> script on Deimos in order to compile all projects included on it,
>> generating "libdeimos.a" and "libdeimos.so", documentation, etc.
>
> I have to second this. It has been a major pain to get D to work in some
> environment because of the dependency on curl.

The continuing stream of issues associated with curl is puzzling me. We 
chose curl _exactly_ because (a) it was available or trivial to install 
everywhere, (b) it had accreted through experience a bunch of tricks 
that made little sense to rediscover the hard way.

Now it seems curl is failing at least the first premise, so we should 
consider various alternatives. First I'd like to gather an understanding 
on why we seem to have this problem (far as I understand, the likes of 
php and python are doing fine with curl, but maybe I'm wrong). So is 
there a short and simple list of issues that anyone can put together?

If we do decide to do away with libcurl, one possible solution would be 
to embed its source code within our build. That way we wouldn't break 
code that already uses it.


Andrei