Should "std.net.curl" be moved from Phobos to Deimos?
Jonathan M Davis
jmdavisProg at gmx.com
Mon Nov 25 16:36:42 PST 2013
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
More information about the Digitalmars-d
mailing list