Join forces with Briar GTK

Hey @fphemeral,

it's really nice to see another python client popping up! Thanks for working on it. I'm looking forward to play around with it!

When developing Briar GTK, I took care that I separated all the GTK code from the Briar headless wrapper code. You can see the separation at /src/briar/ as there exists a module for gtk and a module for api. What about if we combine forces and both use the same code for the api wrapper part?

We could create a new Git repository where I push that api wrapper part and where we work together on that part.

hej @nicoalt,

great idea!

using the same wrapper code and working on it together makes a lot of sense to me! do you envision the wrapper as a package pushed to pypi?

yes please give briar_repl a spin - I am curious to hear your thoughts on it!

Great!

do you envision the wrapper as a package pushed to pypi?

Yes, the wrapper would be a dependency we use like requests and websockets. It'll be written into requirements.txt and operating systems will create a package like python-briar-headless-wrapper that will be a dependency of both briar-gtk and briar_repl. That's what's on my mind

What do you think about the project name python-briar-headless-wrapper? We could ask if we get /briar/python-briar-headless-wrapper here on GitLab. On PyPi, I would call it briar-headless-wrapper.

yes please give briar_repl a spin

I'll do!

pypi package sounds good! python-briar-headless-wrapper is very desciptive. how about a shorter one like briar-wrapper ? for pypi the "namespace" python should be self-explanatory (I guess) but on code.briar and for operating systems clarifying the language might be helpful..

Yeah, briar-wrapper would most likely also do it. I don't think there is any other comparable api planned.

For PyPi of course we don't have to use that python prefix, but for GitLab and operating system I would use it as in the future there might pop up other briar-wrappers implemented in other languages.

@akwizgran @grote Are you OK with creating a GitLab project briar/python-briar-wrapper for us? If yes, could you make @fphemeral and me maintainers there?

Once the repo exists, I plan to push a fork of Briar GTK there and rip off all the GTK stuff. Is this OK for you, @fphemeral?

Sounds good! Feel free to create the repo. I'll set it to public and you both as maintainers once it exists.

@grote I would do, but I think I can't do so in the briar/ namespace.

Ah I missed the briar/ namespace. Since this is probably only meant for official projects, maybe let's wait for @akwizgran to chime in here. In the meantime though, you can already create the repo in another namespace and we move it later.

maybe let's wait for akwizgran to chime in here

Sure!

Maybe creating a group called e.g. World would be another good option? That's how they do it at GNOME: there exists a GNOME group for official stuff and a World group for community stuff. I would transfer my GTK client to such a group, as I don't need my name attached to it.

I'd be happy for this to be in the briar namespace. I'll create the project and add you both to the group.

I can also move the briar-gtk and briar_repl projects into the group if you like, or we can leave them in your personal namespaces if you prefer. Old links will redirect if they're moved, but IIRC git remotes need to be updated.

https://code.briarproject.org/briar/python-briar-wrapper

great, thank you so much @all! @nicoalt do you see the wrapper as sync or async? currently nearly everything in briar_repl is async. I know there are also dual mode libs, but I have no clue yet how they do it though..

@fphemeral

do you see the wrapper as sync or async?

I see it as async, in case that this means that we can call functions and it will not block the main thread. I.e., briar-wrapper should use those async stuff or create threads on its own and applications like briar_repl should not have to implement the async stuff around potential sync functions on their own.

I hope I understood this correctly

great then async it is!

collaboraion on briar-wrapper currently paused, due to gtk not playing well with python asyncio main loop, which is the async mode briar_repl is built on.

closed