build: vendor bleeding-edge bolt-python wheel from main branch#11
build: vendor bleeding-edge bolt-python wheel from main branch#11
Conversation
Build slack-bolt from bolt-python main (837e120) with a PEP 440 local version identifier and check the .whl into vendor/. All three apps now install from the vendored wheel via requirements.txt instead of pinning to PyPI. Adds /project:update-bolt slash command for future updates.
mwbrooks
added
the
update
mwbrooks
left a comment
mwbrooks
left a comment
There was a problem hiding this comment.
Comments for the kind reviewers!
|
|
||
| ```sh | ||
| pip install -r requirements.txt | ||
| # or pip install -e . |
There was a problem hiding this comment.
question: went back and forth on whether to remove this or leave a comment. I fear we'll forget to add this back after we un-vendor Bolt
There was a problem hiding this comment.
@mwbrooks I think you made the right call here. We should keep README as correct as possible for what exists. It'd be so confusing otherwise to find incorrect instruction! 📠
zimeg
left a comment
zimeg
left a comment
There was a problem hiding this comment.
🧰 Another amazing changeset to land toward fast development! I think we should merge this but left a comment about findings we might encounter with updates...
Thank you for setting us up for success with this 🏆 ✨
| @@ -1,5 +1,5 @@ | |||
| slack-sdk==3.40.1 | |||
| slack-bolt==1.27.0 | |||
| ../vendor/slack_bolt-1.27.0+837e120-py2.py3-none-any.whl | |||
There was a problem hiding this comment.
🤖 issue(non-blocking): IIRC the kind @dependabot cannot update requirements.txt files that use a relative path. This happened to me with similar testing setups before but I'm not confident in this statement when vendoring the package to be honest...
Wanting to call this out here since we might find adjacent dependencies fall outdated, but I think the slash command included does more than enough!
There was a problem hiding this comment.
Thanks for the insight @zimeg!
Hmm... that's a bummer. I suppose we can merge it and if we find that @dependabot has trouble, then we can revisit it.
An alternative approach could be to have the Claude Code slash command install the vendored Bolt into each project using pip. This would allow us to use the production slack_bolt and then /project:update-bolt would overwrite it with the vendor copy.
|
|
||
| ```sh | ||
| pip install -r requirements.txt | ||
| # or pip install -e . |
There was a problem hiding this comment.
@mwbrooks I think you made the right call here. We should keep README as correct as possible for what exists. It'd be so confusing otherwise to find incorrect instruction! 📠
|
What insight! Thank you @zimeg! We can merge this and switch up our slash command approach if @dependabot is feelings a little blocked. I definitely think it's good to keep our dependencies up-to-date! |
2 participants
Summary
slack-boltfrom bolt-pythonmain(837e120) with a version and sha identifier (1.27.0+837e120) and checks the.whlintovendor/requirements.txtfiles to install from the vendored wheel instead of pinningslack-bolt==1.27.0from PyPIslack-boltin all threepyproject.tomlfiles (relative whl paths aren't reliably supported there)/project:update-boltClaude Code slash command for future updatesslack-boltREADME.mdwith install instructions and how to update Bolt PythonTest plan
pip install -r requirements.txtand confirmslack_boltinstalls from the vendored whlpython -c "from slack_bolt.version import __version__; print(__version__)"— should show1.27.0+837e120slack runto confirm the Slack CLI can install and start the appruff check .from an app directory to confirm linting passes