3 ms·

Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that

by 1wd 10y ago

Thanks, but I still don't see where such guarantees are advertised. Also it's not really clear what "the nursery" is exactly. Where is it? Why is it called that? It sounds more like "not mature = ready for prime time = don't use this". According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different licenses, with zero obvious guarantees.

steveklabnik 10y ago
RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0. That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)
- 1wd 10y ago
  My point is researching all this puts a huge burden on (serious) users that would not be there for a big standard library. Currently the Rust approach seems quite problematic, but I think this can be solved. For example by an explicit guarantee pledged by the Rust team (or a related umbrella / organization / consortium / ...) for a certain set of libraries (platform / ecosystem / 2nd tier standard library extension / stdx / nursery / ...). I think it would be important to include in this pledge: * Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.) * Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.) * Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.) Or maybe this already exists and I'm just uninformed?
  - steveklabnik 10y ago
    It all exists, it's just not as advertised as it should be.
Manishearth 10y ago
Crates.io lists the authors as "The Rust Project Developers", and has the Rust libs team as an owner. The dependencies are almost all maintained by Rust libs team members or are otherwise trusted crates. https://crates.io/crates/regex https://crates.io/crates/regex (Regex moved out of the nursery a while back) The nursery is more of a "These crates are officially blessed and we wish to make them part of rust-lang, unless the community comes up with something better". The guarantees aren't advertised, they're known. We can do a better job of advertising this, some of the work this year is related to that.
- 1wd 10y ago
  Sorry, I meant the author and license of e.g. this dependency of regex: https://crates.io/crates/aho-corasick https://crates.io/crates/aho-corasick I'm sure the Rust team knows and trusts these (or they even are Rust team members), but how should outsiders know this? Researching trustworthiness of individual authors, getting approval for different licenses, tracking and updating required notices in documentation etc. for every single dependency transitively(!) seriously takes a lot of effort. Updating dependencies that switch sub-(sub-...)-dependencies freely can turn from a simple cargo command into a month of work. A big standard library (or an equivalent construct) can really save the day there. > The guarantees aren't advertised, they're known. It is known. -- Jhiqui Glad to hear improving this is in the works anyway.

by 1wd 10y ago

steveklabnik 10y ago

RFCs are frozen in time; regex has since moved under rust-lang, and has a pre-release for a 1.0. That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)

1wd 10y ago
My point is researching all this puts a huge burden on (serious) users that would not be there for a big standard library. Currently the Rust approach seems quite problematic, but I think this can be solved. For example by an explicit guarantee pledged by the Rust team (or a related umbrella / organization / consortium / ...) for a certain set of libraries (platform / ecosystem / 2nd tier standard library extension / stdx / nursery / ...). I think it would be important to include in this pledge: * Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.) * Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.) * Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.) Or maybe this already exists and I'm just uninformed?
- steveklabnik 10y ago
  It all exists, it's just not as advertised as it should be.

Manishearth 10y ago

Crates.io lists the authors as "The Rust Project Developers", and has the Rust libs team as an owner. The dependencies are almost all maintained by Rust libs team members or are otherwise trusted crates. https://crates.io/crates/regex https://crates.io/crates/regex (Regex moved out of the nursery a while back) The nursery is more of a "These crates are officially blessed and we wish to make them part of rust-lang, unless the community comes up with something better". The guarantees aren't advertised, they're known. We can do a better job of advertising this, some of the work this year is related to that.

1wd 10y ago
Sorry, I meant the author and license of e.g. this dependency of regex: https://crates.io/crates/aho-corasick https://crates.io/crates/aho-corasick I'm sure the Rust team knows and trusts these (or they even are Rust team members), but how should outsiders know this? Researching trustworthiness of individual authors, getting approval for different licenses, tracking and updating required notices in documentation etc. for every single dependency transitively(!) seriously takes a lot of effort. Updating dependencies that switch sub-(sub-...)-dependencies freely can turn from a simple cargo command into a month of work. A big standard library (or an equivalent construct) can really save the day there. > The guarantees aren't advertised, they're known. It is known. -- Jhiqui Glad to hear improving this is in the works anyway.