1. 23
  1.  

  2. 2

    Why is it the http crate 603?

    1. 17

      That’s the new HTTP return code that means “Rewrite in Rust”.

    2. 2

      And this is why lacking package namespacing is such a bad idea: https://crates.io/crates/http

      (Told you so, I guess.)

      1. 16

        And this is why lacking package namespacing is such a bad idea: https://crates.io/crates/http

        If you take a look, seanmonstar - one of the authors of http - is a co-owner and the http crate will be published there.

        Not using namespacing is entirely intentional. The other option would be to have a fragmentation of multiple packages called http, all with different prefixes. Especially the http crate is meant to be a center-piece of the ecosystem and wouldn’t live any better in a namespace then somewhere else.

        We’ve been there: Github had a namespaced gem host for a longer time and it lead to fragmentation within the ecosystem very quickly (“which fork of $x are we currently using”?). There are many large ecosystems without namespacing out there (gems, npm) and it is rarely a problem.

        But that discussion has been had - multiple times - and the only thing we could do is rehashing.

        (Told you so, I guess.)

        Let me be as blunt as you are: Your guess is wrong. And smug.

        1. 4

          Not using namespacing is entirely intentional. The other option would be to have a fragmentation of multiple packages called http, all with different prefixes. Especially the http crate is meant to be a center-piece of the ecosystem and wouldn’t live any better in a namespace then somewhere else.

          Is there a suggested approach for private crates? For example for companies.

          1. 7

            It’s not hard to run your own crate host (currently, that’s a bit of manual work or feasible, but making that better is wanted).

            crates.io is fully public and not a commercial service.

            Also, cargo understands git dependencies and can put multiple crates in a repository, which is what I usually use.

            1. 1

              It’s not hard to run your own crate host (currently, that’s a bit of manual work or feasible, but making that better is wanted).

              Would that custom crate host work as a proxy to crates.io? Or just another host? I’m thinking that it’s useful to have access to crates.io but host some crates on custom host…

              Also, cargo understands git dependencies and can put multiple crates in a repository, which is what I usually use.

              Just like npm dependencies can use git URLs? Great! That solves a lot of cases for me.

              Thanks!

              1. 7

                Would that custom crate host work as a proxy to crates.io? Or just another host? I’m thinking that it’s useful to have access to crates.io but host some crates on custom host…

                Mostly, cargo retrieves a flat-file manifest, then does the resolution locally and then hits our download host. So proxying doesn’t make that much sense, unless you want to publish to crates.io, too. I would run a mirror if I had to.

                The process of setting up a mirror is explained in detail here: http://www.integer32.com/2016/10/08/bare-minimum-crates-io-mirror-plus-one.html

                1. 1

                  That’s exactly what I needed, thanks.

                  1. 6

                    I should also mention that in general, we’re working towards making this easy, it just takes time to design, like anything else. See https://github.com/rust-lang/rfcs/pull/2006 for example.

                    1. 3

                      Excellent, I’m glad that this is considered. The process transparency with Rust’s RFCs is really impressive.

          2. 6

            If you take a look, seanmonstar - one of the authors of http - is a co-owner and the http crate will be published there.

            I’m kind of surprised that you assume that I haven’t checked this. I did, and the fact Rust team got lucky this time changes absolutely zero about the fundamental issue.

            • Crates.io prides itself with >10.000 “crates in stock”.
            • Most English speakers have a vocabulary size of 15.000 to 20.000 words.

            This means that practically every “obvious” noun that one can think of has already been claimed by someone.

            What happens the next time the Rust team wants to use some “nice” name?

            Will Rust devs ask nicely? What happens when the person who claimed the name is not reachable anymore, or doesn’t want to relinquish the name? Will the Rust team just commandeer that person’s crate?

            fragmentation within the ecosystem […] (“which fork of $x are we currently using”?)

            That pain is completely manageable compared to the pain of having to change every single file in a project just to swap out one version of a library with some fork of it (for instance to check whether some bug has really been fixed).

            There are many large ecosystems without namespacing out there (gems, npm) and it is rarely a problem.

            npm introduced namespaces in 2015.

            Let me be as blunt as you are: Your guess is wrong. And smug.

            I think it’s only a matter of time until Rust comes around. I’m happy to remind you when it happens.

            1. 7

              | I think it’s only a matter of time until Rust comes around. I’m happy to remind you when it happens.

              The possibility you might be right in the future doesn’t make you less smug right now.

              1. 0

                So as soon as I’m proven right, it’s not considered smug anymore? Following that reasoning, I’d like to settle my smugness debt with prior cases of me making a prediction and being right. :-)

                1. [Comment removed by author]

                  1. 1

                    No, I’m just kidding. Jesus.

              2. 6

                What happens the next time the Rust team wants to use some “nice” name?

                We play by the same rules as everyone else.

                That pain is completely manageable compared to the pain of having to change every single file in a project just to swap out one version of a library with some fork of it (for instance to check whether some bug has really been fixed).

                You don’t need to do this, you use an override or [replace], it’s one/two line(s) in Cargo.toml.

                1. 2

                  Or an “extern crate foo as bar” in {mod,lib}.rs. Either technique is strictly more flexible than relying on a forked version of a library retaining the same name under a different namespace.

                  1. 1

                    So there is already some half-baked namespacing mechanism, it’s just that everyone has to roll their own when required?

                    1. 4

                      I don’t think of it as having anything to do with namespacing, personally.

                  2. 5

                    I did, and the fact Rust team got lucky this time changes absolutely zero about the fundamental issue.

                    Great job on the timing of the “I told you so”.

                    What happens the next time the Rust team wants to use some “nice” name?

                    If they can’t, they can’t. Meh. The Rust team doesn’t get special privileges here. Like everyone else, they have to come up with a new crate name each time. It’s not hard.

                    If someone goes and squats a million crates there’s a chance the team may undo that, but in general if a crate is taken it’s taken.

                    It’s not really considered a major problem, and really namespacing doesn’t solve that problem much either. It solves it to the extent that Rust gets a namespace for “official” stuff, but not really for anyone else.

                    Most English speakers have a vocabulary size of 15.000 to 20.000 words.

                    Your math assumes single word crates; most crates are two words.

                    Doing a quick grep, only half the crates (almost exactly half actually) use only alphanumeric characters in their names (Rust crates use - or _ often for multiword crates). On top of that there are plenty of two word crates with the names mushed together.

                    When a crate name can be more than just a single noun, you still have plenty of possibilities.

                    the pain of having to change every single file in a project just to swap out one version of a library with some fork of it

                    [replace] and [patch] exist. http://doc.crates.io/manifest.html#the-patch-section

                    1. 2

                      Rust crates use - or _ often for multiword crates

                      I do wish Cargo had disallowed one or the other before the 1.0 ship set sail. The community seems to have standardized on - as a separator in the package name that goes in Cargo.toml and _ for the actual crate name, but it’s not universal.

                      I suppose it wouldn’t be too late to transparently make - and _ equivalent as far as Cargo/Crates.io are concerned, if there are no actual instances of published crates whose names would clash given a global replacement one way or the other.

                      1. 1

                        I thought there was an issue open for this, but cannot find it.

                        I agree wholeheartedly.

                        1. 1

                          I suppose it wouldn’t be too late to transparently make - and _ equivalent as far as Cargo/Crates.io are concerned,

                          So:

                          • Crates.io considers them to be the same when uploading crates
                          • Rustc will always see crate names with hyphens converted to underscores

                          (So there are no clashing crate names)

                          However, I think you still have to get the crate name correct when describing it as a dependency in Cargo.toml.

                          This is probably a straightforward fix in Cargo itself, with no backwards compatibility risk. I’d be willing to help push this through (or mentor folks who want to work on an rfc for this)

                        2. 1

                          If someone goes and squats a million crates there’s a chance the team may undo that, but in general if a crate is taken it’s taken.

                          I know that “a million” is just hyperbole, but it’s already the case that people have claimed dozens of very common names for seemingly no other purpose than “owning” them.

                          1. 1

                            Which is fine. Let them have fun.

                      2. 2

                        Github had a namespaced gem host for a longer time and it lead to fragmentation within the ecosystem very quickly (“which fork of $x are we currently using”?).

                        This is just a variation of “Which X are we currently using?” You’ve traded namespaces + common names for no namespaces + creative names. By going with creative names and no namespaces, you’ve made discoverability harder without a lot of benefit.

                        1. 4

                          Since this was reverted, it has become more common again to contribute back. The problem was that everyone ran their own fix with their own bugfix.