The lib target gtars in package `gtars-r v0.5.0

A way to solve this is change the [lib.name] attribute in the gtars-r crate to gtars_r. Not sure what the consequences of this are, however

The problem with this is that extendr uses the package name in the DESCRIPTION file to generate wrappers that call useDynLib(gtars, .registration = TRUE) which means it looks for the gtars lib, but can't find it because we changed it to gtars_r. We can rename the R package in the description file to something like gtars.r or gtarsr and use this under [lib], but not gtars_r because only alphanumeric and . characters are allowed, or somehow keep it as gtars in the toml file

@sanghoonio gotcha thanks for the explaination. I think I am partial to gtarsr.... what do others think?

The consequence of this is that when you install and import you need to do this?

library(gtarsr)

? Thats a bit annoying it'd be nice to just do library(gtars). I have this problem with the wasm bindings too where you can't override the package name -- it just uses the crate name which is a non-starter since we cant call it gtars. Its a conflict and also just a bit confusing

For reference:

• pyo3 lets us rename the final python wheel using the pyproject.toml file.
• wasm-bindgen doesn't support it, but you can simply edit the package.json it spits out and then upload which is a really easy fix I suppose (Allow the user to fully customize the package name wasm-bindgen/wasm-pack#427)

So it'd be nice if everything was just gtars across environments. Right now I think we have a solution for everything:

• Rust: wrapper crate called gtars:

// cargo add gtars
use gtars::tokenizers::{Tokenizer};

• Python: python wheel called gtars:

# pip install gtars
import gtars

• Web/JS: package called gtars:

// npm i @databio/gtars
import { Tokenizer } from '@databio/gtars'

So R would be the odd-one out:

# install.packages("gtarsr")
library(gtarsr)

The gtarsr is definitely annoying, is there any reason we can't use gtars for the R package if we rename everything else?

The gtarsr is definitely annoying, is there any reason we can't use gtars for the R package if we rename everything else?

well the wrapper crate sort of needs to be called gtars I think that's important.

Ok I dont actually think the gtars_r thing is a problem, right? I think that its only really an issue if we intend to publish to crates.io, which we aren't planning on doing, nor does that make any sense. I guess put another way... because the R bindings are completely downstream of the core crates (gtars, gtars-core, gtars-refget, etc), it shouldnt actually be a problem.

Put another way... I think that we only would have a problem if we tried to import this crate alongside something else like gtars... think. As long as the package name can be gtars-r then the [lib.name] is safe to be named gtars.

I just tested it locally with rextendr::document() and it seems to work well