Replies: 2 comments 2 replies
-
This is an interesting idea. Here's one trick that approximates your idea today: PATH= tea "+python.org~3.11" /bin/sh -c 'echo $PATH'
/Users/jacob/.tea/invisible-island.net/ncurses/v6.3.0/bin:/Users/jacob/.tea/gnu.org/readline/v8.1.0/bin:/Users/jacob/.tea/sourceware.org/bzip2/v1.0.8/bin:/Users/jacob/.tea/openssl.org/v1.1.1s/bin:/Users/jacob/.tea/libexpat.github.io/v2.5.0/bin:/Users/jacob/.tea/tukaani.org/xz/v5.2.7/bin:/Users/jacob/.tea/sqlite.org/v3.39.4/bin:/Users/jacob/.tea/python.org/v3.11.0/bin:/Users/jacob/.tea/tea.xyz/v0.21.4/bin |
Beta Was this translation helpful? Give feedback.
0 replies
-
If we are to continue “emulating And in the vein, PR welcome! Or we’ll add sometime soonish. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'd like to pitch an idea for improving the resilience of tea for deployments in remote environments.
Most scriptable deployment systems (e.g. GitHub Actions, Heroku, Render) have a set of pre-installed, arbitrarily versioned binaries (e.g. Python 3.10.9).
Maybe it makes sense for
tea
to offer a mode where the execution environment only contains the specified packages and nothing else. No locally installed binaries allowed as a fallback.So if I'm deploying to a remote server that comes with Python 3.10.2 preinstalled, but I'd like to ensure Python 3.11.x is used throughout my deployment process without falling back on 3.10.2, I should be able to do so by
--strain
ing mytea
:tea --strain +python.org~3.11 make # only tea's Python allowed
I recognize this might be a bit overly cautious or even unnecessary, but I do worry about my deployment environments getting muddied by mistake and breaking later on without knowing why.
Beta Was this translation helpful? Give feedback.
All reactions