How to deal with crates trying to keep up with nightly (quasi)


#1

I’m hoping to use yup_oauth2 in a program. To that end I’m trying to build the device flow example.

Unfortunately this library seems to be in a bit of a pickle. One way or another it is dependent on quasi. When I try to build it on stable I get several errors, including:

   Compiling quasi v0.3.0 (file:///Users/tk/rust/rust-quasi/quasi)
src/lib.rs:112:58: 112:75 error: unresolved name `token::NtImplItem`
src/lib.rs:112         vec![ast::TtToken(self.span, token::Interpolated(token::NtImplItem(self.clone())))]

When I compare libsyntax token.rs for 1.0.0 and master I see that NtImplItem is a new enum value after current stable.

As best as I can tell Rust doesn’t yet have a way to conditionally compile code by rustc version.

What can I do to help resolve this situation? Has quasi jumped the gun by adding syntax from a newer version? Is it strange that an oauth2 library is depending on quasi? Is rustc letting us all down because we can’t handle versions of syntax? Many thanks for any tips!


#2

I think regular quasi is simply out of reach for the stable channel right now. It’s using some rustc internals which are not stable.

It does however have a feature flag by the looks of it, where it could be used in stable possibly – you need whatever depends on quasi to use this feature flag. As it stands now, yup-oauth2 is then not compatible with the stable channel. You could ask their developer, maybe they have a good idea about how / why / when stable can be supported.

Ideally, crates.io should have a simple label for which release channel a crate follows. Mine own follow stable & nightly.