Support Rust 1.31

[Leonid Ryzhyk]

Timely 0.9 builds with rust 1.32, but not rust 1.31. As far as I can tell, it is not using any important features available in 1.32, but not 1.31. The main issue seems to be that it uses the new syntax for module imports.

If I create a PR to restore 1.31 compatibility, will it be accepted and become timely 0.9.1?

The reason I care about one minor version so much is because RHEL (which is what our build farm runs on) currently supports 1.31. The build farm must work offline, so installing the toolchain with rustup is not an option.

[Leonid Ryzhyk]

Here is the proposed patch

diff --git a/communication/src/lib.rs b/communication/src/lib.rs
index 7af0714..b12d8e0 100644
--- a/communication/src/lib.rs
+++ b/communication/src/lib.rs
@@ -102,10 +102,10 @@ use serde::{Serialize, Deserialize};
 #[cfg(not(feature = "bincode"))]
 use abomonation::Abomonation;
 
-pub use allocator::Generic as Allocator;
-pub use allocator::Allocate;
-pub use initialize::{initialize, initialize_from, Configuration, WorkerGuards};
-pub use message::Message;
+pub use self::allocator::Generic as Allocator;
+pub use self::allocator::Allocate;
+pub use self::initialize::{initialize, initialize_from, Configuration, WorkerGuards};
+pub use self::message::Message;
 
 /// A composite trait for types that may be used with channels.
 #[cfg(not(feature = "bincode"))]
@@ -188,4 +188,4 @@ fn promise_futures<T>(sends: usize, recvs: usize) -> (Vec<Vec<Sender<T>>>, Vec<V
     }
 
     (senders, recvers)
-}
\ No newline at end of file
+}
diff --git a/kafkaesque/src/lib.rs b/kafkaesque/src/lib.rs
index 39ec51b..01ad1d2 100644
--- a/kafkaesque/src/lib.rs
+++ b/kafkaesque/src/lib.rs
@@ -13,7 +13,7 @@ use rdkafka::consumer::{Consumer, BaseConsumer, DefaultConsumerContext};
 use rdkafka::config::FromClientConfigAndContext;
 
 pub mod kafka_source;
-pub use kafka_source::kafka_source as source;
+pub use self::kafka_source::kafka_source as source;
 
 struct OutstandingCounterContext {
     outstanding: Arc<AtomicIsize>,
diff --git a/sort/src/lib.rs b/sort/src/lib.rs
index 0653a28..088e367 100644
--- a/sort/src/lib.rs
+++ b/sort/src/lib.rs
@@ -16,11 +16,11 @@ mod stash;
 mod batched_vec;
 mod swc_buffer;
 
-pub use lsb::Sorter as LSBRadixSorter;
-pub use lsb_swc::Sorter as LSBSWCRadixSorter;
-pub use msb::Sorter as MSBRadixSorter;
-pub use msb_swc::Sorter as MSBSWCRadixSorter;
-pub use swc_buffer::SWCBuffer;
+pub use self::lsb::Sorter as LSBRadixSorter;
+pub use self::lsb_swc::Sorter as LSBSWCRadixSorter;
+pub use self::msb::Sorter as MSBRadixSorter;
+pub use self::msb_swc::Sorter as MSBSWCRadixSorter;
+pub use self::swc_buffer::SWCBuffer;
 
 /// An unsigned integer fit for use as a radix key.
 pub trait Unsigned : Ord {
diff --git a/timely/src/lib.rs b/timely/src/lib.rs
index 192b43c..d3438b3 100644
--- a/timely/src/lib.rs
+++ b/timely/src/lib.rs
@@ -67,8 +67,8 @@ extern crate timely_communication;
 extern crate timely_bytes;
 extern crate timely_logging;
 
-pub use execute::{execute, execute_directly, execute_from_args, example};
-pub use order::PartialOrder;
+pub use self::execute::{execute, execute_directly, execute_from_args, example};
+pub use self::order::PartialOrder;
 
 pub use timely_communication::Configuration;
 
@@ -110,4 +110,4 @@ impl<T: Clone+'static> Data for T { }
 /// The `ExchangeData` trait extends `Data` with any requirements imposed by the `timely_communication`
 /// `Data` trait, which describes requirements for communication along channels.
 pub trait ExchangeData: Data + communication::Data { }
-impl<T: Data + communication::Data> ExchangeData for T { }
\ No newline at end of file
+impl<T: Data + communication::Data> ExchangeData for T { }

[Frank McSherry]

Sorry for the delay here. I'm away for the weekend but will try and figure out something for you here.

My understanding of the alternatives are:

1. Maintain some amount of forward compatibility so that future timely programs / commits can work against older Rust compilers.
2. Ask people pinned to older compilers to maintain their own forks.

I'm personally hesitant about 1. taking on maintenance burden for software I don't use (and to avoid features I would like to use, like the recent Box<FnOnce> upgrade). I'll chat it up with some local folks with more software maintenance experience than I have and see if I can get a read on the trade-offs.

If you have constraints that prevent option two, let me know!

[Leonid Ryzhyk]

I completely understand why you're reluctant to maintain backwards/forward compiler compatibility. Obviously, this is an extra constraint on your development process. The reason I hoped you'd consider it is because I feel it will be important for many others who, like me, want to use differential/timely in production environments. Even working with open source projects, I've encountered that people are reluctant to use rustup and demand that the software compiles with the version of Rust that comes with their distro. Likewise, it is a hard requirement in my company.

Regarding option 2. In cases like the one that started this thread, maintaining my own clone of differential is not a big deal; although I am not sure that using this slightly improved syntax is worth losing compiler compatibility. But once you start using new capabilities like Box<FnOnce>, I'm in trouble, as workarounds get much more complex and worst of all I'll have to keep patching timely/differential to keep up with your development.