Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System tdlib #119

Closed
jugendhacker opened this issue Aug 3, 2020 · 6 comments
Closed

System tdlib #119

jugendhacker opened this issue Aug 3, 2020 · 6 comments
Labels
wontfix This will not be worked on

Comments

@jugendhacker
Copy link

I'm currently trying to package this lib for the Arch User Repo. And I just noticed that you use your own build of tdlib which is not that nice because it's not possible to verify if it was build from the original source or not. Also it is redundant if multiple applications on the system use tdlib. So I'm trying to find out if I could get this lib to use the tdlib already provided by the system. Is this possible?

@alexander-akhmetov
Copy link
Owner

alexander-akhmetov commented Aug 5, 2020

Hi, sure, you can use any tdlib, you need to pass path to the tdjson library when you initialize the Telegram instance:

td = Telegram(
    ...
    library_path='path/to/libtdjson.so',
    ...
)

If the path is not specified, the library uses the built-in version, otherwise it uses the specified file:

https://github.com/alexander-akhmetov/python-telegram/blob/master/telegram/client.py#L113
https://github.com/alexander-akhmetov/python-telegram/blob/master/telegram/tdjson.py#L22

@jugendhacker
Copy link
Author

But that does not really help for packaging here, because for a system package the path should be set inside the lib.

@alexander-akhmetov
Copy link
Owner

The main reason behind using the built-in version is that it works out of the box in most cases.

If you want to create a package for AUR and use the shared library instead of the built-in, changes are required. I'm not sure what would be the best solution here, but we should keep the standard working out-of-the-box behaviour.
You could create a specific (for your package) patch, and apply it before packaging. It might cause problems if something changes in this part of the code, but only for package maintainers (you will have to update the patch), and existing package versions will work. Another way could be to change the library and use find_library from ctypes, but it requires more work.

@jugendhacker
Copy link
Author

Okay I patched the AUR to use find_libary for now. You can find the diff here

@alexander-akhmetov
Copy link
Owner

That's great, thank you! By the look of it, should be straightforward to fallback to find_library if there is no binary, and as a second step release two versions of the library, for those who wants to use their own or system tdlib. I'll keep the issue open for now for the first part of changes.

@stale
Copy link

stale bot commented Nov 25, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Nov 25, 2021
@stale stale bot closed this as completed Dec 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants