Paste alternatives

1

I just learned that paste is unmaintained. This crate is one of the top 200 downloaded crates from crates.io so this is pretty sad.

I am wondering what people propose to use as an alternative.

My use case is quite simple, I have a simple declarative macro that defines a new enum struct that can hold a number of different types (one variant per type). The user only specifies the types and the macro generates the variant names (the user doesn't really care about the names). So I do it recursively and use paste to recursively construct unique variant names. A simplified version would look like this:

use paste::paste;

macro_rules! enum_storage {
    ($($Types:ty),+) => {
        enum_storage!($($Types),+;; V);
    };
    (
        $Unnamed1:ty $(, $UnnamedTail:ty)*;
        $($Variant:ident($Type:ty)),*;
        $VariantName:ident
    ) => {
        paste! {
            enum_storage!(
                 $($UnnamedTail),*;
                 $($Variant($Type),)* $VariantName($Unnamed1);
                 [<$VariantName v>]
            );
        }
    };
    (; $($Variant:ident($Type:ty)),+; $VariantName:ident) => {
        enum TypeEnum {
            $($Variant($Type)),+
        }
    };
}

The idea is that a call like enum_storage!(u64, u32, String); should generate something like:

enum TypeEnum {
    V(u64),
    Vv(u32),
    Vvv(String),
}
1 Like
2

I'm curious on why do you need the alternative? This crate looks like it is, well, finished, without any need for actual maintenance - the only possible problem I could think of is it being broken by some unanticipated borrow-checker limitation, but given the nature of code in the crate (namely, it being only some token-generator, with the whole code logic created by the caller), this sounds highly unlikely.

6 Likes
3

Very good question. I think one drawback of using an unmaintained dependency is if this dependency would ever have a bug nobody would fix it. I see that the risk of this for something like paste is probably low, but who knows.

Also the second drawback is that cargo audit gives me a warning that I don't like :stuck_out_tongue:.

4

There are two issues with this:

  • you're assuming that if it was maintained "in name" the issue will be fixed, often this is not the case;

  • you're assuming you can't just fix the issue yourself.

You can simply ignore it in the audit.toml, effectively recognizing that it is not a critical issue for you.

4 Likes
5

this kind of argumentation doesn't make any sense nor helps with that OP asked.
Having a crate that may not be officially unmaintained hasn't any relation with what the OP asked for, nor can any paste end user fix a bug if it occurs inside paste itself.

paste is a very popular crate with 19,089 dependent crates. I'd say there probably should be a community effort to maintain it again.
As I am not experienced in these kinds of situations nor with paste code, does anyone have a suggestion on how can we followup on this?
Thanks!

6

I'd say it has, since the question essentially is "does this "unmaintainted" label mean anything bad for me?", and this answer is "well, it's not worse then "unmaintained without label"".

Forking is always an option. And for unmaintained dependencies, that's sometimes the expected option.

7

I have created pastey which is the fork of paste. It also provides some additional features that paste crate lacks:

  1. Generate Raw Identifiers - I am working on adding this functionality, 99% done. I have https://github.com/AS1100K/pastey/pull/8 opened in my repo. Will be merging it soon
  2. lower_camel case conversion More Info at https://github.com/AS1100K/pastey/issues/4
  3. camel_edge case conversion More Info at https://github.com/AS1100K/pastey/issues/3

Since dtolnay said in Create advisory for unmaintained `paste` crate by AS1100K · Pull Request #2215 · rustsec/advisory-db · GitHub , paste is finished and polished crate, and suggested that my crate should be vetted by someone that wants additional behaviour that isn't supported by paste crate.

Since, I have created a new crate pastey, I am looking into building it as a drop-in replacement for paste while also providing additional features.

paste crate could break in future (rare to happen for a long time), or could have bugs that will not be listened or new feature request, that won't be coming. For this you need use an alternative to paste crate.

I was the one that opened the PR in rust advisory that paste crate is unmaintained, but I didn't saw any alternatives to the paste crate as what I believe is there might be some features introduced in future that will never be supported by paste. This is when I took matters into my own hands and created pastey.

If you want to use a maintained crate or some additional behaviours that aren't supported by paste, you should use pastey as an alternative.

Sorry for having links inline but I couldn't add more than two links in the post, since my account is new on rust forum

8

I wish that systems like RustSec would not lump all cases like this into one classification of “unmaintained”, for two reasons:

  • Some code is in fact “done” and will almost certainly not need further changes. (This hypothesis can be falsified, but so can any claim that a library is actively maintained.)

  • In build-time libraries like paste, other macros, or build script helpers, if a bug is discovered then it will almost certainly only affect new code using it; therefore, the discoverer of the bug is also in a position to switch to a fork or whatever. This is different from bugs in code that interacts with run-time data, which can have direct vulnerabilities or non-compliance with a standard, where a transitive user of the code can provide new input that triggers a previously undiscovered bug.

7 Likes
9

In particular, dependabot freaking out that, eg, the xml parser used as a dependency of a build script that talks to trusted API has a DOS vulnerability is pretty annoying.

I don't know how this should be fixed though, every simple answer has a million little asterisks...

5 Likes