Tea

统一包管理器（brew2）

Package Manager
teaxyz/clitea.xyz/

README

tea

tea 不是包管理器。

tea 是统一的包基础工具.

从[brew]的创建者那里，tea是一个面向所有人的独立二进制下载让整个开放的平台源生态系统触手可及。轻轻松松地使用最新并且从任何堆栈的任何层中最大或最古老和最成熟。打破在编程社区之间的筒仓中使用完全独立的工具和语言，并与世界共享一个简单的单线。

你只需要 tea.

 

tea 是v1之前的。这意味着在日常使用中可能仍有一些粗糙的边缘。

这也意味着你绝对应该参与其中。这是关键。

参与其中的黄金时期既简单又有趣。我们非常期待与您见面 👊


 


tea/cli 0.18.1


开源是一个宝库，但这些都加了锁
tea 是key:

  1. ```sh
  2. $ tea +rust-lang.org

  4. tea: installing rust-lang.org and 13 other packages into a temporary sandbox
  5. when done type: exit

  7. tea $ cat <<EOF >hello.rs
  8. fn main() {
  9.   println!("Hello World!");
  10. }
  11. EOF
  12. $ rustc hello.rs -o hello
  13. $ ./hello
  14. Hello World!

  16. tea $ exit

  18. $ rustc
  19. command not found: rustc
  20. ```

tea 不安装软件包，至少在传统意义上不是这样。它们在 ~/.tea†中. 您的系统保持原始状态，并与tea’s的活动隔离。 但当你需要的时候，一切都在那里。

† 最后是一个包管理器，其中所有的包都是可重定位的（应该是这样的）。


tea 流水线


tea’s 的 +pkg 语法让整个开源生态系统触手可及，如果您在+pkg处停止，则会发生上述情况，我们将在环境中打开一个带有这些包的新shell，但如果您继续键入，则可以构造直接使用:

  1. ```sh
  2. $ tea +nodejs.org npx --yes browser-sync start --server
  3. # ^^ one-liner to start a local web server with live reload

  5. $ sh <(curl tea.xyz) +nodejs.org npx --yes browser-sync start --server
  6. # ^^ same one-liner but works for anyone on the Internet
  7. # (if tea is already installed, it uses it, if not it *doesn’t* install tea,
  8. #  a temporary sandbox is created)
  9. ```

像UNIX一样，组合一切，组合一切设想的。这将我们引向tea 流水线:

  1. ```sh
  2. $ tea +gnu.org/wget wget -qO- tea.xyz/white-paper | tea +charm.sh/glow glow -
  3. ```

这个例子下载了我们的白皮书，并使用[charm]’s 出色的发光终端markdown渲染器进行渲染。这是一个基本的示例，但UNIX受到包管理器的限制太久了。这是tea设计要克服的一个基本限制。

值得注意的是，使用-X语法可以更简洁地表达:

  1. ```sh
  2. $ tea -X wget -qO- tea.xyz/white-paper | tea -X glow -
  3. ```

其他示例

现在是202x，显然我们也可以从互联网下载脚本:

  1. ```sh
  2. $ sh <(curl tea.xyz) +charm.sh/gum https://github.com/charmbracelet/gum/blob/main/examples/demo.sh
  3. ```

想试用最新版本的node，但不确定它是否适用于您的项目tea很容易
  1. ```sh
  2. $ tea +nodejs.org^19 npm start
  3. ```

  5. 创建react应用程序的一行代码：

  7. ```sh
  8. $ sh <(curl tea.xyz) -X npx create-react-app my-app
  9. ```

  11. </details>

  13. ### 马上就来

  15. tea 流水线 是如此有趣，我们打算专门为它们展示。

  17. &nbsp;


  20. ## tea: 通用解释程序

  22. ```sh
$ tea https://gist.githubusercontent.com/i0bj/2b3afbe07a44179250474b5f36e7bd9b/raw/colors.go --yellow
tea: installing go 1.18.3
go: installing deps
go: running colors.go
…
  1. ```

  3. 在这个基本示例中，我们知道首先根据文件扩展名安装`go`。很明显，对吗？这就是为什么我们没有停下来:

  5. ```sh
$ tea favicon-generator.sh input.png
tea: installing image-magick, optipng, guetzli and 3 other packages…
…
output: favicon-128.png…

$ cat favicon-generator.sh
#!/usr/bin/env tea
#---

args: [/bin/sh, -e]

dependencies:

    imagemagick.org: 4

    optipng.sourceforge.net: 1

#---

[snip…]
  1. ```

  3. tea读取文件的YAML前端内容，允许您在整个开源生态系统中滚动脚本、gist和一行程序。当脚本运行时，它的环境中有这些依赖项，但系统的其他部分永远不会知道这些依赖项。

  5. 我们还知道更多的魔法:

  7. ```sh
$ tea -X node
tea: installing node@18.9.1
Welcome to Node.js v18.9.1.
Type ".help" for more information.
>
  1. ```

  3. 通常，`tea`对包使用完全限定的名称，但我们知道他们提供的工具，所以只要你知道你在寻找什么工具，我们就可以解决剩下的问题。

  5. Notably if you create a symlink of `foo` to `tea` (or `tea_foo`) we will
  6. interpret that as `tea -X foo [args…]`, yet another way using `tea` can be
  7. completely transparent to your everyday workflows.

  9. Even better, you can include semver ranges in your link name, so `ln -s tea node^16`
  10. will let you run `node^16` via the symlink of the same name. For even, even more
  11. goodness, we will follow a symlink one deep to see if a base link goes to a versioned
  12. link. Example:

  14. ```sh
$ ln -s tea /usr/local/bin/node^16
$ ln -s node^16 /usr/local/bin/node
$ node --version
v16.19.0
  1. ```

  3. Some tools, like `python` expect versioned binary names as well. `python.org` provides
  4. `python`, `python{{version.major}}` and `python{{version.major}}.{{version.minor}}`,
  5. so `ln -s tea /usr/local/bin/python3` works as expected, but this provides an equivalent
  6. method for achieving this if not provided by the package, via:

  8. ```sh
$ ln -s tea /usr/local/bin/python^3
$ ln -s python^3 /usr/local/bin/python3
  1. ```

  3. > ### Coming Soon
  4. >
  5. > ```yaml
  6. > ---
  7. > dependencies:
  8. >  nodejs.org: 19
  9. >  npmjs.com:
  10. >    package.json:
  11. >      dependencies:
  12. >        react: ^18
  13. > ---
  14. > ```

  16. &nbsp;


  19. ## tea: the universal virtual‑environment manager

  21. ```sh
$ deno
zsh: command not found: deno

$ echo $PATH
/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin

$ cd my-project
$ deno
tea: installing deno.land^1.22
deno 1.27.0

^D


$ env
PATH=~/.tea/deno.land/v1.27.0/bin:/usr/bin:/bin
SRCROOT=/src/my-project
VERSION=…
…
  1. ```

  3. > <details><summary><i>What is this sourcery?</i>summary><br>
  4. >
  5. > tea uses a shell hook to insert the precise tooling your project needs into
  6. > your shell environment. Development is now containerized at the
  7. > *package manager* level. No longer do you need to worry about your team
  8. > being on different versions of foundational tooling nor do you need to worry
  9. > about system level updates breaking different projects you’re working on.
  10. >
  11. > There are thousands of version managers for the thousands of tools they
  12. > support. Probably it’s time we stopped that duplicated effort.
  13. >
  14. > Projects can specify precisely what they need and you can install those
  15. > requirements precisely be it today, tomorrow or in ten years.
  16. >
  17. > In the above example if `deno` is not yet installed we insert a hook so
  18. > trying to execute it will install it first.
  19. > </details>

  21. > <details><summary><i>PSA:</i> Stop using Dockersummary><br>
  22. >
  23. > Docker is great for deployment and cross compilation, but… let’s face it: it
  24. > sucks for dev.
  25. >
  26. > *Docker stifles builders*.
  27. > It constricts you; you’re immalleable; tech marches onwards but your docker
  28. > container remains immobile. *Nobody knows how to use `docker`*. Once that
  29. > `Dockerfile` is set up, nobody dares touch it.
  30. >
  31. > And let’s face it, getting your personal dev and debug tools working inside
  32. > that image is incredibly frustrating. Why limit your potential?
  33. >
  34. > Keep deploying with Docker, but use tea to develop.
  35. >
  36. > Then when you do deploy you may as well install those deps with tea.
  37. >
  38. > Frankly, tea is properly versioned unlike system packagers, so with tea your
  39. > deployments actually remain *more* stable.
  40. > </details>

  42. You need 34 dependencies to compile our white-paper but with tea there’s
  43. nothing to think about:

  45. ```sh
$ git clone https://github.com/teaxyz/white-paper
$ cd white-paper
$ tea make  #†
tea: installing pandoc.org and 33 other dependencies…
…
$ open tea.white-paper.pdf
  1. ```

  3. Our white-paper’s dependencies are written in plain markdown in our `README`.
  4. tea sets up a virtual environment for them simply by stepping into the
  5. directory.

  7. > † prefixing with tea ensures all the deps get installed before `make` is run
  8. > in general tea is a *shell* that injects a packaging environment before
  9. > executing other commands.

  11. > ### Coming Soon
  12. >
  13. > * we’ll automatically load and unload completions as you change directory
  14. > * we’ll allow customizations per package for your project

  16. &nbsp;


  19. ## Executable Markdown

  21. [Markdown] has (justifiably) become the standard documentation format of
  22. development. How about instead of writing scripts with comments, we write
  23. documentation that can be *run*.

  25. ```sh
$ tea .  # interprets # Getting Started, could also be tea ./README.md
tea: npm install
tea: npm start

$ git clone https://github.com/my/project
$ cd project
$ tea build
tea: executing # Build
  1. ```

  3. Using these scripts in CI is easy:

  5. ```yaml
steps:
  - uses: teaxyz/setup@v0
    with:
      target: build
  1. ```

  3. Check out [teaxyz/setup] for all that you can do with our GitHub Action.

  5. > ### Coming Soon
  6. >
  7. > This is a limited set of first steps exploring the idea of executable
  8. > markdown. We intend to sensibly build out concepts for making entire
  9. > documents executable, and we’d like your help with that.
  10. > Start a [discussion] about it.

  12. &nbsp;



  16. # Getting Started

  18. tea is a standalone binary. Grab it from [releases] or `curl` it:

  20. ```sh
$ curl -Lo tea https://tea.xyz/$(uname)/$(uname -m)
$ chmod u+x ./tea

$ echo '# tea really is a standalone binary' | ./tea -X glow -
  1. ```

  3. However, we recommend our installer:

  5. ```sh
sh <(curl https://tea.xyz)

• asks you to confirm before it sets up ~/.tea

• asks you to confirm before adding one line to your ~/.shellrc

• asks you to confirm before making a /usr/local/bin/tea symlink

  1. ```

  3. <details><summary><code>`preview.gif`</code>summary>

  5. ![charm.sh/vhs recording](https://teaxyz.github.io/setup/sample.gif)

  7. </details>

  9. <details><summary>If you <code>fish</code>, read this…summary>

  11. ```fish
sh <(curl https://tea.xyz | psub)
  1. ```

  3. </details>

  5. In fact, the tea one-liner abstracts away installation:

  7. ```sh
$ sh <(curl tea.xyz) https://examples.deno.land/color-logging.ts

if tea is installed, our one-liner uses the tea installation, if it’s not

installed then it doesn’t install tea or any dependencies, it creates a

sandbox and runs everything in there


and btw, the above works the same as:

$ tea https://examples.deno.land/color-logging.ts

which really is:

$ tea -X deno run https://examples.deno.land/color-logging.ts

which really, really is:

$ tea +deno.land deno run https://examples.deno.land/color-logging.ts
  1. ```

  3. > Now in your blog posts, tweets and tutorials you don’t have to start
  4. > with any “how to install tea” preamble nor will they need to google anything.
  5. > If they want to learn about tea first they can go to the same URL as they’re
  6. > curl’ing. We already work on Linux, macOS, and WSL; soon we’ll support Windows
  7. > natively.

  9. As a bonus the installer also updates tea.

  11. ## *Now see here fella’, I \*hate\* installers…*

  13. Us too! *That’s why we wrote a package manager!*

  15. > <details><summary><i>Installing without the installer</i>summary><br>
  16. >
  17. > Take your pick:
  18. >
  19. > * Grab the latest [release][releases] with your browser. On macOS you’ll
  20. >   have to unquarantine the binary:
  21. >
  22. >   ```sh
  23. >   $ xattr -d com.apple.quarantine ./tea
  24. >   ```
  25. >
  26. > * Or get a plain text listing of binary downloads:
  27. >
  28. >   ```sh
  29. >   $ curl dist.tea.xyz   # pick your platform and `curl` it
  30. >   ```
  31. >
  32. > * Or if you want to get fancy there’s this:
  33. >
  34. >   ```sh
  35. >   $ sudo install -m 755 <(curl --compressed -LSsf https://tea.xyz/$(uname)/$(uname -m)) /usr/local/bin/tea
  36. >   ```
  37. >
  38. > Our (optional) virtual environment manager functionality needs a shell hook
  39. > in the relevant `.rc` file:
  40. >
  41. > ```sh
  42. > add-zsh-hook -Uz chpwd(){ source <(tea -Eds) }
  43. > ```
  44. >
  45. > </details>

  47. > <details><summary><i>Uninstalling tea</i>summary><br>
  48. >
  49. > * You can delete everything under `~/.tea`
  50. > * There’s also a one-liner added to your `~/.zshrc` you should remove.
  51. > * Finally delete `/usr/local/bin/tea`
  52. >
  53. > </details>

  55. &nbsp;


  58. ## Usage as an Environment Manager

  60. You’re a developer, installing tools globally makes no sense. With tea the
  61. tools you need per project or script are available to that workspace as
  62. *virtual environments*. Our magic works from depths of libc to the heights of
  63. the latests fads in CSS precompilers. All versions†. All platforms‡.

  65. > † We’re new software, give us time to achieve this promise.\
  66. > ‡ Windows (native, we support WSL), Raspberry Pi, BeOS, etc. coming soon!

  68. When you `cd` into a project in your terminal, tea sets up the environment so
  69. your tools “just work”. To do this it looks for a dependencies table in
  70. your `README`.

  72. > Using the `README` may seem weird, but really it's the right place to
  73. > document your dependencies. Typically in open source this information is
  74. > barely documented, incorrectly documented or duplicated (incorrectly) in
  75. > various hard to find places. No longer.
  76. >
  77. > Additionally this makes use of tea *optional*. Your team or your users can
  78. > source your dependencies themselves if they want. It says right there in a
  79. > human readable form in the `README` what they need to get.
  80. >
  81. > <details><summary><i>Umm, I hate this, can I use a different file?</i>summary>
  82. >
  83. > You can use `package.json` instead:
  84. >
  85. > ```json
  86. > {
  87. >   "tea": {
  88. >     "dependencies": [{ "nodejs.org": 18 }]
  89. >   }
  90. > }
  91. > ```
  92. >
  93. > We check `README.md` before `package.json`. You can force use of
  94. > `package.json` by disabling magic with `--disable-magic`.
  95. >
  96. > </details>

  98. For an example see our “[dependencies](#dependencies)” section
  99. (teaception: we use tea to build tea).

  101. You can check what environment this generates with `tea`:

  103. ```sh
tea --env --dump
  1. ```

  3. `--env` specifies that tea will generate an environment based on the source
  4. control checkout. So if you’re using git we’ll look around for a `.git`
  5. directory and consider that the `SRCROOT` for your project. Then we check the
  6. `README.md` there to gather the environment information.

  8. tea attempts to further enhance your environment based on your workspace
  9. context:

  11. | Variable  | Description                                                               |
  12. | --------- | ------------------------------------------------------------------------- |
  13. | `VERSION` | Extracted from the `README.md`, `VERSION` or `package.json`               |
  14. | `SRCROOT` | We descend towards root until we find a source control marker, eg. `.git` |
  15. | `MANPATH` | So `man …` works for your deps                                            |

  17. We also provide eg. `PKG_CONFIG_PATH`, `LD_LIBRARY_PATH`, `DEVELOPER_DIR`,
  18. etc. so other tools can find your dependencies. We provide other variables for
  19. convenience too, like `GITHUB_SLUG` (extracted from your `git remote`) which
  20. can be surprisingly useful to automation scripts.

  22. These variables are also available to “tea Scripts”.

  24. > Our shell magic controls this feature, if you don’t want to add our
  25. > one-liner to your shell rc then you can just `tea sh` in your project
  26. > directory to get the same effect—albeit more laboriously.
  27. >
  28. > Or you can run tools directly with eg. `tea foo`

  30. &nbsp;


  33. ## Usage as an Interpreter

  35. You can use tea to execute pretty much any script from any location. We’ll
  36. auto-magically install the right interpreter (as an isolated virtual
  37. environment—there are no global consequences to your system).

  39. ```sh
$ tea my-script.py
  1. ```

  3. tea sees the `.py` file extension, so it installs the latest version of Python
  4. and then executes the script.

  6. If you want more control over the python version then we need to edit the
  7. script’s YAML front-matter, eg:

  9. ```python
#!/usr/bin/env python

"""
dependencies:
  python.org: ^3.11
"""

snip …

  1. ```

  3. tea will run the script with the latest version of Python that is >=3.11 but
  4. less than 4.0. If it's not installed we grab it, otherwise we use what is
  5. available.

  7. We also support `args` and `env` parameters which are useful for tools that
  8. require a `run` command like deno or go.

  10. ```ts
#!/usr/bin/env deno

/*---
dependencies:
  deno.land: ^1.27
args:
  - deno
  - run
  # we put the script filename on the end for you here
env:
  foo: {{srcroot}}/bar
  1. ```

  3. > Note strictly you don’t need the above, we automatically do this (if magic
  4. > is enabled) for `.ts` scripts.

  6. ### Using a `tea` Shebang

  8. You can `#!/usr/bin/env tea`, and you’d possibly choose this because tea can
  9. do more than install dependencies. You may recall our earlier diatribe about
  10. tools sticking to what they’re good at—*we really believe this*. Thus
  11. having tools evolve to be configurable for project environments is something
  12. we think should be left to *us*.

  14. For example, `deno` is a wonderful interpreter for JavaScript and TypeScript,
  15. but it has no project configuration capabilities which means if you want to
  16. use it for scripts you may have to mess around a little. We think deno should
  17. stay this way, and instead we can use tea:

  19. ```ts
#!/usr/bin/env -S tea -E

/* ---
dependencies:
  deno.land: ^1.18
args:
  - deno
  - run
  - --allow-net
  - --import-map={{ srcroot }}/import-map.json
  # ^^ we provide {{srcroot}} which can be enormously useful for scripting
  # note that you must use a tea -E shebang for this to work

// snip …
  1. ```

  3. Which would go like this:

  5. ```sh
$ pwd
/src
$ ./script.ts my-arg
tea: ~/.tea/deno.land/v1.18/bin/deno run \
  --allow-net \
  --import-map=/src/import-map.json \
  /src/script.ts \
  my-arg
  1. ```

  3. > When called with `-E` tea reads the virtual environment and injects any
  4. > dependencies from there. Probably your project already specifies your `deno`
  5. > dependency, so the above YAML is possibly being redundant.

  7. &nbsp;


  10. # Magic

  12. `tea` formalizes (in a CLI/TUI sense) the concept of magic.

  14. In an environment where there
  15. is magic we try to be clever and infer what you want. Without magic we are
  16. strict and require precise specification of your intent.

  18. You can disable magic by specifying `--disable-magic` or exporting `MAGIC=0`
  19. to your shell environment.

  21. The primary magic we apply is determining if you want to use your virtual
  22. environment or not. Strictly `tea --env` is required to inject it, but when
  23. magic is enabled we try to figure out if you *just wanted that*. Our goal is
  24. to be smart and useful for your productivity.

  26. We do some magic per dependency. This is currently hard-coded logic in tea/cli
  27. itself, but we intend to make it general with a `magic.ts` file per package
  28. in the [pantry].

  30. Currently magic is limited (and a great place for contributions†).

  32. For example, if we detect that your project is a GitHub Action we read the
  33. `action.yml` and make the right version of node available.

  35. > † is there a file that your environment or language always has and thus
  36. > `tea` should know to add packages to that environment? Open a [discussion]
  37. > or just go straight to contributing the PR!
  38. > Magic lives in `useVirtualEnv.ts`.

  40. &nbsp;


  43. # Contributing

  45. If you have suggestions or ideas, start a [discussion]. If we agree we’ll
  46. move it to an issue. Bug fixes straight to pull request or issue please!

  48. Probably the place you’ll want to start is by supplementing the
  49. [pantry][pantry.extra].

  51. ## Hacking on `tea`

  53. `tea` is written in [TypeScript] using [deno].

  55. ```sh
git clone https://github.com/teaxyz/cli tea
cd tea

tea run foo       # runs the local checkout passing foo as an argument
tea install-self  # deploys the local checkout into your ~/.tea
  1. ```

  3. This alias makes it so you can execute your local checkout from anywhere:

  5. ```sh
alias teal="$HOME/.tea/deno.land/v1/bin/deno run \
  --import-map=$HOME/tea/cli/import-map.json \
  --unstable \
  --allow-all \
  $HOME/tea/cli/src/app.ts"

^^ change the paths!

^^ add to your ~/.shellrc file

  1. ```

  3. ### Things we Need

  5. * We really need more tests!
  6. * We need test coverage information
  7. * More magic for dependencies, eg. knowing what version of node should be in
  8.     the env based on `.node-version` files used for other version managers.

  10. ## Token Rewards

  12. There isn’t a token *yet* but when it’s brewed it’s quite possible there will
  13. be a little something extra for those who helped build tea. ��‍��️

  15. &nbsp;


  18. # FAQ

  20. ## How do I update packages

  22. ```sh
$ tea --sync

^^ updates the pantries, and any packages in the virtual-environment


$ tea --sync +deno.land

^^ updates specific packages

  1. ```

  3. Of course this is limited and more is required here. We’re working on it.

  5. ## Where’s `tea install`?

  7. tea works differently. It’s not “I want to install Freetype” it’s
  8. “I want to *use* Freetype”.

  10. Look, we’re not idiots. We know there are occasions where a good ol’
  11. `brew install` is what you need. So—*for now*—continue using `brew install`.
  12. Longer term, we have plans for an extensible commands system.

  14. *tea is a set of packaging primitives*. We want you to build entirely new
  15. things on top of tea. We want to integrate tea into your existing build tools,
  16. we eventually want to be the authoritative packaging datastore (isn’t it about
  17. time there was one of those?)

  19. Coming soon is [tea/cmd]. tea/cli will expose forks of this repo as commands
  20. the user can run utilizing the power of tea’s packaging primitives to do all
  21. that they can imagine. Maybe it’ll be you who writes the `tea install`
  22. command? (If you do, try to do something new, eh? ��)

  24. ### May we interest you in a hack?

  26. If you really want to put `tea` through its paces, you can combine the search
  27. magic with your shell’s “command not found” logic, to get automatic `tea`
  28. lookups.

  30. > <details open><summary><h4><code>zsh</code>h4></summary>
  31. >
  32. > ```sh
  33. > function command_not_found_handler {
  34. >   tea -X $*
  35. > }
  36. > ```
  37. >
  38. > </details>

  40. > <details><summary><h4><code>bash</code>h4></summary>
  41. >
  42. > The following requires `bash^4`; sadly macOS ships with v3.2, but `tea`
  43. > provides `+gnu.org/bash`, and we’ve met very few people who want to use
  44. > `bash` on macs, though I bet you're out there).
  45. >
  46. > ```sh
  47. > function command_not_found_handle {
  48. >   tea -X $*
  49. > }
  50. > ```
  51. >
  52. > </details>

  54. > <details><summary><h4><code>fish</code>h4></summary>
  55. >
  56. > ```sh
  57. > function fish_command_not_found
  58. >   tea -X $argv
  59. > end
  60. > ```
  61. >
  62. > </details>

  64. ## How do I find available packages?

  66. We list all packages at [tea.xyz](https://tea.xyz/+/).
  67. Or `open ~/.tea/tea.xyz/var/pantry`. We
  68. agree this is not great UX.

  70. ## What are you doing to my computer?

  72. We install compartmentalized packages to `~/.tea`.

  74. We then suggest you add our one-liner to your shell `.rc` and a symlink
  75. for `/usr/local/bin/tea`.

  77. We might not have installed tea, if you used `sh <(curl tea.xyz) foo` and tea
  78. wasn’t already installed, then we only fetched any packages, including
  79. tea, temporarily.

  81. ## I thought you were decentralized and web3 and shit

  83. [tea is creating new technologies that will change how open source is funded][white-paper].
  84. tea/cli is an essential part of that endeavor and is released
  85. prior to our protocol in order to bootstrap our holistic vision.

  87. We don’t subscribe to any particular “web” at tea.xyz, our blockchain
  88. component will be an implementation detail that you won’t need to think about
  89. (but we think you will want to).

  91. ## Am I or my employer going to have to pay for open source now?

  93. No. Software is a multi-trillion industry. We only have to skim a little off
  94. that to pay the entire open source ecosystem. Check out our [white-paper] for
  95. the deets.

  97. ## Packaging up tea packages with your `.app`, etc.

  99. Our packages are relocatable by default. Just keep the directory structure the
  100. same. And ofc. you are licensed to do so (by us! each package has its own
  101. license!). Honestly we think you should
  102. absolutely bundle and deploy tea’s prefix with your software. We designed it
  103. so that it would be easier for you to do this than anything that has come
  104. before.

  106. ## Will you support platform `foo`

  108. We want to support *all* platforms.
  109. Start a [discussion] and let’s talk about how to move forward with that.

  111. ## I have another question

  113. Start a [discussion] and we’ll get back to you.


  116. &nbsp;

  118. &nbsp;



  122. # Appendix

  124. ## Philosophy

  126. * Be non‑intrusive
  127.     > don’t interfere with our users’ systems or habits
  128. * Be “just works”
  129.     > our users have better things to do than fix us
  130. * Error messages must be excellent
  131.     > trust that if it comes to it, our users can fix things provided we give
  132.     > them a helping hand
  133. * Be intuitive
  134.     > being clever is good—but don’t be so clever nobody gets it
  135. * Resist complexity
  136.     > rethink the problem until a simpler solution emerges
  137. * Be fast
  138.     > we are in the way of our users’ real work, don’t make them wait

  140. ## Troubleshooting

  142. ### `env: tea: No such file or directory`

  144. If you got this error message, you need to install tea:
  145. `sh <(curl https://tea.xyz)`.

  147. ## vs. `brew`

  149. We don’t aim to replace `brew`, we see our offerings as somewhat
  150. complementary. Still where we have overlapping features:

  152. * tea supports more platforms
  153. * tea is transparently cross-platform in usage
  154. * tea packages are relocatable
  155. * tea aims to be zippy and stay zippy
  156. * tea doesn’t make global changes to your system
  157. * tea doesn’t require you install the Xcode Command Line Tools
  158. * tea aims to enhance the way you work, rather than dictate the way you work
  159. * tea installs independently for every user on the machine
  160. * tea is somewhat decentralized and aims to be completely decentralized
  161. * tea is a handful of tight, easy-to-understand codebases
  162. * tea starts building new releases for tools almost instantly
  163. * tea’s packages are named in a fully-qualified manner
  164. * tea’s philosophy is user-first and not tea-maintainer-first


  167. &nbsp;

  169. ## Tea Scripts

  171. You can execute each of these with `tea foo` where `foo` is the name of the
  172. section.

  174. ### Test

  176. > `FIXME` would be nice to be able to specify tests here
  177. > deno supports `--filter` but that would require a little
  178. > massaging.

  180. ```sh
deno task test
  1. ```

  3. ### Typecheck

  5. ```sh
deno task typecheck
  1. ```

  3. ### Run

  5. ```sh
deno task run
  1. ```

  3. ### Compile

  5. ```sh
OUT="$1"
if test -z "$OUT"; then
  OUT="./tea"
else
  shift
fi

deno compile \
  --allow-read \
  --allow-write \
  --allow-net \
  --allow-run \
  --allow-env \
  --unstable \
  --import-map="$SRCROOT/import-map.json" \
  --output "$OUT" \
  "$@" \
  "$SRCROOT/src/app.ts"
  1. ```

  3. ### Install Self

  5. Installs this working copy into `~/.tea/tea.xyz/vx.y.z`.

  7. ```sh
tea compile "$TEA_PREFIX/tea.xyz/v$VERSION/bin/tea"
"$SRCROOT"/scripts/repair.ts tea.xyz
  1. ```

  3. ## Dependencies

  5. | Project   | Version |
  6. | --------- | ------- |
  7. | deno.land | ^1.27   |
  8. | tea.xyz   | ^0      |

  10. > macOS >= 11 || linux:glibc >= 23


  13. &nbsp;


  16. ## A Brief Diatribe

  18. Every programming language, every build system, every compiler, web server,
  19. database and email client seem to gravitate towards adding infinite features
  20. and complexity so that their users can do ever more and more.

  22. This is contrary to the UNIX philosophy: tools should do one thing and
  23. —by being tight and focused—
  24. do it *damn* well.
  25. If they are composable and flexible then they can be combined,
  26. piped and leveraged into a larger,
  27. more capable toolbox.
  28. *The Internet is built with this toolbox.*

  30. Nowadays every programming language
  31. reimplements the same set of libraries and tools because using a
  32. well-maintained, mature and portable library that lives higher up the stack
  33. adds too much complexity.
  34. This extends the adolescence of new languages,
  35. results in no single language even becoming truly state of the art
  36. and leads to degrees of
  37. duplication that make the open source ecosystem *fragile*.
  38. This is to the detriment of all software, everywhere.

  40. tea removes this complexity and adds some much needed robustness for the good
  41. of the entire open source ecosystem, the larger Internet and the whole world
  42. of software.


  45. [pantry]: https://github.com/teaxyz/pantry.core
  46. [Markdown]: https://daringfireball.net/projects/markdown/
  47. [releases]: ../../releases
  48. [teaxyz/setup]: https://github.com/teaxyz/setup
  49. [deno]: https://deno.land
  50. [tea/cmd]: https://github.com/teaxyz/cmd
  51. [TypeScript]: https://www.typescriptlang.org
  52. [discussion]: https://github.com/orgs/teaxyz/discussions
  53. [white-paper]: https://github.com/teaxyz/white-paper
  54. [`brew`]: https://brew.sh
  55. [charm]: https://charm.sh
  56. [pantry.extra]: https://github.com/teaxyz/pantry.extra