Allow specifying diesel path as derive attribute

[Elrendio]

Resolves #4276

Good to know:

• Most diffs are from new indentation due to a second argument to wrap_in_dummy_mod
• I did not add the option on QueryId and the diesel_numeric_ops as these seems to be used in the table! macro and not in derive macros

Might I also suggest picking any import granularity (I however advise One) from the ones that can be automatically formatted by cargo fmt? See here available options

[Ten0]

Is there a downside to adding diesel itself to its own prelude instead?
It looks like this would solve the same issue (being able to use diesel as an indirect dependency) without requiring as much more code within diesel_derives, and without requiring more boilerplate in the caller's code.

[weiznich]

I don't think that would work. The import is currently use diesel which means we either need to have a direct dependency called diesel or a module with than name in the consuming crate root. Now assuming that someone want's to build a crate on top of diesel that reexports diesel's derives they would need to require that all consumer crates need to depend on the extension crate and diesel. Reexporting diesel from the extension crate wouldn't help as it needs to be done from the consuming crate.

[Ten0]

I don't understand what you mean.

we either need to have a direct dependency called diesel or a module with than name in the consuming crate root

Side note: it seems that a module won't work anymore.
That was the case at the time the comment in the existing code was written, but now we need extern crate self as diesel;.
That new writing doesn't even seem to require the use anymore so we probably want to update that comment and even remove that use.
That is:

mod y {
	fn f() {
		x::main();
	}
}

extern crate self as x;

fn main() {}

compiles.

But in addition to direct dependency and extern crate in the crate root, we can also resolve things that are explicitly brought in scope, including by a prelude. That is, the following code compiles:

mod y {
	use crate::prelude::*;

	use x;

	use x::main;
}

mod prelude {
	pub use crate as x;
}
fn main() {}

So it looks like adding pub use diesel; to the diesel::prelude would lead to every crate importing the derives via the diesel prelude (which is the most natural way to do so) to also get diesel in scope, in turn making the code expanded by the derives work, because it would then be able to resolve diesel.

This seems to be a simpler way to be able to use diesel as an indirect dependency than what is currently implemented in this PR. (Which is the goal of this PR.)

[Ten0]

Might I also suggest picking any import granularity (I however advise One) from the ones that can be automatically formatted by cargo fmt?

Unless I'm mistaken currently it is "module"