slackapi
uv instead of pip for Python guides
Hey @sin4ch! 👋 Thanks for starting this discussion.
While I agree that uv is a fantastic tool I am not certain that it comes included with the standard set of Python tooling, so we might hesitate to include this as part of #777.
Let's still keep this issue open since such a recommendation is popular in other packages at a quick glance:
- https://github.com/langflow-ai/langflow
- https://github.com/modelcontextprotocol/python-sdk
I'm also so curious to know of additional configurations also needed to recommend uv usage for this package? 👾
Hi, @zimeg.
So, uv works like an add-on to pip, just that it makes it significantly faster, with reports showing that it's up to 10-100x faster (see here).
From what I have seen from the docs, it should work pretty well given that the changes required to add it on aren't even that cumbersome (in 'nearly' all cases, it's as simple as just adding uv in front of the pip command).
I understand the hesitation but it's worth the shot in my opinion. I'll be glad to work on this to show a PoC.
Lemme know what you think.
The goal of #777 was to somehow centralize the setup steps of Bolt projects
We currently inform developers to run these 3 commands in various areas of our documentation and in all our sample projects
$ python3 -m venv .venv
$ source .venv/bin/activate
$ pip install -r requirements.txt
Having a source of truth for these steps and using it as a reference across our documentation ensures consistency and correctness.
As @zimeg mentioned uv seems like a fantastic tool, but I don't think using it instead of pip would solve the issue. We would still need to document how to install UV and how to use it with Bolt across all our documentation surfaces
I totally get you, @WilliamBergamin, and I'm not trying to use uv to solve the dependency referencing/centralization issue. I only referenced #777 since it was referencing using pip across the docs.
What I'm suggesting is this: instead of implementing the centralization "for" pip, I suggest we implement it for, not with, uv, so that all the places where pip is mentioned across the doc surfaces and sample projects, uv is used instead.
I don't know if you get my point.
Maybe referencing that issue was a bad choice for the point I wanted to drive. Sorry about that.