8000 Introduce a Depndency Lock File for Development · Issue #4796 · python-telegram-bot/python-telegram-bot · GitHub
[go: up one dir, main page]
Skip to content

Introduce a Depndency Lock File for Development #4796

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.

Sign up for GitHub

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

Jump to bottom
Open
harshil21 opened this issue May 22, 2025 · 4 comments
Open

Introduce a Depndency Lock File for Development #4796

harshil21 opened this issue May 22, 2025 · 4 comments
Labels
⚙️ documentation affected functionality: documentation 🔗 python related technology: python 📋 triage work status: triage

Comments

@harshil21
Copy link
Member

What kind of feature are you missing? Where do you notice a shortcoming of PTB?

Now that uv is well known and established in python community and adopted by many projects, we should consider using some more uv features in our repository.

Describe the solution you'd like

Here's what we can initially change:

  1. The CI for unit tests can use uv built python's, along with using uv commands to setup the job and install dependencies.
  2. Commiting the uv.lock file to the repo to increase reproduciblity across different machines.
  3. Using uv build instead of the build package in the CI.
  4. Using uv publish to release to pypi. They mention that it works through GH actions too, but I don't know how it plays with our specific setup, maybe @Bibo-Joshi can determine if it's a good enough fit.
  5. In the future, we could try using the uv build-backend too.

Another idea I had would be to provide a "demo" app, so one could do something like:

uvx python-telegram-bot echobot

and this would run echobot.py (we'd have to read the bot token from stdin or env var).

Describe alternatives you've considered

Not using uv and staying outdated

Additional context

I don't think it's worth replacing all mentions of pip install with something like uv add, but I think we should at least acknowledge the existence of uv in the readme/docs somewhere to encourage more adoption. What do you think?
@harshil21 harshil21 added ⚙️ documentation affected functionality: documentation 🔗 python related technology: python labels May 22, 2025
@Bibo-Joshi
Copy link
Member

Hi. Thanks for the issue. I'm a bit confused about the title though.

"Making PTB more UV friendly" sounds to me like you want to make it easier for uv users to work with PTB.
Here I would agree: If there are issues in e.g. installing PTB via uv, then it's reasonable to improve that.

The issue description however mostly reads like you want to replace PTB internal tooling/CI setup with uv. Here, I don't see a necessity. If switching to uv provides us with advantages for certain tasks, then I'm open to it. Doing it simply because uv is hip doesn't sound right. Note also that uv is still a pre-release (like all other astral products...)

@Bibo-Joshi Bibo-Joshi added the 📋 triage work status: triage label May 22, 2025
@harshil21
Copy link
Member Author

There's nothing hindering PTB to be installed via uv per se. I'll admit that the main reason I opened this issue is so we commit a uv.lock file. Currently, each one of us can have dependencies out of sync with each other. E.g. dependabot could update several library versions, and locally we could still be using some really old version. And when we test locally, we can get failures which are not reproducible in the CI, or vice versa.

That being said, if you commit a uv.lock, you'd want to make use of it. Which is why I also suggest using uv in the unit test CI at least.

There's no comparable lockfile feature in pip, even the newly standardized pylock.toml, is something pip will write to, but it won't use it to sync the environment, which sort of defeats the purpose imo.

I'm a bit confused about the title though

Yeah I should've been a little more explicit, I just meant using uv in our repository more. (the idea was using uv means you become friends with it 😄 )

Note also that uv is still a pre-release

I don't see that written anywhere in their docs. In fact they say that there's not really any goal which will make them release 1.0 -https://docs.astral.sh/uv/reference/policies/versioning/#versioning. There's many projects out there which follow a 0.x.y scheme, like httpx, fastapi, msgspec, etc. If a project being used by significant chunk of the community for this long doesn't count as at least semi-stable, I don't know what does..

@Bibo-Joshi
Copy link
Member

There's nothing hindering PTB to be installed via uv per se. I'll admit that the main reason I opened this issue is so we commit a uv.lock file.

Haha alright : ) propose that we focus on this here, then. I'll edit the issue title.

I can understand the reasoning for adding a lock file for development dependencies. However, it must be not be considered for the public dependencies. pip/uv install ptb must still be able to find versions matching against other requirements constraints in the environment. Moreover, because of the former, our CI tests should not use locked runtime dependencies. Otherwise the regular nightly tests could never pick up any compatiblity issues with new releases of depndencies.

Example:

  • Our requirements list httpx ~= 0.27
  • lock file locks to 0.27.1 and all CI runs against that
  • httpx releases 0.27.2 with introduces an incompatibility/bug
  • CI happly runs against 0.27.1 noticing nothing
  • We get bug reports from users or notice only once we upgrade to httpx ~= 0.28

Is my reasoning understandable?

There's no comparable lockfile feature in pip, even the newly standardized pylock.toml, is something pip will write to, but it won't use it to sync the environment, which sort of defeats the purpose imo.

I actually wasn't aware of pylock.toml so far. Nice to learn about it!
The pip-community apparently has already started working on support though pypa/pip#13334. There's also a dependabot feature request at dependabot/dependabot-core#12094.
If we want to use a lock file for our development and pip doesn't support it, but uv does, then this is a valid argument for using uv in our setup. I'm personally strongly in favor of using pylock.toml as language wide standard rather than uv.lock as tool-specific file. If it's important to us to introduce this lock file soon and we don't want to wait for dependabot to add support, I'd be open to using uv.lock as stand-in. In that case I strongly suggest to open a follow-up issue for switching to pylock.toml once all our tools support it.

there's not really any goal which will make them release 1.0 -https://docs.astral.sh/uv/reference/policies/versioning/#versioning.

Huh, I wasn't aware of that. Thanks for clarifying!

I think we should at least acknowledge the existence of uv in the readme/docs somewhere to encourage more adoption. What do you think?

IMO even before uv, pip install … in the docs had already to be understood as example. There are tons of ways to install python packages with different package/environment managers. Everyone who's aware of uv will know what to do. As long as pip is shipped with python, I personally don't see a need to advertise anything else. If this is important to you, I recommend to track it in a separate issue as not to mix it with the lock-file topic.

Another idea I had would be to provide a "demo" app, so one could do something like:

uvx python-telegram-bot echobot

and this would run echobot.py (we'd have to read the bot token from stdin or env var).

I'm don't quite see the benefit here, TBH. How would this help the user? They wouldn't even see the code. It would basically just show that PTB is indeed working, but I don't think we have to include a proof for that in the lib itself. As above, if you would like more discussion on this, please open a separate issue :)

@Bibo-Joshi Bibo-Joshi changed the title Make python-telegram-bot a little more uv friendly Introduce a Depndency Lock File for Development May 23, 2025
@JulesP83

This comment has been minimized.

Sign in to view
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
⚙️ documentation affected functionality: documentation 🔗 python related technology: python 📋 triage work status: triage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Bibo-Joshi @harshil21 @JulesP83
0