The existing tk/tcl libraries seem to use inwelling to generate bindings https://github.com/oooutlk/tcltk/blob/main/tcl/src/lib.rs#L150-L159

If we switch to bindings, how do you think we go similar with those approach to avoid common pitfalls and find a shared point with them in future?

The existing tk/tcl libraries seem to use inwelling to generate bindings https://github.com/oooutlk/tcltk/blob/main/tcl/src/lib.rs#L150-L159

I took a look a while back, before writing custom crates. It seems inwelling is simply a manner for upstream crates to send information downstream. clib does the building and is just a thin wrapper around bindgen (https://docs.rs/clib/latest/clib/, and https://docs.rs/crate/clib/latest/source/build.rs).

Currently I have a few problems with this approach.

1. clib is used as a singular dependency to compile anything, and is depended on twice just by pulling in the tk crate (once for tcl, and the second time for tk). I'm not sure how well cargo handles this, seeing they both call clib with the same version etc.
2. I don't have raw API access, which I seem to need for much of this.
3. tk as well as other bindings I have considered all have a bug where Tcl_DecrRefCount and Tcl_IncrRefCount are not handled properly due to a bindgen limitation in terms of function macros.

I blacklist these macros here: https://github.com/arihant2math/tkinter/blob/d9874a8446cd32dfcd3e71b8e891329f304d2a3b/tk-sys/build.rs#L113

and re-implement them here: https://github.com/arihant2math/tkinter/blob/2957564c74fbb4f25b967f6ac1e2289ed04fd0c0/tk-sys/src/lib.rs#L7

Seeing that they crash the linker if included, unless patched, ... I doubt these libraries are handling memory management well.
Seeing that the right Free function isn't called either: https://github.com/search?q=repo%3Aoooutlk%2Ftcltk%20Free&type=code

If we switch to bindings, how do you think we go similar with those approach to avoid common pitfalls and find a shared point with them in future?

I think with bindings we will be able to mirror the cpython implementation well enough that most issues should be avoided. I think the current set of tk libraries aren't ready for something as broad as tkinter.

Also I would ideally have contributed to https://github.com/MisterEggnog/tcltk-rs, but it seems to be unmaintained and the author seems to be inactive.

Thank you so much for explanation

I don't have too much of a use for them, so I'll send a transfer request after I clean it up and add basic CI.

Also since I'm not an admin of the RustPython org, I'd have to transfer it to you first, and you can transfer it to the org.