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.

-- 
Jordi Sayol

On Monday, 25 November 2013 at 07:38:38 UTC, Jordi Sayol wrote:
> "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.

Deimos currently only hosts bindings, not wrappers, as part of
its objective. So, etc.c.curl would be appropriate, but
std.net.curl would be unprecedented.

I think both etc.c.curl and std.net.curl should just be ripped
out and moved into a CurlD (or whatever) project, hosted by
someone on Github (such as Jonas Drewsen or a maintainer), on the
grounds that I don't think Phobos is a place for wrapper
libraries.

I think std.net.curl is a well designed wrapper library, and I
would happily continue to use it in my projects, but I don't
think it's appropriate for Phobos.

As an aside, personally I think Deimos is pointless; and worse,
horribly executed (A Github organization? Really?). A simple wiki
page like this one[1] can do the job much better and without the
ridiculous self-imposed disadvantages we are putting up with by
using a Github organization.

[1] http://wiki.dlang.org/Bindings

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.

Am 25.11.2013 09:32, schrieb Jakob Ovrum:
> On Monday, 25 November 2013 at 07:38:38 UTC, Jordi Sayol wrote:
>> "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.
> 
> Deimos currently only hosts bindings, not wrappers, as part of its objective. So, etc.c.curl would be appropriate, but std.net.curl would be unprecedented.
> 
> I think both etc.c.curl and std.net.curl should just be ripped out and moved into a CurlD (or whatever) project, hosted by someone on Github (such as Jonas Drewsen or a maintainer), on the grounds that I don't think Phobos is a place for wrapper libraries.
> 
> I think std.net.curl is a well designed wrapper library, and I would happily continue to use it in my projects, but I don't think it's appropriate for Phobos.
> 
> As an aside, personally I think Deimos is pointless; and worse, horribly executed (A Github organization? Really?). A simple wiki page like this one[1] can do the job much better and without the ridiculous self-imposed disadvantages we are putting up with by using a Github organization.
> 
> [1] http://wiki.dlang.org/Bindings

Or, even better (because it doesn't get out of date), an automatically generated list like this one: http://code.dlang.org/?sort=name&category=library.binding

On Monday, 25 November 2013 at 10:08:12 UTC, Sönke Ludwig wrote:
> Or, even better (because it doesn't get out of date), an automatically
> generated list like this one:
> http://code.dlang.org/?sort=name&category=library.binding

Yeah, absolutely :)

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

On Tuesday, 26 November 2013 at 00:13:57 UTC, Andrei Alexandrescu wrote:

> 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

A solution could be to ship curl with phobos, if license allow to do so.

On Tuesday, 26 November 2013 at 00:13:57 UTC, Andrei Alexandrescu wrote:
> 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).

A major difference is there's only one php/python binary, usually build on the same system that uses it. Phobos, on the other hand, is generally built on the packager's computer, which isn't always binary compatible with the deployment box.

On Windows, the problem is simply that curl isn't packaged with dmd, for some weird reason, meaning people have to get curl.lib separately. That's idiotic. But then again, so are a lot of the dmd Windows deficiencies.

> 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.

Yes, that would be ideal, we should just statically link curl right into the phobos build so it just works everywhere.

On Monday, November 25, 2013 16:13:57 Andrei Alexandrescu wrote:
> 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.

The number one problem on Windows is the fact that libcurl does not come with Windows and that you have to get a version of it build which is compatible with dmd has proven to be a huge hurdle for Windows developers. There may be other problems, but that's the biggest. Distributing libcurl with dmd could fix that, but IIRC, there was some reason why we couldn't do that (or maybe it was just that Walter didn't want to - I can't remember).

On Linux, I believe that the biggest problem is that dmd then has to be built on your specific distro for it to work with your distro, so the libraries in the zip file were only working on debian-based systems. Regardless of why libcurl is not distributed with dmd on Windows, we couldn't distribute for Linux to fix this problem, because that would conflict with the system's libcurl.

There may be other problems, but I think that those are the two bigs ones, and they've come up several times (particularly the issues with libcurl and Windows).

There's also Don's recent rant on why curl was ever supported in the first place, but I guess that he just wasn't paying enough attention to it given that he only complained about it recently rather than during the review:

http://forum.dlang.org/thread/CADpwU1cu=0r+NJ+4GN9P9Fd_XisK1dsduYrrkjpGAvM0YJ_tUA@mail.gmail.com

At this point, I'm inclined to argue that Phobos should not depend on any libraries other than the system libraries for each OS so that we can avoid further dependencies that may not be available - especially when it comes to Windows, since Windows comes with no 3rd party development libraries at all. So, I would very much be against std.net.curl's inclusion at this point and would argue that it should be in a library separate from Phobos and that if we want similar functionality in Phobos, we need to implement it without relying on anything other than system libraries. And from previous discussions on the topic, I believe that Walter and several other dmd/Phobos devs agree with that.

So, I'm all for removing std.net.curl, but if we do that, we'd obviously need to deprecate it first rather than simply removing it, and we'd need to have a separate library with std.net.curl in it (preferably one which could be pulled in via dub) which people could switch to using instead. Whether that library would be maintained by us, by Jonas (since he created it), or someone else, I don't know, but ideally, it wouldn't be in Phobos any longer. At minimum, I think that we should avoid putting any more 3rd party dependencies in Phobos in the future.

- Jonathan M Davis

On 25.11.2013 8:38, 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

I'm for removing as I always compile Phobos without curl anyway (I don't want to install all dependencies).

-- 
mk