geodatafusion cli

[ratmice]

I was curious if anyone had made a geodatafusion cli, like the datafusion-cli crate which could potentially be added to the readme?
As far as I understand it the datafusion_cli crate doesn't have a geodatafusion feature, or LOAD statement like duckdb.

I suppose It wouldn't be hard to hack one out myself, maybe even just fork datafusion-cli and add the appropriate register call under #cfg(feature="geodatafusion")] but I wasn't sure if one existed? I guess that might be difficult to upstream back to datafusion-cli if geodatafusion lags behind on releases (which it kind of has to, since datafusion-cli is released from the same repo as datafusion itself).

[ratmice]

So, one thing to note is that datafusion-cli is one of those lib + binary combos I had forgotten about.

1. We could come up with a main.rs that calls register(), and links to datafusion-cli library (probably just copy main.rs).
2. Add some kind of libloading + inventory or typetag, dynamic loading of the registration mechanism to datafusion-cli then
   including a small cli adapter dynamic library in this repo?

Would either of these two options be preferred if I were to work on (I somewhat prefer the second since it'd be a tiny library and doesn't involve main.rs that would need to be updated as datafusion-cli changes)

If so I can experiment with patches for datafusion-cli?

Edit: at https://codeberg.org/ratmice/geodatafusion-cli
In order to just getting something working, I threw up a copy of the datafusion-cli/main.rs
with geodatafusion::register(). In order to do the one line change though I basically
had to rewrite a large section of the entire Cargo.toml. Because it builds from a workspace,
with workspace dependencies + path dependencies.

It works for lack of anything better, but it isn't really going to be any fun trying to keep it in sync with the original.

[kylebarron]

I don't think there's maintenance capacity right now to merge a CLI into geodatafusion itself, but as a separate crate it sounds great

[paleolimbot]

https://github.com/apache/sedona-db/tree/main/sedona-cli may be good reference (DataFusion the last time I looked didn't provide an easy way to reuse its internal utilities to make a CLI, so there's a bit of copying + modifying that has since diverged from what's in datafusion-cli.

[ratmice]

I made a PR on datafusion itself, to make reusing it's internal utilities easier (command line argument reuse, session construction).
This is now apache/datafusion#23466

If the PR goes through I feel like the registration process is simple enough that implementing the cli should be pretty low maintenance burden.
https://github.com/ratmice/datafusion/blob/cli_entrypoint_pr2/datafusion-cli/examples/cli-custom-udf.rs

#[derive(Debug, Parser, PartialEq)]
#[clap(author, version, about, long_about= None)]
struct CustomArgs {
    #[command(flatten)]
    cli_args: CliArgs,
    #[clap(long, help = "Register geodatafusion" action = clap::ArgAction::Set, default_value_t = true)]
    register_geodatafusion: bool,
}

fn main() -> Result<(), CliError>
    let args = CustomArgs::try_parse()?;
    let cli_session = CliSession::builder().with_args(args.cli_args).build()?;
    let ctx: &SessionContext = cli_session.session_context();
    if args.register_geodatafusion {
        geodatafusion::register(&ctx);
    }
    cli_session.run().await?;
}

It isn't clear this is going to help with SedonaDB cli, it's initialization process seems to be getting it's SessionContext from somewhere upstream (I haven't worked it out yet). But if there is any changes that would also help the SedonaDB cli situation, any input would be welcome.