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

[deadalnix]

On Tuesday, 26 November 2013 at 19:06:26 UTC, Andrei Alexandrescu 
wrote:
> On 11/25/13 10:53 PM, H. S. Teoh wrote:
>> On Tue, Nov 26, 2013 at 06:44:03AM +0100, Jesse Phillips wrote:
>> [...]
>>> I don't think I understand having to build dmd just because 
>>> you have
>>> a different distribution, Phobos maybe but dmd... Even for 
>>> Phobos
>>> I'm skeptical but am not going to install a different distro 
>>> to
>>> experiment myself.
>>
>> If you have used enough Linux distros (or even different 
>> versions of the
>> same distro!), you will realize that all it takes is for a 
>> single shared
>> library on the system to be a different version, missing, or 
>> just the
>> same version built with different compiler flags, and the 
>> executable
>> will not work. Not to mention that filesystem layout can be 
>> different
>> across distros (and versions of the same distro), which will 
>> break
>> things.
>>
>> Basically, to guarantee a program runs on distro X, the only 
>> way is it
>> has to be built from source. If you're lucky, somebody else 
>> has already
>> done that, and you can just download the binary. (Or better 
>> yet,
>> somebody packaged it for your distro, then you can just 
>> install it via
>> your system's package system.) But if not, you'll just have to 
>> do it
>> yourself.
>
> Do we with our std.net.curl make this matter any worse?
>
>>> If it is moved to a third party library, the problems will 
>>> still
>>> remain. If the Phobos team is expected to support it, then the
>>> burden hasn't shifted either.
>>
>> This I agree with. However, it misses the point. The point is 
>> that the
>> core D toolchain (dmd/phobos/druntime) would have one less 
>> dependency,
>> which is generally a good thing, because you want to make it 
>> as easy as
>> possible for people to get a working compiler up and running.
>
> But my understanding is that the dependency is conditional, 
> i.e. you have no dependency on libcurl unless you attempt to 
> use std.net.curl. Which strikes me as entirely reasonable. No?
>
>> Requiring
>> this library and that library and that other tool, just to get 
>> a bare
>> bones D toolchain working, is a good way to turn people off D.
>
> Bare bones == no std.net.curl. No?
>
>> If a bare
>> bones D compiler is actually working, then they'd have more 
>> incentive to
>> actually put in more effort to make the frills work too. 
>> Having a hello
>> world program be uncompilable just because libcurl isn't 
>> available, is a
>> very bad first impression ("why does this stupid language need 
>> libcurl
>> just to compile a hello world program?!").
>
> My understanding is that a missing or broken libcurl does not 
> break hello world. Is that correct?
>
> As a note regarding my many messages in this thread: I decided 
> to get to the bottom of this given that I've asked "what is 
> exactly the problem with libcurl" and all I got was unclear 
> answers.
>
>
> Thanks,
>
> Andrei

In some cases, it can prevent the whole stuff to link. Otherwise, 
hello world should simply work.