[rust-dev] [ANN] libcurl bindings for rust (HTTP client at this point)

[Carl Lerche]

Hey all,

I've been working on libcurl bindings for rust. So far, I've only been
focusing on HTTP support. The goal is to provide a fully functioning
HTTP client that robustly handles all the edge cases needed in the
real world. I'm not trying to build the world's most amazing HTTP
client for rust. I'm hoping that one day a pure rust option will fill
that need.

In the mean time, curl-rust will satisfy your needs.

In case you don't know, libcurl (http://curl.haxx.se/libcurl/) is a
client-side URL transfer library supporting many, many protocols.
Hopefully, if anybody needs support for any of the other protocols
curl supports, I will see PRs for them!

Cheers,
Carl
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] [ANN] libcurl bindings for rust (HTTP client at this point)

[Carl Lerche]

And, it seems that I completely forgot to actually provide the link. I
need more coffee!

https://github.com/carllerche/curl-rust

On Wed, Jul 2, 2014 at 3:00 PM, Carl Lerche m...@carllerche.com wrote:
 Hey all,

 I've been working on libcurl bindings for rust. So far, I've only been
 focusing on HTTP support. The goal is to provide a fully functioning
 HTTP client that robustly handles all the edge cases needed in the
 real world. I'm not trying to build the world's most amazing HTTP
 client for rust. I'm hoping that one day a pure rust option will fill
 that need.

 In the mean time, curl-rust will satisfy your needs.

 In case you don't know, libcurl (http://curl.haxx.se/libcurl/) is a
 client-side URL transfer library supporting many, many protocols.
 Hopefully, if anybody needs support for any of the other protocols
 curl supports, I will see PRs for them!

 Cheers,
 Carl
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Announcing the new Rust package manager, Cargo

[Carl Lerche]

Strahinja:

We are definitely going to be smart with dependency resolution. We are
going to allow libs to specify their dependencies using semver
(http://semver.org/) as well as version bounds (for example, foo =
2.0.0 - any version of foo greater than 2.0.0, bar ~ 2.1.0, any
version of bar greater than 2.1.0 and less than 2.2 -- exact syntax is
still TBD). Ideally, if pulling in shared dependencies that satisfy
the bounds, only one version of the dep will be present (reduce binary
bloat). We should also be able to handle the incompatible transitive
dependency case by getting both versions of the library, like you
said.

Davis:

The term native library is pretty loaded, so hopefully I will be
able to answer your question.

First, we do not want to reinvent Make or apt-get. So, Cargo will not,
itself, be able to build C / C++ libraries nor will it be able to pull
in system packages (via apt-get, homebrew, etc...). However, it will
definitely be extensible. So, if you have C library dependencies that
you want to be able to compile, you can include a makefile and tell
cargo when and how to invoke it. Also, if you want to ensure that
certain system packages are present, you will also be able to tell
cargo when and how to do this.

As for moving cargo to rust-lang, that is the plan. We haven't done so
yet as we are still still in spike mode and code is pretty messy,
but we want to move it to rust-lang's github very soon.

Cheers,
Carl


On Tue, Mar 18, 2014 at 8:37 PM, Davis Silverman
sinistersn...@gmail.com wrote:
 This is great news! I wonder, what will the story be with native libraries?
 Will/could it be possible to package other dependencies, say, in C, to build
 also?

 Also, are there plans to move the repository to rust-lang?

 I'm extremely happy and can't wait to hear more. Thanks so much!


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev