How to guarantee the sustainability of Rust crates ?!

community
22

For the most part, it's a first-come, first-served global namespace that guarantees that the delivered artifact for a given (crate name, version) pair never changes. Beyond that, caveat emptor applies.

Mostly, it's a lighter-weight way to return one of two different types than dyn Trait is. Generally, both L and R will implement some trait that you care about, like Iterator, so that Either<L,R> can also implement that trait. For example:

fn maybe_reverse<T>(
    items: impl DoubleEndedIterator<Item=T>,
    should_rev: bool
)->impl Iterator<Item=T> {
    if should_rev {
        Either::Left(items.rev())
    } else {
        Either::Right(items)
    }
}
5 Likes
23

Thanks for the reply.

What I was trying to illustrate is a general tendency of what is posted lacking documentation.
I understand this since one can be so close to a problem to be solved that one imagines that others should intuitively understand it. That and seer laziness.

24

In cases like Either, there is a fuzzy border between terseness and over-verbosity which is not easy to navigate and satisfy all audiences. If you're comfortable with the language, you understand without deep reflection that a) impl Trait in return position maps to a single type, b) various iterator chains are distinct types, and c) unifying them through trait objects can work, but adds indirection and the potential for suboptimal performance. If that's the case, and you've encountered the problem in practice, the value of Either will be nearly self-evident, and any extended description will seem superfluous or annoying. If not, it's easy to end up feeling at sea.

I don't have a solution, aside from appealing to all sides to at least recognize the problem and refrain from judging in absolutes in either direction. Giving feedback won't hurt, all the more so if it's not drenched in frustration.

5 Likes
25

Boost was created as a reaction to the near complete lack of progress in the C++ standard between 98 and 11, and the complete lack of any package registry.

Boost was created to be the "missing standard library" or at least a place to incubate additions to the standard library, with the implicit rebuke being that the standard library is incomplete. It has a central organization accepting and reviewing code to be added, has a common build and distribution system, and has a guiding principle to be code potentially useful for most any developer

Package registries are not at all the same thing. They're for anyone to share whatever code they like in a way that can be easily added by you or (importantly) by other packages on the registry, and to handle these all being released by different people in different schedules.

Of course quality is going to differ, of course there are going to be multiple packages that solve the same problem: creating a package involves only creating a crates.io account and calling cargo publish. Boom, everyone can use your code now. The trade off is that you get code to solve pretty much any problem against it being solved by pretty much any developer. Overall, this has been shown to be a resounding success.

3 Likes
26

I personally have found crates.io to have excellent quality software. This could be due to several factors, perhaps people put a lot of effort into what they publish, perhaps they are outstandingly good at writing software, perhaps the Open-source software model brings benefits, but I think it is also the underlying strength of Rust which encourages the production of reliable software. I think if you have a good design, to some extent the code almost "writes itself", and it tends to simply be correct because there wasn't any real way to go wrong ( an over-simplification, but it is uncanny how Rust code tends to simply "just work" ).

27

Yeah, it's certainly a much higher baseline than many other repositories, though to some extent just being a newer, smaller ecosystem means this would be more likely anyway.

I've published there though, so it can't be that good! :yum:

5 Likes
28

There is (or was?) a suggested section in Cargo.toml where the crate author can put things like this:

[badges]
maintenance = { status = "actively-developed" }

This would at least make it easy to distinguish between "throwaway crates" or early experiments and things someone at least claims to intend to maintain. It is even documented in the Cargo book but still not used by crates.io (or even lib.rs?).

3 Likes
29

It is also documented that crates.io used to display badges, but removed that (here's the issue for that) -- that information should go in the readme instead, which is rendered and user-controlled.

3 Likes
30

True, visual badges now belongs in the readme. But there can't be structured, queryable information in the readme, so the maintenence status remains at least documented.

Unfortunatley, the work on a better way to handle such status seems to have stalled (see e.g. #2437).

31

The ideal is to create a scheduling a job that allows you to read the dates of the last commits and the date of the last release, and to apply a formula like this:

if there is a new release in the last 6 months {
 * 0 commits in the last 6 months: inactive
 * 1 or more commits in the last 6 months: not very active
 * 1+ commits per month = active
} else {
 * inactive
}

for example, using Github's APIs :

curl -H "Authorization: token YOUR_PERSONAL_ACCESS_TOKEN" \
     -H "Accept: application/vnd.github.v3+json" \
     https://api.github.com/repos/{owner}/{repo}/commits

and why not be inspired by Lib.rs' functionalities ?

32

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.