docs: discussion doc on alternative distribution mechanisms for the cli#709
docs: discussion doc on alternative distribution mechanisms for the cli#709aorumbayev wants to merge 3 commits intomainfrom
Conversation
Create a non formal .md file providing an analysis of options available to simplify algokit cli distribution to achieve the following: - Complex multi tool distribution pipeline that requires apple developer account, canonical account and dealing with winget which in result only gives the end user a binary that still would not handle python installation for them after they jump into ide where an algokit example or a template has been scaffolded. - Acknowledge that pyinstaller was the most mature thing available at the time of implementing binary mode support but as of 2026 a few alternatives are available. Option A -> go over the codebase check the .github folder check all brew winget and pyinstaller related code including the tests in pytest that only run on pyinstaller binaries. Asses what would need to change if we are to do a switch to https://github.com/aorumbayev/uvget or a system similar to that (a single bash for unix and pwsh for windows - that take care of not just tool install like uvx or uv tool insall put pulling the uv itself and pulling the required python version for algokit to function then install the alogkit from pip). This allows dropping brew winget snap and pipx and simmply provide this single command (along with uv tool install algokit) to everyone. But must be phased so initially uv based installation is introduced and all other installation options moved to legacy and are explicitly marked for removal in next major updated (make the point for we dont have to break and remove what already works instantly). How would we make it smooth for people who had algokit installed via brew winget and etc? Option B. we continue distribution of binaries BUT only via curl with gpg signed executables from gh releases by leveraging https://ofek.dev/pyapp/latest/. This removes brew winget snap but we are still dealing with binaries but pyapp does dynamic python resolution so evaluate if this is fundamentally inferior to the approach with option A. C. Leave it as is and continue distributions of binaries but change default pip installation from pipx to uv tool install Create a laconic, easy to read, easy to approach by engineers working on this codebase document that ouytlines the options for the team to decide in and md file commit that and complete the task
|
Option A sounds good with me. How do we currently handle Puya? It would be nice to align binary distribution. |
|
Option A sounds good to me as well. I like the idea of having uv handling the Python distributions. I'm still a little bit unsure about all the migration paths, but I am sure we can figure that out during the implementation. |
|
If I understood correctly the option A would allow us to replace the binary shipping with a bootstrap script that 1. installs uv, 2. installs python using uv and 3. installs algokit using uv, right? In that case this would allow us to get rid of PyInstaller, code signing, brew, snap and winget at once, I mean, to me this looks like a no-brainer (but I might be missing more than something) |
|
@lempira i pushed a commit updating that we agreed on option A, let me know if i can merge |
6736177 to
2324663
Compare
ADR for discussion on replacing and improving current distribution mechanisms