├── .gitignore ├── src ├── robots.txt ├── Checksum_Deprecation.zh.md ├── Migrating-A-Formula-To-A-Tap.zh.md ├── Common-Issues-for-Core-Contributors.zh.md ├── Rename-A-Formula.zh.md ├── Custom-GCC-and-cross-compilers.zh.md ├── C++-Standard-Libraries.zh.md ├── Common-Issues-for-Core-Contributors.md ├── Building-Against-Non-Homebrew-Dependencies.zh.md ├── _config.yml ├── Migrating-A-Formula-To-A-Tap.md ├── Rename-A-Formula.md ├── Xcode.zh.md ├── Maintainers-Avoiding-Burnout.zh.md ├── Checksum_Deprecation.md ├── Xcode.md ├── Custom-GCC-and-cross-compilers.md ├── Brew-Test-Bot-For-Core-Contributors.zh.md ├── Shell-Completion.zh.md ├── Brew-Test-Bot.zh.md ├── C++-Standard-Libraries.md ├── How-to-Create-and-Maintain-a-Tap.zh.md ├── Troubleshooting.zh.md ├── Building-Against-Non-Homebrew-Dependencies.md ├── Interesting-Taps-and-Forks.zh.md ├── How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.zh.md ├── Brew-Test-Bot.md ├── Installation.zh.md ├── Brew-Test-Bot-For-Core-Contributors.md ├── README.zh.md ├── Acceptable-Formulae.zh.md ├── Querying-Brew.zh.md ├── Shell-Completion.md ├── Versions.zh.md ├── Taps.zh.md ├── SUMMARY.md ├── Interesting-Taps-and-Forks.md ├── README.md ├── Troubleshooting.md ├── Maintainers-Avoiding-Burnout.md ├── How-to-Create-and-Maintain-a-Tap.md ├── Prose-Style-Guidelines.zh.md ├── Bottles.zh.md ├── External-Commands.zh.md ├── How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.md ├── Analytics.zh.md ├── How-To-Open-a-Homebrew-Pull-Request.zh.md ├── Tips-N'-Tricks.zh.md ├── Installation.md ├── Gems,-Eggs-and-Perl-Modules.zh.md ├── Homebrew-and-Python.zh.md ├── Querying-Brew.md ├── Taps.md ├── Acceptable-Formulae.md ├── New-Maintainer-Checklist.zh.md ├── Common-Issues.zh.md ├── Node-for-Formula-Authors.zh.md ├── Versions.md ├── External-Commands.md ├── Bottles.md ├── Tips-N'-Tricks.md ├── Maintainer-Guidelines.zh.md ├── FAQ.zh.md ├── Homebrew-and-Python.md ├── Analytics.md ├── Gems,-Eggs-and-Perl-Modules.md ├── Prose-Style-Guidelines.md ├── New-Maintainer-Checklist.md ├── Common-Issues.md ├── How-To-Open-a-Homebrew-Pull-Request.md ├── Node-for-Formula-Authors.md ├── Python-for-Formula-Authors.zh.md └── FAQ.md ├── book.toml └── en.md /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules/ 2 | .DS_Store 3 | fork 4 | source 5 | docs -------------------------------------------------------------------------------- /src/robots.txt: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | User-agent: * 4 | Sitemap: {{ site.url }}/sitemap.xml 5 | -------------------------------------------------------------------------------- /book.toml: -------------------------------------------------------------------------------- 1 | [book] 2 | title = "Homebrew 中文🇨🇳文档" 3 | description = "Documentation : Mac 缺失的包管理器." 4 | -------------------------------------------------------------------------------- /src/Checksum_Deprecation.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # MD5和SHA-1表示法 3 | 4 | 2015年初,自制开始了贬低的过程.*沙哈*用于封装完整性验证.从那时起,自制软件组织的公式就被转移到了使用中.*沙256*为了验证,这包括源包和我们的预编译包(瓶). 5 | 6 | 家庭自制已经停止支持.*沙哈*和*MD5*完全.*MD5*从2012和2015年4月的核心公式中除去校验和,安装一个公式验证.*MD5*主动封锁. 7 | 8 | 我们移除*沙哈*支持**2016年11月**21个月后,我们开始警告人们离开它进行核实.这是以同样的方式实施的.*MD5*是通过阻止该单独公式的安装直到校验和被迁移. 9 | 10 | 这意味着需要将定制的抽头、本地定制公式等迁移到使用中.*沙256*然后才能安装它们. 11 | -------------------------------------------------------------------------------- /src/Migrating-A-Formula-To-A-Tap.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 将公式迁移到轻敲 3 | 4 | 有时我们可能希望将一个公式从一个抽头迁移到另一个抽头.这样做: 5 | 6 | 1. 创建一个拉请求到新的点击,添加公式文件,是从原来的水龙头.修正由于新公式比现有公式更严格的要求而可能发生的任何测试故障(例如).`brew audit --strict`必须通过这个公式. 7 | 2. 创建一个拉请求到原来的TAP删除公式文件并将其添加到`tap_migrations.json`使用提交消息`gv: migrate to homebrew/core`. 8 | 3. 在另一个拖拽请求中为每个拉动请求设置一个链接,以便维护者能够同时合并它们. 9 | 10 | 恭喜你,你把一个公式移到了水龙头上! 11 | -------------------------------------------------------------------------------- /src/Common-Issues-for-Core-Contributors.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 核心贡献者的共同问题 3 | 4 | ## 概述 5 | 6 | 这是维护人员诊断某些生成错误的页面. 7 | 8 | ## 问题 9 | 10 | ### `ld: internal error: atom not found in symbolIndex(__ZN10SQInstance3GetERK11SQObjectPtrRS0_) for architecture x86_64` 11 | 12 | 确切的原子可能是不同的. 13 | 14 | 这可能是由于过时的原因造成的.`-s`标记到链接器,并且可以像[这](https://github.com/Homebrew/legacy-homebrew/commit/7c9a9334631dc84d59131ca57419e8c828b1574b). 15 | -------------------------------------------------------------------------------- /src/Rename-A-Formula.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 重命名公式 3 | 4 | 有时需要重新命名软件和公式.重命名一个你需要的公式: 5 | 6 | 1. 将公式文件及其类重命名为新公式.新名称必须满足公式命名的所有常规规则.修正由于新公式比现有公式更严格的要求而可能发生的任何测试故障(即:`brew audit --strict`必须通过这个公式. 7 | 8 | 2. 创建一个拉请求到相应的TAP,删除旧的公式文件,添加新的公式文件,并将其添加到`formula_renames.json`使用提交消息`newack: renamed from ack`. 使用规范名称(例如)`ack`而不是`user/repo/ack`) 9 | 10 | 一`formula_renames.json`公式重命名的例子: 11 | 12 | ```json 13 | { 14 | "ack": "newack" 15 | } 16 | ``` 17 | -------------------------------------------------------------------------------- /src/Custom-GCC-and-cross-compilers.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 自定义GCC和交叉编译器 3 | 4 | HOBBURW依赖于具有最新版本的XCODE,因为它带有特定版本的构建工具,例如.`clang`. 5 | 6 | 安装GCC的自定义版本或`autotools`进入`PATH`有可能打破许多编译,所以我们更喜欢苹果或自制的编译器. 7 | 8 | 基于GCC的交叉编译器通常是"仅KEG",因此默认情况下不链接到路径中. 9 | 10 | 在这个时候,我们不会把它们合并在一起,而是把它们列在这个页面上.如果你想出了一个新版本的GCC或交叉编译器套件的公式,请把它链接到这里. 11 | 12 | - 自制饮料提供了`gcc`公式使用XCODE 4.2 +或当需要C++ 11支持早期版本. 13 | - 家庭酿造提供旧的GCC公式,例如.`gcc@4.9`和`gcc@6`. 14 | - HybBurw提供LLVM CLAN,它与`llvm`公式. 15 | - [RISC-V](https://github.com/riscv/homebrew-riscv)提供包括BIUTILS和GCC的RISC-V工具链. 16 | -------------------------------------------------------------------------------- /src/C++-Standard-Libraries.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # C++标准库 3 | 4 | 苹果编译器支持两个C++标准库. 5 | 6 | 10.9和以后的默认值是**LBC+**这也是默认的`clang`在老平台上构建C++ 11代码时. 7 | 8 | 10.8和更早的默认值是**libstdc++**,由苹果GCC编译器、GNU GCC编译器支持,以及`clang`. 在XCODE 8编译过程中,这一点被标记为警告. 9 | 10 | 在几个C++标准库之间存在微妙的不兼容性,因此如果用一个不兼容的C++库构建一个依赖项,HOBPREW将拒绝安装软件.建议使用兼容编译器安装依赖树. 11 | 12 | **如果您已升级到10.9或更高版本的早期版本**-因为默认的C++标准库现在是LBC+++,所以您可能无法使用10.8或更低的依赖性来构建软件.如果您正在阅读此页,是因为您在此处受到构建错误的引导,那么如果重新安装要构建的包的所有依赖项,则很可能可以解决此问题. 13 | 14 | 使用GCC 4.8安装示例:`brew install DESIRED_FORMULA --cc=gcc-4.8`. 获得GCC 4.8通过:`brew install gcc48` 15 | -------------------------------------------------------------------------------- /src/Common-Issues-for-Core-Contributors.md: -------------------------------------------------------------------------------- 1 | # Common Issues for Core Contributors 2 | 3 | ## Overview 4 | 5 | This is a page for maintainers to diagnose certain build errors. 6 | 7 | ## Issues 8 | 9 | ### `ld: internal error: atom not found in symbolIndex(__ZN10SQInstance3GetERK11SQObjectPtrRS0_) for architecture x86_64` 10 | 11 | The exact atom may be different. 12 | 13 | This can be caused by passing the obsolete `-s` flag to the linker and can be 14 | fixed like [this](https://github.com/Homebrew/legacy-homebrew/commit/7c9a9334631dc84d59131ca57419e8c828b1574b). 15 | -------------------------------------------------------------------------------- /src/Building-Against-Non-Homebrew-Dependencies.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 建立非自制依赖关系 3 | 4 | ## 历史 5 | 6 | 最初,Homebrew是一个从源构建的包管理器,所有用户环境变量和非Homebrew安装的软件都可用于构建.从那时起,自制啤酒增加了`Requirement`s指定非自制软件的依赖性(如由`brew cask`像x11/x石英一样,`superenv`构建系统以去除未指定的依赖项,环境过滤以阻止用户环境泄漏到Homebrew构建,以及`default_formula`指定一个`Requirement`可以用一个特定的公式来满足. 7 | 8 | 由于自制软件主要是二进制包管理器,大多数用户都在满足.`Requirement`S与`default_formula`不是随意选择.为了改进质量和减少变化,Homebrew现在只支持使用默认公式,作为普通的依赖项,而不再支持使用任意的替代项. 9 | 10 | ## 今天 11 | 12 | 如果您希望构建由自制程序提供的自定义非自制软件依赖项(例如非自制程序、非MACOS)`ruby`那么你必须[创建和维护您自己的水龙头](How-to-Create-and-Maintain-a-Tap.md)由于这些公式将不被接受在自制/自制核心.一旦你做到了,你就可以指定`env :std`在公式中允许`which ruby`访问现有的`PATH`变量,并允许编译与此红宝石链接. 13 | -------------------------------------------------------------------------------- /src/_config.yml: -------------------------------------------------------------------------------- 1 | title: Homebrew Documentation 2 | description: Documentation for the missing package manager for macOS. 3 | 4 | remote_theme: Homebrew/brew.sh 5 | 6 | exclude: 7 | - bin 8 | - CNAME 9 | - Gemfile* 10 | - vendor 11 | 12 | plugins: 13 | - jekyll-feed 14 | - jekyll-remote-theme 15 | - jekyll-seo-tag 16 | - jekyll-sitemap 17 | 18 | permalink: :title 19 | 20 | defaults: 21 | - scope: 22 | path: "" 23 | values: 24 | image: /assets/img/homebrew-256x256.png 25 | 26 | logo: /assets/img/homebrew-256x256.png 27 | 28 | twitter: 29 | username: MacHomebrew 30 | 31 | facebook: 32 | publisher: https://www.facebook.com/machomebrew/ 33 | -------------------------------------------------------------------------------- /src/Migrating-A-Formula-To-A-Tap.md: -------------------------------------------------------------------------------- 1 | # Migrating A Formula To A Tap 2 | 3 | There are times when we may wish to migrate a formula from one tap into another tap. To do this: 4 | 5 | 1. Create a pull request to the new tap adding the formula file as-is from the original tap. Fix any test failures that may occur due to the stricter requirements for new formulae than existing formula (e.g. `brew audit --strict` must pass for that formula). 6 | 2. Create a pull request to the original tap deleting the formula file and add it to `tap_migrations.json` with a commit message like `gv: migrate to homebrew/core`. 7 | 3. Put a link for each pull request in the other pull request so the maintainers can merge them both at once. 8 | 9 | Congratulations, you've moved a formula to a tap! 10 | -------------------------------------------------------------------------------- /src/Rename-A-Formula.md: -------------------------------------------------------------------------------- 1 | # Renaming a Formula 2 | 3 | Sometimes software and formulae need to be renamed. To rename a formula 4 | you need to: 5 | 6 | 1. Rename the formula file and its class to a new formula. The new name must meet all the usual rules of formula naming. Fix any test failures that may occur due to the stricter requirements for new formulae than existing formulae (i.e. `brew audit --strict` must pass for that formula). 7 | 8 | 2. Create a pull request to the corresponding tap deleting the old formula file, adding the new formula file, and adding it to `formula_renames.json` with a commit message like `newack: renamed from ack`. Use the canonical name (e.g. `ack` instead of `user/repo/ack`). 9 | 10 | A `formula_renames.json` example for a formula rename: 11 | 12 | ```json 13 | { 14 | "ack": "newack" 15 | } 16 | ``` 17 | -------------------------------------------------------------------------------- /src/Xcode.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # Xcode 3 | 4 | ## 支持的XCODE版本 5 | 6 | HOBBRW支持并推荐最新的XCODE和/或命令行工具可供您的平台使用(参见`OS::Mac::Xcode.latest_version`和`OS::Mac::CLT.latest_version`在里面[`Library/Homebrew/os/mac/xcode.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac/xcode.rb)) 7 | 8 | ## XCODE编译器版本 9 | 10 | 见`OS::Mac::STANDARD_COMPILERS`在里面[`Library/Homebrew/os/mac.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac.rb). 11 | 12 | ## 更新新的XCOP版本 13 | 14 | 当一个新的XCODE版本被发布时,需要更新以下内容: 15 | 16 | - 在[`Library/Homebrew/os/mac/xcode.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac/xcode.rb) 17 | - `OS::Mac::Xcode.latest_version` 18 | - `OS::Mac::CLT.latest_version` 19 | - `OS::Mac::Xcode.detect_version_from_clang_version` 20 | - 在[`Library/Homebrew/os/mac.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac.rb) 21 | - `OS::Mac::STANDARD_COMPILERS` 22 | -------------------------------------------------------------------------------- /src/Maintainers-Avoiding-Burnout.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 维持者:避免倦怠 3 | 4 | **本指南适用于维护人员.**这些特殊的人**写访问**HOBPROW的知识库,并帮助合并他人的贡献.你可能会发现这里写的东西很有趣,但绝对不是每个人都写的. 5 | 6 | ## 1.使用自制软件 7 | 8 | 自制的维护者应该定期使用它.这部分是因为你不会除非你能把自己放在用户的鞋是一个很好的维护者,也可能因为你决定停止使用自制程序,在这一点上你应该也决定不将维护和找其他的事情来做. 9 | 10 | ## 2.没有离开的罪恶感 11 | 12 | 所有的维护者可以在任何时候停止工作,没有任何内疚或解释(比如离开工作).你离开后,我们可能还会问你的问题,但你没有义务回答.像是一份工作,如果你创建一个大的混乱,然后让你没有义务,但我们可以少想你(或者,实际上,可能只是回复问题的工作).像一份工作,你应该至少从家酿一年至少几次. 13 | 14 | 这也意味着贡献者应该是消费者.如果一个所有者发现他们没有在现实世界中使用项目,他们应该重新考虑他们参与项目. 15 | 16 | ## 三.优先维护用户 17 | 18 | 关注用户很重要,但是最终,只要您遵循上面的#1,Homebrew的最小用户数量就是维护者的数量.然而,如果自制软件没有维护者,它将很快对所有用户都毫无用处,项目也将死亡.因此,没有用户投诉,行为或需要优先于维护人员的倦怠.如果用户不喜欢项目的方向,那么影响它的最简单方法是做出显著的、高质量的代码贡献并成为维护者. 19 | 20 | ## 4.学会说不 21 | 22 | 自制程序有很多特征请求,不可重复的bug报告,使用问题和PRS,我们不接受.一旦我们意识到它们不会被解决或合并,它们就应该被关闭.这比经过长时间的审查更明智.我们的问题跟踪器应该反映工作要做. 23 | 24 | * * * 25 | 26 | *多亏了[HTTPS//GIST.GITHUBCOM/RYANFRONES/124070E7C4B38](https://gist.github.com/ryanflorence/124070e7c4b3839d4573)影响了这份文件* 27 | -------------------------------------------------------------------------------- /src/Checksum_Deprecation.md: -------------------------------------------------------------------------------- 1 | # MD5 and SHA-1 Deprecation 2 | 3 | In early 2015 Homebrew started the process of deprecating _SHA1_ for package 4 | integrity verification. Since then formulae under the Homebrew organisation 5 | have been moved onto using _SHA256_ for verification; this includes both source 6 | packages and our precompiled packages (bottles). 7 | 8 | Homebrew has since stopped supporting _SHA1_ and _MD5_ entirely. 9 | _MD5_ checksums were removed from core formulae in 2012 and as of April 2015 10 | installing a formula verified by _MD5_ is actively blocked. 11 | 12 | We removed _SHA1_ support in **November 2016**, 13 | 21 months after we started warning people to move away from it for verification. 14 | This is enforced in the same way _MD5_ is, by blocking the installation of that 15 | individual formula until the checksum is migrated. 16 | 17 | This means custom taps, local custom formulae, etc need to be migrated to use 18 | _SHA256_ before you can install them. 19 | -------------------------------------------------------------------------------- /src/Xcode.md: -------------------------------------------------------------------------------- 1 | # Xcode 2 | 3 | ## Supported Xcode versions 4 | Homebrew supports and recommends the latest Xcode and/or Command Line 5 | Tools available for your platform (see `OS::Mac::Xcode.latest_version` and `OS::Mac::CLT.latest_version` in [`Library/Homebrew/os/mac/xcode.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac/xcode.rb)). 6 | 7 | ## Xcode compiler versions 8 | 9 | See `OS::Mac::STANDARD_COMPILERS` in [`Library/Homebrew/os/mac.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac.rb). 10 | 11 | ## Updating for new Xcode releases 12 | When a new Xcode release is made, the following things need to be 13 | updated: 14 | 15 | - In [`Library/Homebrew/os/mac/xcode.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac/xcode.rb) 16 | * `OS::Mac::Xcode.latest_version` 17 | * `OS::Mac::CLT.latest_version` 18 | * `OS::Mac::Xcode.detect_version_from_clang_version` 19 | - In [`Library/Homebrew/os/mac.rb`](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac.rb) 20 | * `OS::Mac::STANDARD_COMPILERS` 21 | -------------------------------------------------------------------------------- /src/Custom-GCC-and-cross-compilers.md: -------------------------------------------------------------------------------- 1 | # Custom GCC and Cross Compilers 2 | 3 | Homebrew depends on having an up-to-date version of Xcode because it comes with 4 | specific versions of build tools, e.g. `clang`. 5 | 6 | Installing a custom version of GCC or `autotools` into the `PATH` has the 7 | potential to break lots of compiles so we prefer the Apple- or Homebrew-provided 8 | compilers. 9 | 10 | Cross-compilers based on GCC will typically be "keg-only" and therefore not 11 | linked into the path by default. 12 | 13 | Rather than merging in brews for either of these cases at this time, we're 14 | listing them on this page. If you come up with a formula for a new version of 15 | GCC or cross-compiler suite, please link it in here. 16 | 17 | - Homebrew provides a `gcc` formula for use with Xcode 4.2+ or when needing 18 | C++11 support on earlier versions. 19 | - Homebrew provides older GCC formulae, e.g. `gcc@4.9` and `gcc@6`. 20 | - Homebrew provides the LLVM clang, which is bundled with the `llvm` formula. 21 | - [RISC-V](https://github.com/riscv/homebrew-riscv) provides the RISC-V 22 | toolchain including binutils and GCC. 23 | -------------------------------------------------------------------------------- /src/Brew-Test-Bot-For-Core-Contributors.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # BREW测试BOT为核心贡献者 3 | 4 | 如果生成已运行并通过`brew test-bot`然后,它可以用来快速瓶公式. 5 | 6 | 有两种类型的詹金斯作业将与之交互: 7 | 8 | ## [自制核心拉动请求](https://jenkins.brew.sh/job/Homebrew%20Core/) 9 | 10 | 这项工作自动构建任何提交请求到自制/自制软件的核心.在成功或失败时,它更新拉请求状态(参见[主酿测试BOT文档页](Brew-Test-Bot.md))在成功构建时,它自动上载瓶子. 11 | 12 | ## [自制测试](https://jenkins.brew.sh/job/Homebrew%20Testing/) 13 | 14 | 此作业手动触发运行.[`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb)使用用户指定的参数.在成功构建时,它自动上载瓶子. 15 | 16 | 您可以手动启动具有参数运行的作业.[`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb)具有相同的参数.通过pull请求URL、commit URL、commit SHA-1和/或公式名称让Brew Test Bot测试它们、报告结果并生产瓶子通常是有用的. 17 | 18 | ## 装瓶 19 | 20 | 拉动和装瓶拉动请求`brew pull`: 21 | 22 | 1. 确保工作顺利完成. 23 | 2. 跑`brew pull --bottle 12345`哪里`12345`是拉请求号(或URL).如果它抱怨一个丢失的URL`BrewTestBot`然后,瓶子还没有完成上传,等待并稍后再试. 24 | 3. 跑`git push`推动提交. 25 | 26 | 设置测试生成: 27 | 28 | 1. 确保工作顺利完成. 29 | 2. 跑`brew pull --bottle https://jenkins.brew.sh/job/Homebrew%20Testing/1234/`哪里`https://jenkins.brew.sh/job/Homebrew%20Testing/1234/`是詹金斯中的测试生成URL. 30 | 3. 跑`git push`推动提交. 31 | -------------------------------------------------------------------------------- /src/Shell-Completion.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 自制外壳完成 3 | 4 | 自制程序附带完成定义`brew`命令.一些包还为自己的程序提供完成定义. 5 | 6 | `zsh`,`bash`和`fish`目前支持.(自制)提供`brew`完井`zsh`和`bash`;`fish`提供它自己的`brew`完成. 7 | 8 | 必须配置外壳才能完成完成支持.这是因为自制的管理完成被存储在下面.`HOMEBREW_PREFIX`,您的系统外壳可能不知道,因为它很难自动配置.`bash`和`zsh`以一种健壮的方式完成,所以家庭安装程序不能为你做. 9 | 10 | ## 配置完成`bash` 11 | 12 | 让自制啤酒的完工`bash`必须将定义定义为shell启动的一部分.向您添加以下内容`~/.bashrc`文件: 13 | 14 | ```sh 15 | if type brew 2&>/dev/null; then 16 | for completion_file in $(brew --prefix)/etc/bash_completion.d/*; do 17 | source "$completion_file" 18 | done 19 | fi 20 | ``` 21 | 22 | ## 配置完成`zsh` 23 | 24 | 让自制啤酒的完工`zsh`您必须在自己的网站上获得自制的ZSH站点功能.`$FPATH`初始化之前`zsh`完成设施.向您添加以下内容`~/.zshrc`文件: 25 | 26 | ```sh 27 | if type brew &>/dev/null; then 28 | FPATH=$(brew --prefix)/share/zsh/site-functions:$FPATH 29 | fi 30 | ``` 31 | 32 | 这必须先做.`compinit`被称为.(注意:如果你使用OH我的ZSH,它会呼叫`compinit`为了你,所以在你打电话之前必须这样做`oh-my-zsh.sh`) 33 | 34 | 你也可能需要强行重建.`zcompdump`: 35 | 36 | ```sh 37 | rm -f ~/.zcompdump; compinit 38 | ``` 39 | 40 | 此外,如果在尝试加载这些完成时收到"zsh compinit:insesafetdirectories"警告,则可能需要运行以下命令: 41 | 42 | ```sh 43 | chmod go-w "$(brew --prefix)/share" 44 | ``` 45 | 46 | ## 配置完成`fish` 47 | 48 | 不需要配置`fish`. 友好! 49 | -------------------------------------------------------------------------------- /src/Brew-Test-Bot.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 酿造试验机器人 3 | 4 | `brew test-bot`是自动审查和测试系统的名称[我们的Kickstarter在2013](https://www.kickstarter.com/projects/homebrew/brew-test-bot). 5 | 6 | 它包括四个Mac Mini和三个XServer,它们在两个数据中心运行.[詹金斯实例在HTTPS://Junk.BurW.SH](https://jenkins.brew.sh)然后运行[`brew-test-bot.rb`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb)Ruby脚本,用于执行提交到主分支、拉请求和维护人员请求的自定义构建的自动测试. 7 | 8 | ## 拉动请求 9 | 10 | BOT自动建立拉请求并根据作业的结果更新它们的状态. 11 | 12 | 例如,已经排队但尚未完成的作业将在拉请求中有一个这样的部分: 13 | 14 | ![Triggered Pull Request](assets/img/docs/brew-test-bot-triggered-pr.png) 15 | 16 | * * * 17 | 18 | 失败的构建看起来像这样: 19 | 20 | ![Failed Pull Request](assets/img/docs/brew-test-bot-failed-pr.png) 21 | 22 | * * * 23 | 24 | 经过的构建看起来像这样: 25 | 26 | ![Passed Pull Request](assets/img/docs/brew-test-bot-passed-pr.png) 27 | 28 | * * * 29 | 30 | 在失败或通过的构建中,您可以单击"详细信息"链接来查看詹金斯中的结果. 31 | 32 | 经过的构建看起来像这样: 33 | 34 | ![Passed Jenkins Build](assets/img/docs/brew-test-bot-passed-jenkins.png) 35 | 36 | * * * 37 | 38 | 失败的构建看起来像这样: 39 | 40 | ![Failed Jenkins Build](assets/img/docs/brew-test-bot-failed-jenkins.png) 41 | 42 | * * * 43 | 44 | 您可以单击测试结果链接(例如`brew-test-bot.el_capitan.install openssl`)查看失败的测试输出: 45 | 46 | ![Failed Test](assets/img/docs/brew-test-bot-failed-test.png) 47 | 48 | * * * 49 | -------------------------------------------------------------------------------- /src/C++-Standard-Libraries.md: -------------------------------------------------------------------------------- 1 | # C++ Standard Libraries 2 | 3 | There are two C++ standard libraries supported by Apple compilers. 4 | 5 | The default for 10.9 and later is **libc++**, which is also the default for `clang` on older 6 | platforms when building C++11 code. 7 | 8 | The default for 10.8 and earlier was **libstdc++**, supported by Apple GCC 9 | compilers, GNU GCC compilers, and `clang`. This was marked deprecated with a 10 | warning during compile as of Xcode 8. 11 | 12 | There are subtle incompatibilities between several of the C++ standard libraries, 13 | so Homebrew will refuse to install software if a dependency was built with an 14 | incompatible C++ library. It's recommended that you install the dependency tree 15 | using a compatible compiler. 16 | 17 | **If you've upgraded to 10.9 or later from an earlier version** - because the default C++ 18 | standard library is now libc++, you may not be able to build software using 19 | dependencies that you built on 10.8 or lower. If you're reading this page because 20 | you were directed here by a build error, you can most likely fix the issue if 21 | you reinstall all the dependencies of the package you're trying to build. 22 | 23 | Example install using GCC 4.8: ```brew install DESIRED_FORMULA --cc=gcc-4.8```. 24 | Get GCC 4.8 via: ```brew install gcc48``` 25 | -------------------------------------------------------------------------------- /src/How-to-Create-and-Maintain-a-Tap.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 如何创建和维护龙头 3 | 4 | 抽头是自制公式和/或外部命令的外部来源.它们可以由任何人创建,以向任何家庭用户提供自己的公式和/或外部命令. 5 | 6 | ## 创建龙头 7 | 8 | tap通常是在线可用的Git存储库,但是您可以使用任何东西,只要它是Git理解的协议,或者甚至只是一个包含文件的目录.如果在GITHUB上托管,我们建议存储库的名称从`homebrew-`. 9 | 10 | TAP公式遵循与内核的格式相同的格式,可以在存储库的根中添加,或在`Formula`或`HomebrewFormula`子目录.我们推荐后面的选项,因为它使存储库组织更容易掌握,并且顶级文件不与公式混合. 11 | 12 | 见[自制/核心](https://github.com/Homebrew/homebrew-core)对于一个水龙头的例子`Formula`子目录. 13 | 14 | ### 安装 15 | 16 | 如果它在GITHUB上,用户可以安装任何公式.`brew install user/repo/formula`. 自制将自动添加您的`github.com/user/homebrew-repo`在安装公式之前先敲击.`user/repo/formula`指向`github.com/user/homebrew-repo/**/formula.rb`文件在这里. 17 | 18 | 如果他们想要在不同时安装任何公式的情况下获得你的点击,用户可以将它添加到[`brew tap`命令](Taps.md). 19 | 20 | 如果是在GITHUB上,他们可以使用`brew tap user/repo`在哪里`user`是您的GITHUB用户名和`homebrew-repo`你的仓库. 21 | 22 | 如果它在GITHUB外部托管,就必须使用.`brew tap user/repo `在哪里`user`和`repo`将用来指你的水龙头和``是你的Git克隆URL. 23 | 24 | 用户可以同时安装公式.`brew install foo`如果没有同名的核心公式,或`brew install user/repo/foo`避免冲突. 25 | 26 | ## 维修水龙头 27 | 28 | 一个TAP只是一个Git存储库,所以你不必做任何具体的修改,除了提交和推动你的变化. 29 | 30 | ### 更新 31 | 32 | 一旦安装了TAP,每次用户运行时,HOBBURW都会更新它.`brew update`. 过时的公式将在用户运行时升级.`brew upgrade`,就像核心公式一样. 33 | 34 | ## 外部命令 35 | 36 | 您可以为您的TAP用户提供自定义`brew`命令,将它们添加到`cmd`子目录.[多读外部命令](External-Commands.md). 37 | 38 | 见[自制/别名](https://github.com/Homebrew/homebrew-aliases)对于具有外部命令的TAP的示例. 39 | -------------------------------------------------------------------------------- /src/Troubleshooting.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 故障排除 3 | 4 | **跑`brew update`两次`brew doctor` *之前*创造一个问题!** 5 | 6 | 此文档将帮助您检查常见问题,并确保您的问题尚未被报告. 7 | 8 | ## 检查常见问题 9 | 10 | 按照以下步骤解决常见问题: 11 | 12 | - 跑`brew update`两次. 13 | - 跑`brew doctor`修正所有的警告(**过时的XCODE/CLT和未经处理的DyLB很可能引起问题.**) 14 | - 检查一下**XCODEL(CLT)的命令行工具**和**Xcode**是最新的. 15 | - 如果命令在权限错误时失败,请检查权限`/usr/local`的子目录.如果你不确定该怎么办,你可以跑.`cd /usr/local && sudo chown -R $(whoami) bin etc include lib sbin share var opt Cellar Caskroom Frameworks`. 16 | - 读完[常见问题](Common-Issues.md). 17 | 18 | ## 检查是否已报告问题 19 | 20 | - 搜索[问题跟踪器](https://github.com/Homebrew/homebrew-core/issues)看看其他人是否已经报告过同样的问题. 21 | - 确保在正确的存储库中搜索问题.如果一个失败的公式是非自制核心龙头的一部分,或者是一个桶的一部分.[自制/桶](https://github.com/Homebrew/homebrew-cask/issues)检查这些问题跟踪器. 22 | 23 | ## 创建问题 24 | 25 | 如果您的问题尚未解决或报告,那么创建一个问题: 26 | 27 | 0. 将调试信息上传到[主旨](https://gist.github.com): 28 | 29 | - 如果你有一个公式相关的问题:运行`brew gist-logs `(何处)``公式的名称. 30 | - 如果遇到非公式问题:上载输出`brew config`和`brew doctor`新的[主旨](https://gist.github.com). 31 | 32 | 1. [创造新的问题](https://github.com/Homebrew/homebrew-core/issues/new/choose). 33 | 34 | - 给你的问题一个描述性的标题,包括公式名(如果适用)和你使用的MACOS版本.例如,如果一个公式无法建立,标题为您的问题"\\".未能在\\\\ 10 .x>上建立",""是无法构建的公式的名称,而'\\\< 10.x>"是您使用的MACOS的版本. 35 | - 包含URL输出`brew gist-logs `(如适用). 36 | - 包括指向您可能已经创建的任何附加GIST的链接(如输出的链接)`brew config`和`brew doctor`) 37 | -------------------------------------------------------------------------------- /src/Building-Against-Non-Homebrew-Dependencies.md: -------------------------------------------------------------------------------- 1 | # Building Against Non-Homebrew Dependencies 2 | 3 | ## History 4 | 5 | Originally Homebrew was a build-from-source package manager and all user environment variables and non-Homebrew-installed software were available to builds. Since then Homebrew added `Requirement`s to specify dependencies on non-Homebrew software (such as those provided by `brew cask` like X11/XQuartz), the `superenv` build system to strip out unspecified dependencies, environment filtering to stop the user environment leaking into Homebrew builds and `default_formula` to specify that a `Requirement` can be satisfied by a particular formula. 6 | 7 | As Homebrew became primarily a binary package manager, most users were fulfilling `Requirement`s with the `default_formula`, not with arbitrary alternatives. To improve quality and reduce variation, Homebrew now exclusively supports using the default formula, as an ordinary dependency, and no longer supports using arbitrary alternatives. 8 | 9 | ## Today 10 | 11 | If you wish to build against custom non-Homebrew dependencies that are provided by Homebrew (e.g. a non-Homebrew, non-macOS `ruby`) then you must [create and maintain your own tap](How-to-Create-and-Maintain-a-Tap.md) as these formulae will not be accepted in Homebrew/homebrew-core. Once you have done that you can specify `env :std` in the formula which will allow a e.g. `which ruby` to access your existing `PATH` variable and allow compilation to link against this Ruby. 12 | -------------------------------------------------------------------------------- /src/Interesting-Taps-and-Forks.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 趣味丝锥 3 | 4 | 一*水龙头*HOBBURW是一个包含额外公式的GIT库.HOMBRW有能力在本地安装中添加和删除多个TAP`brew tap`和`brew untap`命令.类型`man brew`在你的终端.主要储存库[HTTPS://GITHUBCOM/HOMEBWW/HOMEBRW-CORE](https://github.com/Homebrew/homebrew-core),常被称为`homebrew/core`总是内置的. 5 | 6 | 您的抽头是GIT仓库位于`$(brew --repository)/Library/Taps`. 7 | 8 | ## 不支持的趣味丝锥 9 | 10 | - [丹吉斯/恩吉克斯](https://github.com/denji/homebrew-nginx)NGIX模块的一个抽头,用于它的`nginx-full`公式,其中包括更多的模块选项. 11 | 12 | - [即时点击/即时客户端](https://github.com/InstantClientTap/homebrew-instantclient)Oracle即时客户端的一个TAP.软件包需要手动下载. 13 | 14 | - [OSX交叉/AVR](https://github.com/osx-cross/homebrew-avr)GNU-AVR工具链(Labc,编译器和其他工具,用于Atmel MCU,对ARDUIO黑客和AVR程序员有用). 15 | 16 | - [彼得雷尔](https://github.com/petere/homebrew-postgresql)允许并行安装多个PostgreSQL版本. 17 | 18 | - [钛/古拉迪奥](https://github.com/titanous/homebrew-gnuradio)GNU电台和朋友在MaOOS上运行. 19 | 20 | - [邓恩/Emacs](https://github.com/dunn/homebrew-emacs)一种用于Emacs封装的龙头. 21 | 22 | - [SIDAF/TENTEST](https://github.com/sidaf/homebrew-pentest)渗透测试工具. 23 | 24 | - [OSFR/模拟](https://github.com/osrf/homebrew-simulation)机器人仿真工具. 25 | 26 | - [BurWSCI/Big](https://github.com/brewsci/homebrew-bio)生物信息学公式. 27 | 28 | - [戴维查尔/海普](https://github.com/davidchall/homebrew-hep)高能物理公式. 29 | 30 | - [生命支柱/应用](https://github.com/lifepillar/homebrew-appleii)陈酿苹果仿真公式. 31 | 32 | ## 不支持的有趣的叉子 33 | 34 | - [迷迭香](https://github.com/mistydemeo/tigerbrew)实验虎PowerPC版本. 35 | 36 | - [Linuxbrew /酿造](https://github.com/Linuxbrew/brew)实验Linux版本. 37 | -------------------------------------------------------------------------------- /src/How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 如何用自制软件构建家庭外的软件`keg_only`依赖关系 3 | 4 | ## "KEG"是什么意思? 5 | 6 | 这个[常见问题解答](FAQ.md)简单地解释一下. 7 | 8 | 举个例子: 9 | 10 | *OpenSSL没有被链接到我的`PATH`而非自制软件找不到它!* 11 | 12 | 这是因为Homebrew通常将其锁定在单独的前缀中,而不是与公共可用的位置进行符号链接.`/usr/local`. 13 | 14 | ## 关于潜在解决方案的建议 15 | 16 | 在这种情况下,许多人要么有力地联系在一起.`keg_only`工具与`brew link --force`或将默认系统实用程序移出`PATH`并用手工创建的Simulink替换他们提供的自制工具. 17 | 18 | *拜托*不要删除Mac OS本地工具,并用SyLink将它们强行替换为自制工具.这样做可能会造成重大破坏,当试图建立软件. 19 | 20 | `brew link --force`创建一个警告`brew doctor`让你和维护者都知道可能存在问题的链接.如果你联系了什么,没有任何问题?随意忽略`brew doctor`错误. 21 | 22 | ## 如何在自制软件之外使用这些工具? 23 | 24 | 有用的,可靠的替代品存在,如果你想使用`keg_only`自制工具之外的工具. 25 | 26 | ### 创建标志 27 | 28 | 您可以设置标志,以便在正确的方向上提供配置脚本或生成文件.标志设置示例: 29 | 30 | ```sh 31 | ./configure --prefix=/Users/Dave/Downloads CFLAGS=-I$(brew --prefix)/opt/openssl/include LDFLAGS=-L$(brew --prefix)/opt/openssl/lib 32 | ``` 33 | 34 | 使用实例`pip`: 35 | 36 | ```sh 37 | CFLAGS=-I$(brew --prefix)/opt/icu4c/include LDFLAGS=-L$(brew --prefix)/opt/icu4c/lib pip install pyicu 38 | ``` 39 | 40 | ### `PATH`修改 41 | 42 | 你可以暂时准备好`PATH`使用工具的bin目录,例如: 43 | 44 | ```sh 45 | export PATH=$(brew --prefix)/opt/openssl/bin:$PATH 46 | ``` 47 | 48 | 这将把文件夹准备好.`PATH`确保搜索的任何构建脚本`PATH`会首先找到它. 49 | 50 | 改变你`PATH`使用该命令确保该更改只存在于该shell会话的持续时间.一旦你不再参加那个会议,`PATH`恢复到先前状态. 51 | 52 | ### `pkg-config`侦查 53 | 54 | 如果正在尝试构建的工具是[PKG配置](https://en.wikipedia.org/wiki/Pkg-config)意识到,你可以修改你的`PKG_CONFIG_PATH`发现`keg_only`公用事业公司`.pc`文件,如果有文件的话.并不是所有的公式都与这些文件相关联. 55 | 56 | 这样的一个例子是: 57 | 58 | ```sh 59 | export PKG_CONFIG_PATH=$(brew --prefix)/opt/openssl/lib/pkgconfig 60 | ``` 61 | 62 | 如果你对这件事感到好奇`PKG_CONFIG_PATH`变量`man pkg-config`更详细地说. 63 | 64 | 你可以得到`pkg-config`以以下方式详细说明默认搜索路径: 65 | 66 | ```sh 67 | pkg-config --variable pc_path pkg-config 68 | ``` 69 | -------------------------------------------------------------------------------- /src/Brew-Test-Bot.md: -------------------------------------------------------------------------------- 1 | # Brew Test Bot 2 | 3 | `brew test-bot` is the name for the automated review and testing system funded 4 | by [our Kickstarter in 2013](https://www.kickstarter.com/projects/homebrew/brew-test-bot). 5 | 6 | It comprises four Mac Minis and three Xserves running in two data centres which host 7 | [a Jenkins instance at https://jenkins.brew.sh](https://jenkins.brew.sh) and run the 8 | [`brew-test-bot.rb`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) 9 | Ruby script to perform automated testing of commits to the master branch, pull 10 | requests and custom builds requested by maintainers. 11 | 12 | ## Pull Requests 13 | 14 | The bot automatically builds pull requests and updates their status depending 15 | on the result of the job. 16 | 17 | For example, a job which has been queued but not yet completed will have a 18 | section in the pull request that looks like this: 19 | 20 | ![Triggered Pull Request](assets/img/docs/brew-test-bot-triggered-pr.png) 21 | 22 | --- 23 | 24 | A failed build looks like this: 25 | 26 | ![Failed Pull Request](assets/img/docs/brew-test-bot-failed-pr.png) 27 | 28 | --- 29 | 30 | A passed build looks like this: 31 | 32 | ![Passed Pull Request](assets/img/docs/brew-test-bot-passed-pr.png) 33 | 34 | --- 35 | 36 | On failed or passed builds you can click the "Details" link to view the result 37 | in Jenkins. 38 | 39 | A passed build looks like this: 40 | 41 | ![Passed Jenkins Build](assets/img/docs/brew-test-bot-passed-jenkins.png) 42 | 43 | --- 44 | 45 | A failed build looks like this: 46 | 47 | ![Failed Jenkins Build](assets/img/docs/brew-test-bot-failed-jenkins.png) 48 | 49 | --- 50 | 51 | You can click the test results link 52 | (e.g. `brew-test-bot.el_capitan.install openssl`) to 53 | view the failed test output: 54 | 55 | ![Failed Test](assets/img/docs/brew-test-bot-failed-test.png) 56 | 57 | --- 58 | -------------------------------------------------------------------------------- /src/Installation.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 安装 3 | 4 | 建议的和最简单的安装自制软件的方法是[主页](https://brew.sh). 5 | 6 | 标准脚本安装自制程序`/usr/local`以便[你不需要苏多](FAQ.md)当你`brew install`. 这是一个谨慎的脚本;即使你安装了一些东西,它也可以运行.`/usr/local`已经.它确切地告诉你它在做之前也会做什么.你必须确认它开始之前所做的一切. 7 | 8 | ## 要求 9 | 10 | - 英特尔CPU[一](#1) 11 | - MACOS 10.12或更高[二](#2) 12 | - Xcode的命令行工具(CLT):`xcode-select --install`,[开发应用程序](https://developer.apple.com/downloads)或[Xcode](https://itunes.apple.com/us/app/xcode/id497799835) [三](#3) 13 | - 用于安装的Burne兼容外壳(例如BASH或ZSH)[四](#4) 14 | 15 | ## 替代安装 16 | 17 | ### OSX狮子10.7及以下 18 | 19 | 使用指令[HTTPS://BurW.SH](https://brew.sh)或以下任何时候你打电话`curl`你必须通过`--insecure`作为一个论点.这是因为你的系统`curl`太老了,不能用HTTPS和GITHUB说话.别担心,第一`brew update`自制将安装一个更新的,更安全的`curl`为了你的机器. 20 | 21 | ### 随时随地 22 | 23 | 只提取(或)`git clone`无论你想要什么,都要自酿.只是避免: 24 | 25 | - 包含空格的目录的目录.自制程序可以处理空间,但许多构建脚本不能处理. 26 | - `/tmp`子目录,因为自制软件会不安 27 | - `/sw`和`/opt/local`因为构建脚本在自制程序而不是Fink或Mac端口时会变得混乱. 28 | 29 | 不过,请自己帮忙安装`/usr/local`. 有些东西在其他地方安装时可能无法建立.家庭自制只是相对竞争的原因之一.**因为**我们建议安装到`/usr/local`. *选择另一个前缀在你的危险!* 30 | 31 | ```sh 32 | mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew 33 | ``` 34 | 35 | ### 多种设施 36 | 37 | 在提取TabBar的任何地方创建自制程序.无论哪个`brew`命令是安装包的地方.您可以使用这一点,如一个LIBS的系统集.`/usr/local`并调整了公式`~/homebrew`. 38 | 39 | ## 卸载 40 | 41 | 卸载记录在[常见问题解答](FAQ.md). 42 | 43 | 一不是所有的公式都有CPU或OS要求,但是你可以假设如果你不符合的话你会遇到麻烦.此外,您可以从PoR网络中的其他用户找到PowerPC和老虎分支.见[有趣的水龙头和叉子](Interesting-Taps-and-Forks.md). 44 | 45 | 二建议10.12或更高.10.5—10.11是在尽力的基础上支持的.10.4见[虎尾鹦鹉](https://github.com/mistydemeo/tigerbrew). 46 | 47 | 三大多数公式需要编译器.少数需要完整的XCODE安装.您可以安装XCODE、CLT,或两者兼备;HOBBRW支持所有三种配置.下载XCODE可能需要苹果开发者帐户上的旧版本的Mac OS X.免费注册.[在这里](https://developer.apple.com/register/index.action). 48 | 49 | 四一班轮安装方法发现[啤酒](https://brew.sh)需要一个兼容Burne的shell(例如BASH或ZSH).值得注意的是,鱼类、TCSH和CSH将不起作用. 50 | -------------------------------------------------------------------------------- /src/Brew-Test-Bot-For-Core-Contributors.md: -------------------------------------------------------------------------------- 1 | # Brew Test Bot For Core Contributors 2 | 3 | If a build has run and passed on `brew test-bot` then it can be used to quickly bottle formulae. 4 | 5 | There are two types of Jenkins jobs you will interact with: 6 | 7 | ## [Homebrew Core Pull Requests](https://jenkins.brew.sh/job/Homebrew%20Core/) 8 | This job automatically builds any pull requests submitted to Homebrew/homebrew-core. On success or failure it updates the pull request status (see more details on the [main Brew Test Bot documentation page](Brew-Test-Bot.md)). On a successful build it automatically uploads bottles. 9 | 10 | ## [Homebrew Testing](https://jenkins.brew.sh/job/Homebrew%20Testing/) 11 | This job is manually triggered to run [`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) with user-specified parameters. On a successful build it automatically uploads bottles. 12 | 13 | You can manually start this job with parameters to run [`brew test-bot`](https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb) with the same parameters. It's often useful to pass a pull request URL, a commit URL, a commit SHA-1 and/or formula names to have the Brew Test Bot test them, report the results and produce bottles. 14 | 15 | ## Bottling 16 | To pull and bottle a pull request with `brew pull`: 17 | 18 | 1. Ensure the job has already completed successfully. 19 | 2. Run `brew pull --bottle 12345` where `12345` is the pull request number (or URL). If it complains about a missing URL with `BrewTestBot` in it then the bottles have not finished uploading yet; wait and try again later. 20 | 3. Run `git push` to push the commits. 21 | 22 | To bottle a test build: 23 | 24 | 1. Ensure the job has already completed successfully. 25 | 2. Run `brew pull --bottle https://jenkins.brew.sh/job/Homebrew%20Testing/1234/` where `https://jenkins.brew.sh/job/Homebrew%20Testing/1234/` is the testing build URL in Jenkins. 26 | 3. Run `git push` to push the commits. 27 | -------------------------------------------------------------------------------- /src/README.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 文档 3 | 4 | ## 用户 5 | - [`brew`-man手册页(命令文档)](Manpage.zh.md) 6 | - [故障排除](Troubleshooting.zh.md) 7 | - [安装](Installation.zh.md) 8 | - [常见问题](FAQ.zh.md) 9 | - [常见Issue](Common-Issues.zh.md) 10 | - [`brew`shell tab补充](Shell-Completion.zh.md) 11 | - [提示和技巧](Tips-N'-Tricks.zh.md) 12 | - [bottles (二进制包)](Bottles.zh.md) 13 | - [Taps (第三方储存库)](Taps.zh.md) 14 | - [有趣的Taps和Forks](Interesting-Taps-and-Forks.zh.md) 15 | - [匿名用户行为分析总计](Analytics.zh.md) 16 | 17 | - [查询`brew`](Querying-Brew.zh.md) 18 | - [C++标准库](C++-Standard-Libraries.zh.md) 19 | - [MD5和SHA-1表示法](Checksum_Deprecation.zh.md) 20 | - [自定义 GCC 和跨平台编译器](Custom-GCC-and-cross-compilers.zh.md) 21 | - [外部命令](External-Commands.zh.md) 22 | - [ruby GEM、Python Eggs 和 Perl模块](Gems,-Eggs-and-Perl-Modules.zh.md) 23 | - [python](Homebrew-and-Python.zh.md) 24 | - [如何在homebrew外构建Homebrew-`keg_only`依赖关系的软件](How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.zh.md) 25 | - [Xcode](Xcode.zh.md) 26 | - [Kickstarter支持者](Kickstarter-Supporters.zh.md) 27 | 28 | ## 贡献者 29 | 30 | - [如何打开提交请求(并将其合并)](How-To-Open-a-Homebrew-Pull-Request.zh.md) 31 | - [配方-Formula食谱](Formula-Cookbook.zh.md) 32 | - [可接受配方](Acceptable-Formulae.zh.md) 33 | - [配方版本](Versions.zh.md) 34 | - [配方作者节点](Node-for-Formula-Authors.zh.md) 35 | - [配方作者的Python](Python-for-Formula-Authors.zh.md) 36 | - [将配方迁移到Tap](Migrating-A-Formula-To-A-Tap.zh.md) 37 | - [重命名配方](Rename-A-Formula.zh.md) 38 | - [建立非Homebrew依赖关系](Building-Against-Non-Homebrew-Dependencies.zh.md) 39 | - [如何创建(和维护)Tap](How-to-Create-and-Maintain-a-Tap.zh.md) 40 | - [brew测试机器人](Brew-Test-Bot.zh.md) 41 | - [散文风格导论](Prose-Style-Guidelines.zh.md) 42 | 43 | 44 | ## 维护者 45 | 46 | - [新维护人员清单](New-Maintainer-Checklist.zh.md) 47 | - [维持者:避免倦怠](Maintainers-Avoiding-Burnout.zh.md) 48 | - [维护指南](Maintainer-Guidelines.zh.md) 49 | - [brew测试机器人](Brew-Test-Bot-For-Core-Contributors.zh.md) 50 | - [维护人员的常见问题](Common-Issues-for-Core-Contributors.zh.md) 51 | -------------------------------------------------------------------------------- /src/Acceptable-Formulae.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 可接受公式 3 | 4 | 一些公式不应该进去[自制/核心](https://github.com/Homebrew/homebrew-core). 但是还有其他的[有趣的水龙头和叉子](Interesting-Taps-and-Forks.md)任何人都可以自己开始! 5 | 6 | ### 骗子`homebrew/core` 7 | 8 | 我们现在接受MACOS附带的东西,只要它使用`keg_only :provided_by_macos`仅默认为桶. 9 | 10 | ### 版本公式`homebrew/core` 11 | 12 | 我们现在接受版本化公式只要它们[符合要求](Versions.md). 13 | 14 | ### 我们不喜欢升级自己的工具. 15 | 16 | 可以升级自己的软件与家庭自制的升级功能没有很好的结合.自更新功能应该被禁用(如果可能的话,不使公式复杂化). 17 | 18 | ### 我们不喜欢安装不可逆版本的安装脚本. 19 | 20 | 我们不喜欢正在安装的脚本.`master`Git存储库的分支或未版本的、未校验的塔尔球.这些应该使用`resource`用特定的修改或校验求和的块.请注意,我们现在允许工具`cargo`,`gem`和`pip`在安装过程中下载特定版本的库. 21 | 22 | ### 我们不喜欢二进制公式. 23 | 24 | 我们的政策是在核心抽头中的公式.[自制/核心](https://github.com/Homebrew/homebrew-core)必须是开源的,或者是从源构建的或者生成跨平台二进制文件(例如Java、莫诺河).只有二进制公式才行[自制桶](https://github.com/Homebrew/homebrew-cask). 25 | 26 | ### 稳定版本 27 | 28 | 核心存储库中的公式必须具有上游项目标记的稳定版本.TARBARE是Git签出的首选,TARBOARS应该尽可能在文件名中包含版本. 29 | 30 | 我们不接受没有标签版本的软件,因为它们经常由于上游变化而中断,我们不能提供.[瓶](Bottles.md)对他们来说. 31 | 32 | ### 小生境(或自我提交) 33 | 34 | 所讨论的软件必须: 35 | 36 | - 被维护(即,上一个版本不是很久以前的,它在所有支持的macOS版本上都无需修补即可工作,并且没有突出的未修补的安全漏洞) 37 | - 被人所知 38 | - 稳定(例如上游没有声明"不稳定"或"beta") 39 | - 被使用 40 | - 有一个主页 41 | 42 | 我们将拒绝那些看起来太模糊的公式,部分原因是因为它们不能得到维护,部分原因是我们必须在某个地方划定界限. 43 | 44 | 我们不喜欢作者提交自己的作品,除非它很受欢迎. 45 | 46 | 别忘了自制啤酒都在下面![维护您自己的水龙头](How-to-Create-and-Maintain-a-Tap.md)如果你必须这样做! 47 | 48 | 在主存储库中可能存在这些规则的例外;我们可能包括不符合这些标准的东西或者拒绝所做的事情.请相信我们需要根据我们管理包装经理的经验来决定. 49 | 50 | ### 建立的东西`.app` 51 | 52 | 不要让你的公式建立一个`.app`(本地Mac OS应用程序),我们不希望在家酿这些东西.鼓励上游项目建设和扶持`.app`可以通过[自制桶](https://github.com/Homebrew/homebrew-cask)(也不用它). 53 | 54 | ### 默认情况下构建GUI的东西(但不必) 55 | 56 | 默认情况下,让它构建一个命令行工具或库,如果GUI有用并且被广泛使用,则添加一个选项来构建GUI.不要为多个GUI后台提供选项,例如X11是MaOS上GUI的坏用户体验. 57 | 58 | ### 不能用最新的稳定的XCODE的铿锵来构建的东西 59 | 60 | Clang是Mac OS上默认的C/C++编译器(并且已经很长时间了).软件并没有建立它没有充分移植到MACOS. 61 | 62 | ### 需要繁重的人工前/后安装干预的东西 63 | 64 | 我们是一个包管理器,所以我们想为用户解决依赖性和安装应用程序.如果事情需要过多的人工干预,那么它们在包管理器中就不起作用了. 65 | 66 | ### 有时也有例外. 67 | 68 | 即使满足所有标准,我们也不能接受这个公式.文档往往滞后于当前的决策.尽管有些拒绝看起来有些武断或奇怪,但它们是基于多年的经验,使得Homebrew能够为我们的用户所接受. 69 | -------------------------------------------------------------------------------- /src/Querying-Brew.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 查询`brew` 3 | 4 | *在本文档中,我们将使用[jq](https://stedolan.github.io/jq/)解析JSON,可以从自制程序中使用`brew install jq`.* 5 | 6 | ## 概述 7 | 8 | `brew`提供从系统中获取公共信息类型的命令.`brew list`显示安装公式.`brew deps foo`显示依赖关系`foo`需要. 9 | 10 | 当然,包括外部命令在内的附加命令可以被写入以提供更详细的信息.这里有两个缺点.首先,它意味着编写Ruby反对可能改变的自制代码库.在重构期间会有更多的代码要接触,而自制程序不能保证外部命令继续工作.第二,它意味着设计命令本身,指定输入参数和输出格式. 11 | 12 | 为了让用户能够在没有上面的问题的情况下进行丰富的查询,自制程序提供了`brew info`命令. 13 | 14 | ## `brew info --json` 15 | 16 | `brew info`输出关于公式的JSON格式化信息.然后可以使用您选择的工具解析此JSON. 17 | 18 | 从MangPo: 19 | 20 | - `info --json= (--all|--installed|)`打印一个JSON表示``. 目前唯一接受的价值``是`v1`. 21 | 22 | 通过`--all`获取所有公式的信息,或`--installed`获取所有安装公式的信息. 23 | 24 | 当前模式版本是`v1`. 注意,在不增加架构的情况下,可以根据需要将字段添加到架构中.任何重大的更改都会导致架构版本的更改. 25 | 26 | 架构本身目前不在生成它的代码之外记录:[公式Tyth-THOHASH](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/formula.rb) 27 | 28 | ## 实例 29 | 30 | *JSON输出的顶层元素总是一个数组,所以`map`运算符用于对数据进行操作.* 31 | 32 | ### 漂亮的打印一个公式的信息 33 | 34 | ```sh 35 | brew info --json=v1 tig | jq . 36 | ``` 37 | 38 | ### 安装公式 39 | 40 | 显示关于所有已安装公式的完整JSON信息: 41 | 42 | ```sh 43 | brew info --json=v1 --all | jq "map(select(.installed != []))" 44 | ``` 45 | 46 | 你会注意到,处理所有公式都是慢的,让它更快.`brew`这样做: 47 | 48 | ```sh 49 | brew info --json=v1 --installed 50 | ``` 51 | 52 | ### 只连接KEG公式 53 | 54 | 一些公式被标记为"仅KEG",这意味着已安装的文件没有链接到共享.`bin`,`lib`目录等,这样做会引起冲突.这样的公式可以强制链接到共享目录,但不建议这样做(并且将导致).`brew doctor`抱怨) 55 | 56 | 只查找链接KEG公式的名称: 57 | 58 | ```sh 59 | brew info --json=v1 --installed | jq "map(select(.keg_only == true and .linked_keg != null) | .name)" 60 | ``` 61 | 62 | ### 非连接正规公式 63 | 64 | 查找已安装但未链接到共享目录的正常(不含KEG)公式的名称: 65 | 66 | ```sh 67 | brew info --json=v1 --installed | jq "map(select(.keg_only == false and .linked_keg == null) | .name)" 68 | ``` 69 | 70 | ## 啤酒配方 71 | 72 | 有一个[文档化的JSONAPI](https://formulae.brew.sh/docs/api/)提供访问`brew info --json=v1`输出,不需要进入自制程序. 73 | 74 | ## 结语 75 | 76 | 使用JSON输出,可以针对Homebrew进行查询,而不必理解Homebrew的Ruby内部信息,从而减少由于Homebrew代码更改而导致中断的风险. 77 | 78 | 如果JSON输出没有提供它应该提供的一些信息,请提交一个请求,最好带有一个补丁来添加所需的信息. 79 | -------------------------------------------------------------------------------- /src/Shell-Completion.md: -------------------------------------------------------------------------------- 1 | # Homebrew Shell Completion 2 | 3 | Homebrew comes with completion definitions for the `brew` command. Some packages also provide completion definitions for their own programs. 4 | 5 | `zsh`, `bash` and `fish` are currently supported. (Homebrew provides `brew` completions for `zsh` and `bash`; `fish` provides its own `brew` completions.) 6 | 7 | You must configure your shell to enable the completion support. This is because the Homebrew-managed completions are stored under `HOMEBREW_PREFIX`, which your system shell may not be aware of, and because it is difficult to automatically configure `bash` and `zsh` completions in a robust manner, so the Homebrew installer cannot do it for you. 8 | 9 | ## Configuring Completions in `bash` 10 | To make Homebrew's completions available in `bash`, you must source the definitions as part of your shell startup. Add the following to your `~/.bashrc` file: 11 | 12 | ```sh 13 | if type brew 2&>/dev/null; then 14 | for completion_file in $(brew --prefix)/etc/bash_completion.d/*; do 15 | source "$completion_file" 16 | done 17 | fi 18 | ``` 19 | 20 | ## Configuring Completions in `zsh` 21 | To make Homebrew's completions available in `zsh`, you must get the Homebrew-managed zsh site-functions on your `$FPATH` before initialising `zsh`'s completion facility. Add the following to your `~/.zshrc` file: 22 | 23 | ```sh 24 | if type brew &>/dev/null; then 25 | FPATH=$(brew --prefix)/share/zsh/site-functions:$FPATH 26 | fi 27 | ``` 28 | 29 | This must be done before `compinit` is called. (Note: if you are using Oh My Zsh, it will call `compinit` for you, so this must be done before you call `oh-my-zsh.sh`.) 30 | 31 | You may also need to forcibly rebuild `zcompdump`: 32 | 33 | ```sh 34 | rm -f ~/.zcompdump; compinit 35 | ``` 36 | 37 | Additionally, if you receive "zsh compinit: insecure directories" warnings when attempting to load these completions, you may need to run this: 38 | 39 | ```sh 40 | chmod go-w "$(brew --prefix)/share" 41 | ``` 42 | 43 | ## Configuring Completions in `fish` 44 | No configuration is needed in `fish`. Friendly! 45 | -------------------------------------------------------------------------------- /src/Versions.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 版本 3 | 4 | 既然[自制/版本](https://github.com/homebrew/homebrew-versions)已经被贬低,[自制/核心](https://github.com/homebrew/homebrew-core)用新的命名格式支持公式的多个版本. 5 | 6 | 在[自制/版本](https://github.com/homebrew/homebrew-versions)GCC 6的公式命名为`gcc6.rb`然后开始`class Gcc6 < Formula`. 在[自制/核心](https://github.com/homebrew/homebrew-core)这个公式叫做`gcc@6.rb`从开始`class GccAT6 < Formula`. 7 | 8 | ## 可接受版本公式 9 | 10 | 我们包含的版本公式[自制/核心](https://github.com/homebrew/homebrew-core)必须符合以下标准: 11 | 12 | - 版本化软件应该建立在所有自制的MaOS支持的版本上. 13 | - 版本公式在主/次(非补丁)版本与当前稳定版本中应该有所不同.这是因为补丁版本表示错误或安全更新,我们希望确保应用安全更新. 14 | - 上游应该有一个版本化的公式版本的发布分支,并在必要时仍然对该版本进行安全更新.例如,[PHP 5.5不是支持版本,但PHP 7.2是](http://php.net/supported-versions.php)2018年1月 15 | - 依赖于版本化公式的公式在其递归依赖性中不得两次依赖于两个不同版本的相同公式.例如,如果你依赖`openssl@1.0`和`foo`和`foo`取决于`openssl`那么你必须使用`openssl`. 16 | - 如果上游项目提供支持,例如,使用后缀二进制文件,则版本化的公式应该只能与非版本化的公式同时可链接.如果这是不可能的,使用`keg_only :versioned_formula`允许用户同时安装多个版本. 17 | - 一`keg_only :versioned_formula`不应该`post_install`任何东西`HOMEBREW_PREFIX`与非版本对应的(或其他版本的公式)冲突或复制.例如,A`node@6`公式不应该安装它的`npm`进入之内`HOMEBREW_PREFIX`像`node`公式可以. 18 | - 提交的公式应被许多人预期使用.如果这种情况消失了,它们将被移除.我们的目标是不删除那些[前3000名`install_on_request`公式](https://brew.sh/analytics/install-on-request/). 19 | - 版本化公式不应该有`resource`需要安全更新的S.例如,A`node@6`公式不应该有`npm`资源,而是依赖于`npm`由上游塔球提供. 20 | - 版本化的公式应该尽可能相似,对不可逆公式是敏感的.创建或更新版本化的公式应该是询问未版本化的公式问题的机会,例如,是否可以删除或默认一些未使用或无用的选项? 21 | - 在任何给定时间,无论使用何种方式,都不支持超过五个版本的公式(包括非版本的公式).当删除公式违反这一点,我们将这样做的基础上使用和支持地位,而不是年龄. 22 | 23 | HOBBURW的版本不打算用于您个人对项目所需的任何旧版本.你应该创造你自己[水龙头](How-to-Create-and-Maintain-a-Tap.md)对于公式,您或您的组织希望控制不符合上述标准的版本或版本.具有常规API或ABI中断版本的软件仍然需要满足以上所有要求;`brew upgrade`为你打破一些东西并不是我们为你增加和维持一个公式的理由. 24 | 25 | 如果有一个公式当前存在于Homebrew/homebrew-core存储库中,或者已经存在于过去(即,已经迁移或删除),那么可以通过`brew extract`命令.这将将公式的期望版本复制到自定义抽头中.例如,如果项目依赖于`automake`1.12,而不是最新版本,您可以获得`automake`版本1.12的运行公式`brew extract automake $YOUR_GITHUB_USER/$YOUR_TAP_REPOSITORY_NAME --version=1.12`. 通过这种方式得到的公式可以使用已弃用、禁用或删除的自制语句(例如校验和).`sha1`而不是校验和`sha256`;`brew extract`命令不编辑或更新公式,以满足目前的标准和风格要求. 26 | 27 | 我们可以暂时为我们自己的需求添加不符合这些标准的版本公式.[自制/核心](https://github.com/homebrew/homebrew-core). 那里存在版本化的公式并不意味着它将被无限期地维护,或者我们愿意接受任何不符合上述要求的版本. 28 | -------------------------------------------------------------------------------- /src/Taps.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 抽头(第三方储存库) 3 | 4 | `brew tap`将更多的存储库添加到公式列表中`brew`跟踪、更新和安装.默认情况下,`tap`假设存储库来自GITHUB,但命令不限于任何一个位置. 5 | 6 | ## 命令(`brew tap`) 7 | 8 | - `brew tap`没有参数列出当前挖掘的存储库.例如: 9 | 10 | ```sh 11 | $ brew tap 12 | homebrew/core 13 | mistydemeo/tigerbrew 14 | dunn/emacs 15 | ``` 16 | 17 | - `brew tap `对仓库进行浅层克隆.[HTTPS://Github. COM/USER/RIPO](https://github.com/user/repo). 之后,`brew`将能够在这些公式中工作,就像它们在自制的标准知识库中一样.您可以安装和卸载它们.`brew [un]install`,当运行时,公式会自动更新.`brew update`. (详情见下文)`brew tap`处理存储库的名称. 18 | 19 | - `brew tap `对URL库进行浅层克隆.与一个参数版本不同,URL不被假定为GITHUB,并且它不必是HTTP.GIT可以处理的任何位置和任何协议都很好. 20 | 21 | - 添加`--full`对于上面的一个或两个参数调用,Git将是一个完整的克隆而不是一个浅的克隆.完整是默认的自制程序开发者. 22 | 23 | - `brew tap --repair`从基于目录结构的SyLink迁移抽取公式.(这应该只需要运行一次.) 24 | 25 | - `brew untap user/repo [user/repo user/repo ...]`移除给定的抽头.存储库被删除,`brew`将不再知道他们的公式.`brew untap`可以同时处理多次删除. 26 | 27 | ## 知识库命名约定和假设 28 | 29 | - 在GITHUB上,您的存储库必须命名.`homebrew-something`为了使用一个参数形式`brew tap`. 前缀"自制"不是可选的.(这两个参数表单没有这个限制,但它迫使您显式地给出完整URL.) 30 | 31 | - 当你使用`brew tap`但是,在命令行中,您可以省略命令中的"自制程序"前缀. 32 | 33 | 也就是说,`brew tap username/foobar`可以用作长版本的捷径:`brew tap username/homebrew-foobar`. `brew`每当必要时,它会自动添加"自制程序"前缀. 34 | 35 | ## 公式重复名称 36 | 37 | 如果您的水龙头包含一个公式,也存在于[`homebrew/core`](https://github.com/Homebrew/homebrew-core)这很好,但是它意味着你必须默认地显式安装它. 38 | 39 | 如果你想优先考虑轻敲`homebrew/core`,你可以使用`brew tap-pin username/repo`钉龙头,并使用`brew tap-unpin username/repo`恢复引脚. 40 | 41 | 无论何时`brew install foo`发出命令,`brew`将按以下顺序查找要使用的公式: 42 | 43 | - 固定丝锥 44 | - 核心公式 45 | - 其他抽头 46 | 47 | 如果需要从特定的筛选器安装公式,可以使用完全限定的名称来引用它们. 48 | 49 | 例如,您可以为替代创建一个TAP.`vim`公式.如果不钉住它,它的行为将是 50 | 51 | ```sh 52 | brew install vim # installs from homebrew/core 53 | brew install username/repo/vim # installs from your custom repo 54 | ``` 55 | 56 | 但是如果你把水龙头钉上`brew tap-pin username/repo`您将需要使用`homebrew/core`参考核心公式. 57 | 58 | ```sh 59 | brew install vim # installs from your custom repo 60 | brew install homebrew/core/vim # installs from homebrew/core 61 | ``` 62 | 63 | 请注意,只有当公式名称由您直接给出时,才对固定抽头进行优先级排序,也就是说,它不会影响作为依赖项自动安装的公式. 64 | -------------------------------------------------------------------------------- /src/SUMMARY.md: -------------------------------------------------------------------------------- 1 | 2 | # 文档 3 | 4 | - [用户](Manpage.zh.md) 5 | - [`brew`-man手册页(命令文档)](Manpage.zh.md) 6 | - [故障排除](Troubleshooting.zh.md) 7 | - [安装](Installation.zh.md) 8 | - [常见问题](FAQ.zh.md) 9 | - [常见Issue](Common-Issues.zh.md) 10 | - [`brew`shell tab补充](Shell-Completion.zh.md) 11 | - [提示和技巧](Tips-N'-Tricks.zh.md) 12 | - [bottles (二进制包)](Bottles.zh.md) 13 | - [Taps (第三方储存库)](Taps.zh.md) 14 | - [有趣的Taps和Forks](Interesting-Taps-and-Forks.zh.md) 15 | - [匿名用户行为分析总计](Analytics.zh.md) 16 | 17 | - [查询`brew`](Querying-Brew.zh.md) 18 | - [C++标准库](C++-Standard-Libraries.zh.md) 19 | - [MD5和SHA-1表示法](Checksum_Deprecation.zh.md) 20 | - [自定义 GCC 和跨平台编译器](Custom-GCC-and-cross-compilers.zh.md) 21 | - [外部命令](External-Commands.zh.md) 22 | - [ruby GEM、Python Eggs 和 Perl模块](Gems,-Eggs-and-Perl-Modules.zh.md) 23 | - [python](Homebrew-and-Python.zh.md) 24 | - [如何在homebrew外构建Homebrew-`keg_only`依赖关系的软件](How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.zh.md) 25 | - [Xcode](Xcode.zh.md) 26 | - [Kickstarter支持者](Kickstarter-Supporters.zh.md) 27 | 28 | - [贡献者](How-To-Open-a-Homebrew-Pull-Request.zh.md) 29 | 30 | - [如何打开提交请求(并将其合并)](How-To-Open-a-Homebrew-Pull-Request.zh.md) 31 | - [配方-Formula食谱](Formula-Cookbook.zh.md) 32 | - [可接受配方](Acceptable-Formulae.zh.md) 33 | - [配方版本](Versions.zh.md) 34 | - [配方作者节点](Node-for-Formula-Authors.zh.md) 35 | - [配方作者的Python](Python-for-Formula-Authors.zh.md) 36 | - [将配方迁移到Tap](Migrating-A-Formula-To-A-Tap.zh.md) 37 | - [重命名配方](Rename-A-Formula.zh.md) 38 | - [建立非Homebrew依赖关系](Building-Against-Non-Homebrew-Dependencies.zh.md) 39 | - [如何创建(和维护)Tap](How-to-Create-and-Maintain-a-Tap.zh.md) 40 | - [brew测试机器人](Brew-Test-Bot.zh.md) 41 | - [散文风格导论](Prose-Style-Guidelines.zh.md) 42 | 43 | 44 | - [维护者](New-Maintainer-Checklist.zh.md) 45 | 46 | - [新维护人员清单](New-Maintainer-Checklist.zh.md) 47 | - [维持者:避免倦怠](Maintainers-Avoiding-Burnout.zh.md) 48 | - [维护指南](Maintainer-Guidelines.zh.md) 49 | - [brew测试机器人](Brew-Test-Bot-For-Core-Contributors.zh.md) 50 | - [维护人员的常见问题](Common-Issues-for-Core-Contributors.zh.md) 51 | -------------------------------------------------------------------------------- /src/Interesting-Taps-and-Forks.md: -------------------------------------------------------------------------------- 1 | # Interesting Taps & Forks 2 | 3 | A _tap_ is homebrew-speak for a Git repository containing extra formulae. 4 | Homebrew has the capability to add (and remove) multiple taps to your local installation with the `brew tap` and `brew untap` commands. Type `man brew` in your Terminal. The main repository [https://github.com/Homebrew/homebrew-core](https://github.com/Homebrew/homebrew-core), often called `homebrew/core`, is always built-in. 5 | 6 | Your taps are Git repositories located at `$(brew --repository)/Library/Taps`. 7 | 8 | ## Unsupported interesting taps 9 | 10 | * [denji/nginx](https://github.com/denji/homebrew-nginx): A tap for NGINX modules, intended for its `nginx-full` formula which includes more module options. 11 | 12 | * [InstantClientTap/instantclient](https://github.com/InstantClientTap/homebrew-instantclient): A tap for Oracle Instant Client. The packages need to be downloaded manually. 13 | 14 | * [osx-cross/avr](https://github.com/osx-cross/homebrew-avr): GNU AVR toolchain (Libc, compilers and other tools for Atmel MCUs, useful for Arduino hackers and AVR programmers). 15 | 16 | * [petere/postgresql](https://github.com/petere/homebrew-postgresql): Allows installing multiple PostgreSQL versions in parallel. 17 | 18 | * [titanous/gnuradio](https://github.com/titanous/homebrew-gnuradio): GNU Radio and friends running on macOS. 19 | 20 | * [dunn/emacs](https://github.com/dunn/homebrew-emacs): A tap for Emacs packages. 21 | 22 | * [sidaf/pentest](https://github.com/sidaf/homebrew-pentest): Tools for penetration testing. 23 | 24 | * [osrf/simulation](https://github.com/osrf/homebrew-simulation): Tools for robotics simulation. 25 | 26 | * [brewsci/bio](https://github.com/brewsci/homebrew-bio): Bioinformatics formulae. 27 | 28 | * [davidchall/hep](https://github.com/davidchall/homebrew-hep): High energy physics formulae. 29 | 30 | * [lifepillar/appleii](https://github.com/lifepillar/homebrew-appleii): Formulae for vintage Apple emulation. 31 | 32 | ## Unsupported interesting forks 33 | 34 | * [mistydemeo/tigerbrew](https://github.com/mistydemeo/tigerbrew): Experimental Tiger PowerPC version. 35 | 36 | * [Linuxbrew/brew](https://github.com/Linuxbrew/brew): Experimental Linux version. 37 | -------------------------------------------------------------------------------- /src/README.md: -------------------------------------------------------------------------------- 1 | # Documentation 2 | 3 | - [中文](./README.zh.md) 4 | 5 | ## Users 6 | - [`brew` man-page (command documentation)](Manpage.md) 7 | - [Troubleshooting](Troubleshooting.md) 8 | - [Installation](Installation.md) 9 | - [Frequently Asked Questions](FAQ.md) 10 | - [Common Issues](Common-Issues.md) 11 | - [`brew` Shell Completion](Shell-Completion.md) 12 | 13 | - [Tips and Tricks](Tips-N'-Tricks.md) 14 | - [Bottles (binary packages)](Bottles.md) 15 | - [Taps (third-party repositories)](Taps.md) 16 | - [Interesting Taps and Forks](Interesting-Taps-and-Forks.md) 17 | - [Anonymous Aggregate User Behaviour Analytics](Analytics.md) 18 | 19 | - [Querying `brew`](Querying-Brew.md) 20 | - [C++ Standard Libraries](C++-Standard-Libraries.md) 21 | - [MD5 and SHA-1 Deprecation](Checksum_Deprecation.md) 22 | - [Custom GCC and Cross Compilers](Custom-GCC-and-cross-compilers.md) 23 | - [External Commands](External-Commands.md) 24 | - [Ruby Gems, Python Eggs and Perl Modules](Gems,-Eggs-and-Perl-Modules.md) 25 | - [Python](Homebrew-and-Python.md) 26 | - [How To Build Software Outside Homebrew With Homebrew `keg_only` dependencies](How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.md) 27 | - [Xcode](Xcode.md) 28 | - [Kickstarter Supporters](Kickstarter-Supporters.md) 29 | 30 | ## Contributors 31 | - [How To Open A Pull Request (and get it merged)](How-To-Open-a-Homebrew-Pull-Request.md) 32 | - [Formula Cookbook](Formula-Cookbook.md) 33 | - [Acceptable Formulae](Acceptable-Formulae.md) 34 | - [Formulae Versions](Versions.md) 35 | - [Node for Formula Authors](Node-for-Formula-Authors.md) 36 | - [Python for Formula Authors](Python-for-Formula-Authors.md) 37 | - [Migrating A Formula To A Tap](Migrating-A-Formula-To-A-Tap.md) 38 | - [Rename A Formula](Rename-A-Formula.md) 39 | - [Building Against Non-Homebrew Dependencies](Building-Against-Non-Homebrew-Dependencies.md) 40 | - [How To Create (And Maintain) A Tap](How-to-Create-and-Maintain-a-Tap.md) 41 | - [Brew Test Bot](Brew-Test-Bot.md) 42 | - [Prose Style Guidelines](Prose-Style-Guidelines.md) 43 | 44 | ## Maintainers 45 | - [New Maintainer Checklist](New-Maintainer-Checklist.md) 46 | - [Maintainers: Avoiding Burnout](Maintainers-Avoiding-Burnout.md) 47 | - [Maintainer Guidelines](Maintainer-Guidelines.md) 48 | - [Brew Test Bot For Maintainers](Brew-Test-Bot-For-Core-Contributors.md) 49 | - [Common Issues for Maintainers](Common-Issues-for-Core-Contributors.md) 50 | -------------------------------------------------------------------------------- /src/Troubleshooting.md: -------------------------------------------------------------------------------- 1 | # Troubleshooting 2 | 3 | **Run `brew update` twice and `brew doctor` *before* creating an issue!** 4 | 5 | This document will help you check for common issues and make sure your issue has not already been reported. 6 | 7 | ## Check for common issues 8 | 9 | Follow these steps to fix common problems: 10 | 11 | * Run `brew update` twice. 12 | * Run `brew doctor` and fix all the warnings (**outdated Xcode/CLT and unbrewed dylibs are very likely to cause problems**). 13 | * Check that **Command Line Tools for Xcode (CLT)** and **Xcode** are up to date. 14 | * If commands fail with permissions errors, check the permissions of `/usr/local`'s subdirectories. If you’re unsure what to do, you can run `cd /usr/local && sudo chown -R $(whoami) bin etc include lib sbin share var opt Cellar Caskroom Frameworks`. 15 | * Read through the [Common Issues](Common-Issues.md). 16 | 17 | ## Check to see if the issue has been reported 18 | 19 | * Search the [issue tracker](https://github.com/Homebrew/homebrew-core/issues) to see if someone else has already reported the same issue. 20 | * Make sure you search issues on the correct repository. If a formula that has failed to build is part of a non-homebrew-core tap or a cask is part of [Homebrew/cask](https://github.com/Homebrew/homebrew-cask/issues) check those issue trackers instead. 21 | 22 | ## Create an issue 23 | 24 | If your problem hasn't been solved or reported, then create an issue: 25 | 26 | 0. Upload debugging information to a [Gist](https://gist.github.com): 27 | - If you had a formula-related problem: run `brew gist-logs ` (where `` is the name of the formula). 28 | - If you encountered a non-formula problem: upload the output of `brew config` and `brew doctor` to a new [Gist](https://gist.github.com). 29 | 1. [Create a new issue](https://github.com/Homebrew/homebrew-core/issues/new/choose). 30 | - Give your issue a descriptive title which includes the formula name (if applicable) and the version of macOS you are using. For example, if a formula fails to build, title your issue "\ failed to build on \<10.x>", where "\" is the name of the formula that failed to build, and "\<10.x>" is the version of macOS you are using. 31 | - Include the URL output by `brew gist-logs ` (if applicable). 32 | - Include links to any additional Gists you may have created (such as for the output of `brew config` and `brew doctor`). 33 | -------------------------------------------------------------------------------- /src/Maintainers-Avoiding-Burnout.md: -------------------------------------------------------------------------------- 1 | # Maintainers: Avoiding Burnout 2 | 3 | **This guide is for maintainers.** These special people have **write 4 | access** to Homebrew’s repository and help merge the contributions of 5 | others. You may find what is written here interesting, but it’s 6 | definitely not for everyone. 7 | 8 | ## 1. Use Homebrew 9 | 10 | Maintainers of Homebrew should be using it regularly. This is partly because 11 | you won't be a good maintainer unless you can put yourself in the shoes of our 12 | users, but also because you may decide to stop using Homebrew and at that point 13 | you should also decide not to be a maintainer and find other things to work on. 14 | 15 | ## 2. No Guilt About Leaving 16 | 17 | All maintainers can stop working on Homebrew at any time without any guilt or 18 | explanation (like leaving a job). We may still ask for your help with questions 19 | after you leave but you are under no obligation to answer them. Like a job, if 20 | you create a big mess and then leave you still have no obligations but we may 21 | think less of you (or, realistically, probably just revert the problematic 22 | work). Like a job, you should probably take a break from Homebrew at least a few 23 | times a year. 24 | 25 | This also means contributors should be consumers. If an owner finds they are 26 | not using a project in the real world, they should reconsider their involvement 27 | with the project. 28 | 29 | ## 3. Prioritise Maintainers Over Users 30 | 31 | It's important to be user-focused but ultimately, as long as you follow #1 32 | above, Homebrew's minimum number of users will be the number of maintainers. 33 | However, if Homebrew has no maintainers it will quickly become useless to all 34 | users and the project will die. As a result, no user complaint, behaviour or 35 | need takes priority over the burnout of maintainers. If users do not like the 36 | direction of the project, the easiest way to influence it is to make 37 | significant, high-quality code contributions and become a maintainer. 38 | 39 | ## 4. Learn To Say No 40 | 41 | Homebrew gets a lot of feature requests, non-reproducible bug reports, usage 42 | questions and PRs we won't accept. These should be closed out as soon as we 43 | realise that they aren't going to be resolved or merged. This is kinder than 44 | deciding this after a long period of review. Our issue tracker should reflect 45 | work to be done. 46 | 47 | --- 48 | 49 | _Thanks to https://gist.github.com/ryanflorence/124070e7c4b3839d4573 which influenced this document_ 50 | -------------------------------------------------------------------------------- /src/How-to-Create-and-Maintain-a-Tap.md: -------------------------------------------------------------------------------- 1 | # How to Create and Maintain a Tap 2 | 3 | Taps are external sources of Homebrew formulae and/or external commands. They 4 | can be created by anyone to provide their own formulae and/or external commands 5 | to any Homebrew user. 6 | 7 | ## Creating a tap 8 | A tap is usually a Git repository available online, but you can use anything as 9 | long as it’s a protocol that Git understands, or even just a directory with 10 | files in it. 11 | If hosted on GitHub, we recommend that the repository’s name start with 12 | `homebrew-`. 13 | 14 | Tap formulae follow the same format as the core’s ones, and can be added at the 15 | repository’s root, or under `Formula` or `HomebrewFormula` subdirectories. We 16 | recommend the latter options because it makes the repository organisation 17 | easier to grasp, and top-level files are not mixed with formulae. 18 | 19 | See [homebrew/core](https://github.com/Homebrew/homebrew-core) for an example of 20 | a tap with a `Formula` subdirectory. 21 | 22 | ### Installing 23 | If it’s on GitHub, users can install any of your formulae with 24 | `brew install user/repo/formula`. Homebrew will automatically add your 25 | `github.com/user/homebrew-repo` tap before installing the formula. 26 | `user/repo/formula` points to the `github.com/user/homebrew-repo/**/formula.rb` 27 | file here. 28 | 29 | If they want to get your tap without installing any formula at the same time, 30 | users can add it with the [`brew tap` command](Taps.md). 31 | 32 | If it’s on GitHub, they can use `brew tap user/repo`, where `user` is your 33 | GitHub username and `homebrew-repo` your repository. 34 | 35 | If it’s hosted outside of GitHub, they have to use `brew tap user/repo `, 36 | where `user` and `repo` will be used to refer to your tap and `` is your 37 | Git clone URL. 38 | 39 | Users can then install your formulae either with `brew install foo` if there’s 40 | no core formula with the same name, or with `brew install user/repo/foo` to 41 | avoid conflicts. 42 | 43 | ## Maintaining a tap 44 | A tap is just a Git repository so you don’t have to do anything specific when 45 | making modifications, apart from committing and pushing your changes. 46 | 47 | ### Updating 48 | Once your tap is installed, Homebrew will update it each time a user runs 49 | `brew update`. Outdated formulae will be upgraded when a user runs 50 | `brew upgrade`, like core formulae. 51 | 52 | ## External commands 53 | You can provide your tap users with custom `brew` commands by adding them in a 54 | `cmd` subdirectory. [Read more on external commands](External-Commands.md). 55 | 56 | See [homebrew/aliases](https://github.com/Homebrew/homebrew-aliases) for an 57 | example of a tap with external commands. 58 | -------------------------------------------------------------------------------- /src/Prose-Style-Guidelines.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 散文风格导则 3 | 4 | 这是一组针对用户、贡献者和维护者的Homebrew散文文档的风格和使用指南(与可执行计算机代码相反).它适用于类似于`docs`在`Homebrew/brew`储存库,通知电子邮件,以及与家庭自制社区的其他通信. 5 | 6 | 这不适用于任何红宝石或其他计算机代码.您可以使用它来通知从计算机代码中提取的技术文档,比如嵌入的手册页,但这只是一个建议. 7 | 8 | ## 目标与受众 9 | 10 | HOBPROW的散文文档的主要目标是与用户和贡献者交流.用户在这里包括"贡献者",无论你在哪里看到"用户",你都可以替代"用户和贡献者". 11 | 12 | 可理解性胜过任何特定的风格准则. 13 | 14 | 用户胜过维护者,除非是以维护者为中心的文档. 15 | 16 | Homebrew的受众包括具有广泛教育和经验的用户,以及英语不是母语的用户.我们的目标是支持尽可能多的用户. 17 | 18 | 我们追求"正确"而非"幻想"的用法.想想报纸上的文章,而不是学术论文. 19 | 20 | 这是一套使用人类判断的准则,而不是一套硬性规则.它就像[《经济学人》风格指南](https://www.economist.com/styleguide/introduction)或[Garner的现代美国用法](https://en.wikipedia.org/wiki/Garner's_Modern_American_Usage). 它不像[红宝石风格指南](https://github.com/bbatsov/ruby-style-guide). 这里的所有准则都是开放的.100%符合这些准则的是*不*进球. 21 | 22 | 本文档的目的是帮助作者作出关于清晰度、风格和一致性的决定.它不是帮助解决关于谁更懂英语的争论.不要用这个文件来做蠢事. 23 | 24 | ## 指南 25 | 26 | 我们更喜欢: 27 | 28 | ### 风格与用法 29 | 30 | - 英/英英语对美国英语的影响 31 | - "例如"和"":继续使用"例如"或"即",而不是拼写出来.不要担心在后面加逗号. 32 | - "例如"意思是"例如"; 33 | - 带逗号的非平凡从属子句 34 | 35 | ### 人称代词 36 | 37 | - 我们尊重所有人对人称代词的选择 38 | - 当某人的性别未知时,"他们"是单数的 39 | - 在不必要时避免性别特定语言 40 | 41 | ### 结构与标记 42 | 43 | - 章节标题中的句子案例,而不是标题案例 44 | - 在列表项的末尾,列表中的大多数项目都是完整的句子. 45 | - 更一般地,并行列表项结构 46 | - 如果需要,将所有列表项都大写,即使它们不是完整的句子;只要在每个列表内保持一致,最好是在整个页面内保持一致. 47 | - 使用从属列表项,而不是将多个句子段的长项丢到句子片段的列表中. 48 | - 除非需要特定的特征,否则要优先于其他标记格式. 49 | - GITHUB口味降价.GITHUB的实施是标准,周期. 50 | 51 | ### 排版约定 52 | 53 | - 命令和代码中的文字是`fixed width font` 54 | - 代码段内的占位符标记为`<...>`括号 55 | - 例如`git remote add https://github.com//homebrew-core.git` 56 | - 命令的名称`git`和`brew`样式为`fixed width font` 57 | - 在代码段外没有提到"$"的环境变量 58 | - 例如"设置"`BLAH`到5个"不是"集合`$BLAH`"5" 59 | - 一个时间间隔,而不是两个空间 60 | - 大写专有名词 61 | - 除了专有名词的正常大写和简单的内部大写之外,我们并不遵循广泛的非标准大写、排版或其他品牌名称样式. 62 | - 没有"TM",占地面积,性虐待,专利权,®或其他明确的权利所有权或商标的指标;当提到品牌名称时,我们理解这些. 63 | - 点击名字`homebrew/core`样式为`fixed width font`. 存储库名称可以用固定宽度的字体来命名.`Homebrew/homebrew-core`"像链接一样"[自制/自制核心](https://github.com/homebrew/homebrew-core)"或"像"自制/自制核心"这样的规则文本,基于它,对于给定的使用来说,它看起来是最好的. 64 | - 但在一个文件内保持一致 65 | - 将存储库名称与GITHUB上的用户和存储库名称匹配.在小写中保持TAP名称. 66 | - 逗号 67 | - 没有牛津逗号 68 | - 喜欢一个"松散"逗号风格:"当有疑问,离开它",除非需要明确. 69 | 70 | ### 术语、词和词造型 71 | 72 | - "拉请求",而不是"拉请求" 73 | - "签出"是动词;"结帐"是名词. 74 | - 拼写某些技术词汇 75 | - "知识库",而不是"回购" 76 | - 在缩写时,在任何文档中介绍第一个用法的缩写. 77 | - 不过,一些缩略语(几乎在我们的用户群中普遍理解)是很好的. 78 | - "MAC"很好,"Macintosh"不是必需的. 79 | - "MaOS"的所有版本,"OS X"或"Mac OS X"时,描述特定的旧版本 80 | - "红宝石",而不是"Rubocop" 81 | - 在存储库上创建一个"拉"请求;存储库位于"URL". 82 | 83 | ## 如何使用这些指南 84 | 85 | 参考这些指南,在自制的文档和交流中,为自己的写作风格和用法做出决定. 86 | 87 | 在文档或多个文档中修复样式和用法的PRS是好的,并且受到鼓励.只是一个或两个风格变化的PRS有点多. 88 | 89 | 在PR或提交文档时给出风格和用法反馈是好的,并得到鼓励.但请记住,这些只是指导方针,对于任何变化,作者可能已经作出深思熟虑的选择,打破这些规则,以利于理解或美学. 90 | -------------------------------------------------------------------------------- /src/Bottles.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 瓶(二元包装) 3 | 4 | 瓶子是通过安装配方来生产的.`brew install --build-bottle `然后装瓶`brew bottle `. 这将输出应该插入公式文件的瓶子DSL. 5 | 6 | ## 用法 7 | 8 | 如果一个瓶子是可用的,它将被下载并自动倾倒当你`brew install `. 如果你想禁用这个,你可以通过指定`--build-from-source`. 9 | 10 | 如果用户请求它(见上文),如果公式要求它,则不使用瓶子.`pour_bottle?`如果在安装过程中指定了任何选项(瓶子都用默认选项编译),如果瓶子不是最新的(例如,缺少校验和),或者如果瓶子的`cellar`不是`:any`也不等于电流`HOMEBREW_CELLAR`. 11 | 12 | ## 创造 13 | 14 | 瓶子是用[酿造试验机器人](Brew-Test-Bot.md). 这主要发生在人们向家庭和家庭提出请求的时候.`bottle do`块维护时更新`brew pull --bottle`拉请求的内容.对于自制软件的龙头,它们被上传到下载.[双托盘](https://bintray.com/homebrew). 15 | 16 | 默认情况下,瓶子将为您正在构建的OS/体系结构支持的最老的CPU构建(64位OS的核心2).这确保瓶子与所有你可以分发的电脑兼容.如果你*真的?*希望你的瓶子被其他东西优化,你可以通过`--bottle-arch=`构建另一架构的选项——例如,`brew install foo --bottle-arch=penryn`. 请记住,如果您为更新的架构构建,您的一些用户可能会得到他们无法运行的二进制文件,那将是令人遗憾的! 17 | 18 | ## 格式 19 | 20 | 瓶子是编译后的二进制文件的简单gpip.任何元数据都存储在公式的瓶子DSL和瓶子文件名(即MACOS版本,修订版)中. 21 | 22 | ## 瓶DSL(领域特定语言) 23 | 24 | 瓶子有一个DSL用于公式中,它包含在`bottle do ... end`块. 25 | 26 | 一个简单的(典型的)例子: 27 | 28 | ```ruby 29 | bottle do 30 | sha256 "4921af80137af9cc3d38fd17c9120da882448a090b0a8a3a19af3199b415bfca" => :sierra 31 | sha256 "c71db15326ee9196cd98602e38d0b7fb2b818cdd48eede4ee8eb827d809e09ba" => :el_capitan 32 | sha256 "85cc828a96735bdafcf29eb6291ca91bac846579bcef7308536e0c875d6c81d7" => :yosemite 33 | end 34 | ``` 35 | 36 | 一个完整的例子: 37 | 38 | ```ruby 39 | bottle do 40 | root_url "https://example.com" 41 | prefix "/opt/homebrew" 42 | cellar "/opt/homebrew/Cellar" 43 | rebuild 4 44 | sha256 "4921af80137af9cc3d38fd17c9120da882448a090b0a8a3a19af3199b415bfca" => :sierra 45 | sha256 "c71db15326ee9196cd98602e38d0b7fb2b818cdd48eede4ee8eb827d809e09ba" => :el_capitan 46 | sha256 "85cc828a96735bdafcf29eb6291ca91bac846579bcef7308536e0c875d6c81d7" => :yosemite 47 | end 48 | ``` 49 | 50 | ### 根地址`root_url`) 51 | 52 | 可选地包含用于计算瓶子URL的URL根目录.默认情况下,这将被省略,使用自制的默认瓶子URL根.这可能是有用的抽头,希望提供瓶的公式或迎合非违约.`HOMEBREW_CELLAR`. 53 | 54 | ### 地窖(地下室)`cellar`) 55 | 56 | 可选地包含值`HOMEBREW_CELLAR`瓶子是在其中建造的.大多数编译软件包含对其编译位置的引用,因此不能简单地重新定位磁盘上的任何位置.如果这个值是`:any`或`:any_skip_relocation`这意味着瓶子可以安全地安装在任何地窖中,因为它不包含任何关于它的安装地窖的参考.如果一个瓶子被编译(缺省的所有自制程序都是默认的),则可以省略这一点.`HOMEBREW_CELLAR`属于`/usr/local/Cellar`. 57 | 58 | ### 前缀(前缀)`prefix`) 59 | 60 | 可选地包含值`HOMEBREW_PREFIX`瓶子是在其中建造的.见描述`cellar`. 什么时候?`cellar`是`:any`或`:any_skip_relocation`前缀应该省略. 61 | 62 | ### 重建版本`rebuild`) 63 | 64 | 可选地包含瓶子的重建版本.有时瓶子可能需要更新而不碰撞公式的版本,例如应用了一个新的补丁.在这种情况下,重建将具有1或更多的值. 65 | 66 | ### 校验和`sha256`) 67 | 68 | 包含一个特定版本的MACOS的瓶子的SAH256散列. 69 | 70 | ## 公式DSL 71 | 72 | 另外,在公式DSL中有一种方法可用. 73 | 74 | ### 倒瓶`pour_bottle?`) 75 | 76 | 可选地返回一个布尔值来决定这个公式是否应该使用一个瓶子.例如,如果使用非默认选项编译了另一个公式,则瓶子可能会中断,因此此方法可以检查这种情况并返回`false`. 77 | 78 | 一个完整的例子: 79 | 80 | ```ruby 81 | pour_bottle? do 82 | reason "The bottle needs the Xcode CLT to be installed." 83 | satisfy { MacOS::CLT.installed? } 84 | end 85 | ``` 86 | -------------------------------------------------------------------------------- /src/External-Commands.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 外部命令 3 | 4 | 自制,如Git,支持*外部命令*. 这使您可以创建新的命令,这些命令可以运行如下: 5 | 6 | ```sh 7 | brew mycommand --option1 --option3 formula 8 | ``` 9 | 10 | 不修改自制的内部设备. 11 | 12 | ## 命令类型 13 | 14 | 外部命令有两种味道:Ruby命令和shell脚本. 15 | 16 | 在这两种情况下,命令文件都应该是可执行的(`chmod +x`住在某处`PATH`. 17 | 18 | ### 红宝石命令 19 | 20 | 外部命令`extcmd`作为Ruby命令实现的应该命名为`brew-extcmd.rb`. 通过执行一个命令来执行命令.`require`在完全路径名上.因为命令是`require`d,它可以完全访问Homebrew"环境",即任何内部命令可以访问的所有全局变量和模块.小心使用自制的内部设备,它们随时可能发生变化而没有警告. 21 | 22 | 命令可以`Kernel.exit`如果需要状态代码,如果它没有明确退出,那么自制程序将返回.`0`. 23 | 24 | ### 外壳脚本 25 | 26 | 命令的shell脚本`extcmd`应该命名`brew-extcmd`. 此文件将通过`exec`将一些自制变量设置为环境变量,并传递任何附加命令行参数. 27 | 28 | | 变量 | 描述 | 29 | | ----------------------- | ---------------------------------------------------------------------------------- | 30 | | `HOMEBREW_CACHE` | 默认情况下,自制程序缓存下载TayBar到何处`~/Library/Caches/Homebrew`. | 31 | | `HOMEBREW_CELLAR` | 自酿窖的位置,软件在那里上演.这将是`HOMEBREW_PREFIX/Cellar`如果该目录存在,或`HOMEBREW_REPOSITORY/Cellar`否则. | 32 | | `HOMEBREW_LIBRARY_PATH` | 包含自制程序应用程序代码的目录. | 33 | | `HOMEBREW_PREFIX` | 其中自制软件安装软件.这一直是祖父母的目录`brew`可执行的,`/usr/local`默认情况下. | 34 | | `HOMEBREW_REPOSITORY` | 如果从Git克隆中安装了存储库目录(即HealBurw的.git目录生存的地方). | 35 | 36 | 请注意,脚本本身可以使用任何合适的SHBON(`#!`"行",因此可以为SH、BASH、Ruby或其他任何东西编写外部"shell脚本". 37 | 38 | ## 提供`--help` 39 | 40 | 所有内部和外部自制命令都可以提供样式.`--help`用线开始输出`#:`(然后评论)`:`在BASH和Ruby中的字符,然后输出`--help`. 41 | 42 | 例如,参见[页眉`brew services`](https://github.com/Homebrew/homebrew-services/blob/a5115e47b05e8d2a632ba7775599e698b240e5a2/cmd/brew-services.rb#L1-L31)输出`brew services --help`. 43 | 44 | ## 家庭自制组织外部命令 45 | 46 | ### 自酿活期支票 47 | 48 | 检查是否有一个新的上游版本的公式.见[`README`](https://github.com/Homebrew/homebrew-livecheck/blob/master/README.md)更多信息和用法. 49 | 50 | 安装使用: 51 | 52 | ```sh 53 | brew tap homebrew/livecheck 54 | ``` 55 | 56 | ### 找不到自制命令 57 | 58 | 乌本图`command-not-found equivalent`适合自制.见[`README`](https://github.com/Homebrew/homebrew-command-not-found/blob/master/README.md)更多信息和用法. 59 | 60 | 安装使用: 61 | 62 | ```sh 63 | brew tap homebrew/command-not-found 64 | ``` 65 | 66 | ### 家庭酿别名 67 | 68 | 允许您别名自制命令.见[`README`](https://github.com/Homebrew/homebrew-aliases/blob/master/README.md)更多信息和用法. 69 | 70 | 安装使用: 71 | 72 | ```sh 73 | brew tap homebrew/aliases 74 | ``` 75 | 76 | ## 非官方外部命令 77 | 78 | 这些命令由Homebrew用户提供,但不包括在主Homebrew组织中,也不由安装程序脚本安装.您可以手动安装它们,如上所述. 79 | 80 | 注意,它们基本上未被测试,并且总是在机器上运行未经测试的代码时要小心. 81 | 82 | ### 酿造宝石 83 | 84 | 安装任何`gem`包装成一个自给自足的自制酒窖位置:[HTTPS://GITHUBCOM/SPARTNTIG/BURW-GEM](https://github.com/sportngin/brew-gem) 85 | 86 | 注意这也可以安装在一起.`brew install brew-gem`. 87 | -------------------------------------------------------------------------------- /src/How-to-build-software-outside-Homebrew-with-Homebrew-keg-only-dependencies.md: -------------------------------------------------------------------------------- 1 | # How to build software outside Homebrew with Homebrew `keg_only` dependencies 2 | 3 | ## What does "keg-only" mean? 4 | 5 | The [FAQ](FAQ.md) briefly explains this. 6 | 7 | As an example: 8 | 9 | *OpenSSL isn’t symlinked into my `PATH` and non-Homebrew builds can’t find it!* 10 | 11 | This is because Homebrew keeps it locked inside its individual prefix, rather than symlinking to the publicly-available location, usually `/usr/local`. 12 | 13 | ## Advice on potential workarounds 14 | 15 | A number of people in this situation are either forcefully linking `keg_only` tools with `brew link --force` or moving default system utilities out of the `PATH` and replacing them with manually-created symlinks to the Homebrew-provided tool. 16 | 17 | *Please* do not remove macOS native tools and forcefully replace them with symlinks back to the Homebrew-provided tool. Doing so can and likely will cause significant breakage when attempting to build software. 18 | 19 | `brew link --force` creates a warning in `brew doctor` to let both you and maintainers know that a link exists that could be causing issues. If you’ve linked something and there’s no problems at all? Feel free to ignore the `brew doctor` error. 20 | 21 | ## How do I use those tools outside of Homebrew? 22 | 23 | Useful, reliable alternatives exist should you wish to use `keg_only` tools outside of Homebrew. 24 | 25 | ### Build flags 26 | 27 | You can set flags to give configure scripts or Makefiles a nudge in the right direction. An example of flag setting: 28 | 29 | ```sh 30 | ./configure --prefix=/Users/Dave/Downloads CFLAGS=-I$(brew --prefix)/opt/openssl/include LDFLAGS=-L$(brew --prefix)/opt/openssl/lib 31 | ``` 32 | 33 | An example using `pip`: 34 | 35 | ```sh 36 | CFLAGS=-I$(brew --prefix)/opt/icu4c/include LDFLAGS=-L$(brew --prefix)/opt/icu4c/lib pip install pyicu 37 | ``` 38 | 39 | ### `PATH` modification 40 | 41 | You can temporarily prepend your `PATH` with the tool’s bin directory, such as: 42 | 43 | ```sh 44 | export PATH=$(brew --prefix)/opt/openssl/bin:$PATH 45 | ``` 46 | 47 | This will prepend that folder to your `PATH`, ensuring any build script that searches the `PATH` will find it first. 48 | 49 | Changing your `PATH` using that command ensures the change only exists for the duration of that shell session. Once you are no longer in that session, the `PATH` reverts to the prior state. 50 | 51 | ### `pkg-config` detection 52 | 53 | If the tool you are attempting to build is [pkg-config](https://en.wikipedia.org/wiki/Pkg-config) aware, you can amend your `PKG_CONFIG_PATH` to find that `keg_only` utility’s `.pc` file, if it has them. Not all formulae ship with those files. 54 | 55 | An example of this is: 56 | 57 | ```sh 58 | export PKG_CONFIG_PATH=$(brew --prefix)/opt/openssl/lib/pkgconfig 59 | ``` 60 | 61 | If you’re curious about the `PKG_CONFIG_PATH` variable `man pkg-config` goes into more detail. 62 | 63 | You can get `pkg-config` to detail the default search path with: 64 | 65 | ```sh 66 | pkg-config --variable pc_path pkg-config 67 | ``` 68 | -------------------------------------------------------------------------------- /src/Analytics.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 匿名聚合用户行为分析 3 | 4 | HealBurw已经开始收集匿名聚合用户行为分析,并将这些报告给谷歌Analytics.您将在第一次运行时通知您.`brew update`或者安装自制软件. 5 | 6 | ## 为什么? 7 | 8 | 自制饮料免费提供,在业余时间完全由志愿者操作.因此,我们没有资源对Homebrew用户进行详细的用户研究,以决定如何最好地设计未来的特性和优先考虑当前的工作.匿名聚合用户分析允许我们根据如何、何时何地和何时使用自制软件来优先定位修复和特征.例如: 9 | 10 | - 如果一个公式被广泛使用并且经常失败,它将使我们能够优先考虑将公式固定在别人之上. 11 | - 收集OS版本允许我们决定哪些版本的macOS优先次序并支持并确定只发生在单个版本上的构建失败. 12 | 13 | ## 多长时间? 14 | 15 | HouBurw的匿名用户和事件数据有14个月的保留期.这就是[谷歌分析的最低可能值](https://support.google.com/analytics/answer/7667196). 16 | 17 | ## 什么? 18 | 19 | HealBurw的分析记录了每个事件的一些共享信息: 20 | 21 | - 家庭用户代理,例如`Homebrew/0.9.9 (Macintosh; Intel macOS 10.12.0) curl/7.43.0` 22 | - 谷歌分析版,即`1`([http://开发商:谷歌.com/Analytics/DeValc/集合/协议/V1/参数ⅤV](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#v)) 23 | - 自制分析跟踪ID,例如`UA-75654628-1`([http://开发商:谷歌.com/Analytics/DeValc/集合/协议/V1/参数](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#tid)) 24 | - 自制分析用户ID,例如`1BAB65CC-FE7F-4D8C-AB45-B7DB5A6BA9CB`. 这是由`uuidgen`并存储在仓库特定的Git配置变量中`homebrew.analyticsuuid`在内部`$(brew --repository)/.git/config`. 这不允许我们跟踪单个用户,但能使我们准确地测量用户计数与事件计数.[http://开发商:谷歌.COM/Analytics/DeValc/集合/协议/V1/参数](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#cid)) 25 | - 如果启用了谷歌Analytics匿名IP设置,即`1`([http://开发商:谷歌.com/Analytics/DeValc/集合/协议/V1/参数](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#aip)) 26 | - 自制应用程序名称,例如`Homebrew`([http://开发商:谷歌.com/Analytics/DeVals/Studio/Value/V1/Type](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#an)) 27 | - 自制应用程序版本,例如`0.9.9`([http://开发商:谷歌.COM/Analytics/DeValc/集合/协议/V1/参数AVAV](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#av)) 28 | - HouBurw分析击中类型,例如`event`([http://开发商:谷歌.COM/Analytics/DeVals/Copys/Value/V1/Type](https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#t)) 29 | 30 | HoubBurw的分析记录了以下不同的事件: 31 | 32 | - 安`event`命中类型`install`事件类别和来自非私有GITHUB TAP的HOBURW公式,以及任何使用的选项,例如`wget --with-pcre`作为动作和事件标签,例如`macOS 10.12, non-/usr/local, CI`指示操作系统版本,非标准安装位置和调用作为CI的一部分.这使我们能够识别需要固定的公式,并且在哪里更容易. 33 | - 安`event`命中类型`install_on_request`事件类别和来自请求安装的非私有GitHub抽头的Homebrew公式(例如,使用`brew install`)加上选项和上面的事件标签.这使我们能够区分用户想要安装的公式和依赖的公式. 34 | - 安`event`命中类型`cask_install`事件类别和来自非私有Github TAP的自制桶,作为上述操作和事件标签安装.这使我们能够识别需要固定的桶,更容易识别. 35 | - 安`event`命中类型`BuildError`事件类别和无法安装的HOBBURW公式,例如`wget`作为动作和事件标签,例如`macOS 10.12`. 36 | 37 | 您还可以通过设置来查看由HealBurw的Analytics发送的所有信息.`HOMEBREW_ANALYTICS_DEBUG=1`在你的环境中.请注意,这也将停止任何分析被发送. 38 | 39 | 即使我们能够访问Homebrew分析用户ID(我们没有),Homebrew开发人员也不可能将任何特定事件匹配到任何特定用户.从谷歌Analytics中我们可以看到最用户特定的信息: 40 | 41 | ![Aggregate user analytics](assets/img/docs/analytics.png) 42 | 43 | 据我们所知,Google不可能将随机生成的纯自助分析用户ID与任何其他Google分析用户ID进行匹配.女装. 44 | 45 | ## 何时何地? 46 | 47 | HutBurw的分析在整个家庭的执行过程中通过HTTPS发送到谷歌分析. 48 | 49 | ## 谁? 50 | 51 | 安装和错误分析的摘要是公开可用的[在这里](https://brew.sh/analytics/). JSON API也是可用的. 52 | 53 | ## 怎么用? 54 | 55 | 代码是可查看的[分析RB](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils/analytics.rb)和[分析学](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils/analytics.sh). 它们是在单独的后台进程中完成的,并且失败很快,以避免延迟执行.如果你没有网络连接,他们会立即失败. 56 | 57 | ## 选择退出 58 | 59 | 自制分析帮助我们维护和离开它是值得赞赏的.但是,如果你想选择HouBurw的分析,你可以在你的环境中设置这个变量: 60 | 61 | ```sh 62 | export HOMEBREW_NO_ANALYTICS=1 63 | ``` 64 | 65 | 或者,这将防止分析被发送: 66 | 67 | ```sh 68 | brew analytics off 69 | ``` 70 | -------------------------------------------------------------------------------- /src/How-To-Open-a-Homebrew-Pull-Request.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 如何打开自制中断请求(并将其合并) 3 | 4 | Homebrew贡献者使用以下命令在GitHub上设置Homebrew的Git存储库的分支,创建新的分支并创建该分支中的更改的GitHub拉请求("PR"). 5 | 6 | 根据您想要进行的更改,需要将拉请求发送到Homebrew的主存储库中的适当一个存储库.如果你想提交一个改变自制代码的核心代码`brew`实现),您应该打开拉请求[自制/酿造](https://github.com/Homebrew/brew). 如果您想提交一个公式的更改,您应该打开[这个`homebrew/core`水龙头](https://github.com/Homebrew/homebrew-core)或另一个[官方抽头](https://github.com/Homebrew),根据公式类型. 7 | 8 | ## 提交现有公式的新版本 9 | 10 | 1. 使用`brew bump-formula-pr`用一个命令来做任何事情(即分叉、提交、推送).跑`brew bump-formula-pr --help`学习更多. 11 | 12 | ## 建立自己的自制软件仓库 13 | 14 | ### 核心`brew`代码相关的拉动请求 15 | 16 | 1. [在Github上移植自制/酿造仓库](https://github.com/Homebrew/brew/fork). 17 | 18 | - 这将创建一个可以推到的个人远程存储库.这是需要的,因为只有自制软件维护者才有权进入主要的存储库. 19 | 20 | 2. 更改包含您的自制程序的目录`cd $(brew --repository)`. 21 | 3. 添加你的可推叉仓库`git remote add https://github.com//brew.git`. 22 | 23 | - ``是您的GITHUB用户名,不是本地机器用户名. 24 | 25 | ### 有关拉动请求的公式 26 | 27 | 1. [在Github上移植自制/自制的核心存储库](https://github.com/Homebrew/homebrew-core/fork). 28 | 29 | - 这将创建一个可以推到的个人远程存储库.这是需要的,因为只有自制软件维护者才有权进入主要的存储库. 30 | 31 | 2. 更改包含自制公式的目录`cd $(brew --repository homebrew/core)`. 32 | 3. 添加你的可推叉仓库`git remote add https://github.com//homebrew-core.git` 33 | 34 | - ``是您的GITHUB用户名,不是本地机器用户名. 35 | 36 | ## 从新分支创建您的拉请求 37 | 38 | 要创建一个新的分支并提交它进行审查,请创建一个GITHUB拉请求,其步骤如下: 39 | 40 | 1. 退房`master`分支机构`git checkout master`. 41 | 2. 检索新的更改`master`分支机构`brew update`. 42 | 3. 从最新创建一个新的分支`master`分支机构`git checkout -b origin/master`. 43 | 4. 做出改变.对于公式,使用`brew edit`或者你最喜欢的文本编辑器,遵循所有的指南[公式食谱](Formula-Cookbook.md). 44 | 45 | - 如果有`bottle do`方块中的公式,不要删除或更改它;我们会更新它时,我们拉你的PR. 46 | 47 | 5. 通过执行以下测试来测试更改,并确保它们无问题地通过.对于变化的公式,请务必做.`brew audit`在安装更改公式时执行步骤. 48 | 49 | - `brew tests` 50 | - `brew install --build-from-source ` 51 | - `brew test ` 52 | - `brew audit --strict ` 53 | 54 | 6. 对每一个改变的公式做出单独的提交`git add`和`git commit`. 55 | 7. 把你的新约定上传到你的叉子上`git push --set-upstream `. 56 | 8. 转到相关的存储库(例如[HTTPS://GITHUBCOM/HOMEBWW/BRW](https://github.com/Homebrew/brew),[HTTPS://GITHUBCOM/HOMEBWW/HOMEBRW-CORE](https://github.com/Homebrew/homebrew-core)等,并创建一个拉请求,要求审查和合并的提交在您的推动分支.解释为什么需要改变,如果修复bug,如何重现bug.确保你已经完成了在你的新PR中出现的清单中的每一步. 57 | 58 | - 请注意,我们对于简单版本更新的首选提交消息格式是"` `"例如"`source-highlight 3.1.8`".`devel`版本更新应该具有提交消息.`(devel)`,例如"`nginx 1.9.1 (devel)`".如果同时更新`stable`和`devel`格式应该是这两种形式的连接,例如"`x264 r2699, r2705 (devel)`". 59 | 60 | 9. 等待反馈或来自自制软件的维护者的合并.我们通常在几天内响应所有PRS,但可能需要长达一个星期,这取决于维护人员的工作量. 61 | 62 | 谢谢您! 63 | 64 | ## 跟进 65 | 66 | 对反馈作出良好反应: 67 | 68 | 1. 要求澄清任何你不理解的事情,并帮助你做任何你不知道该怎么做的事情. 69 | 2. 你贴上拉要求评论,如果你提供的所有变更请求的信息,它没有被合并后的一个星期.如果你陷入困境需要帮助,就发表评论. 70 | 71 | - 一`needs response`PR上的标签意味着自制软件维护者需要你对先前的评论做出回应. 72 | 73 | 3. 除非有其他要求,否则请在拉取请求中保持讨论(即不要私下向维护者发电子邮件). 74 | 4. 不要在关闭的拉请求中继续讨论. 75 | 5. 不要和自制软件维护者争论.你可能不同意,但除非他们改变主意,请执行他们的要求.最终,他们控制了在自制中所包含的内容,因为它们必须支持所做的任何更改. 76 | 77 | 基于反馈进行更改: 78 | 79 | 1. 再次检查你的分支`git checkout `. 80 | 2. 进行任何请求的更改并提交`git add`和`git commit`. 81 | 3. SpCub新提交到每个公式的一个提交`git rebase --interactive origin/master`. 82 | 4. 推到远程叉的分支和拉请求`git push --force`. 83 | 84 | 如果你正在做一个单一公式的PR,`git commit --amend`当你走的时候,是一个很方便的方法. 85 | 86 | 一旦所有的反馈都被解决了,如果它是我们想要包含的更改(包括大多数更改),那么我们将把您的提交添加到Homebrew.请注意,由于我们合并捐款的方式,PR状态可能显示为"关闭"而不是"合并".不要担心:在实际合并提交中,您仍然可以获得作者信用. 87 | 88 | 做得好,你现在是一个自制啤酒的贡献者! 89 | -------------------------------------------------------------------------------- /src/Tips-N'-Tricks.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 提示和技巧 3 | 4 | ## 安装公式以前的版本 5 | 6 | 支持某些公式的特定版本的安装方法是看是否有版本化的公式(例如`gcc@6`)可用.如果您找的版本不可用,请考虑使用`brew extract`. 7 | 8 | ### 从拉请求直接安装 9 | 10 | 你可以[浏览拉动请求](https://github.com/Homebrew/homebrew-core/pulls)并通过直接连接进行安装.例如,Python 3.3.0从拉请求[自制/自制啤酒15199](https://github.com/Homebrew/homebrew/pull/15199): 11 | 12 | ```sh 13 | brew install https://raw.github.com/dsr/homebrew/9b22d42f50fcbc5e52c764448b3ac002bc153bd7/Library/Formula/python3.rb 14 | ``` 15 | 16 | ## 快速去除某物`/usr/local` 17 | 18 | ```sh 19 | brew unlink 20 | ``` 21 | 22 | 如果一个包不能建立在你链接到的东西的版本上,这可能是有用的.`/usr/local`. 23 | 24 | 当然,你可以简单地`brew link `再后来! 25 | 26 | ## 激活公式的先前安装版本 27 | 28 | ```sh 29 | brew info 30 | brew switch 31 | ``` 32 | 33 | 使用`brew info `若要检查已安装哪些版本,但未激活当前版本,则`brew switch `激活所需的版本.如果您想在公式的版本之间切换,这可能是有用的. 34 | 35 | ## 在没有公式的情况下安装到自制程序中 36 | 37 | ```sh 38 | ./configure --prefix=/usr/local/Cellar/foo/1.2 && make && make install && brew link foo 39 | ``` 40 | 41 | ## 预先下载一个公式的文件 42 | 43 | 有时候,通过那些可以作为自制软件的一部分的策略下载文件的速度更快.例如,Erlang提供了一个洪流,可以让你下载4到5×普通HTTP方法. 44 | 45 | 下载文件并将其放入`~/Library/Caches/Homebrew`,但请注意文件名.自制程序下载文件`-`. 在Erlang的情况下,这需要重命名文件.`otp_src_R13B03`到`erlang-R13B03`. 46 | 47 | `brew --cache -s erlang`将打印缓存下载的正确名称.这意味着不用手动重命名公式,可以运行.`mv the_tarball $(brew --cache -s )`. 48 | 49 | 还可以使用命令预缓存下载.`brew fetch formula`它还显示了Sha256哈希.这对于更新公式到新版本是有用的. 50 | 51 | ## 不使用XCOLL CLT安装数据 52 | 53 | ```sh 54 | brew sh # or: eval $(brew --env) 55 | gem install ronn # or c-programs 56 | ``` 57 | 58 | 这就进口了`brew`环境进入你现有的外壳;`gem`将拾取环境变量并能够建立.作为奖金`brew`自动设置的优化标志被设置. 59 | 60 | ## 只安装公式的依赖项(不是公式) 61 | 62 | ```sh 63 | brew install --only-dependencies 64 | ``` 65 | 66 | ## 互动自制外壳 67 | 68 | ```sh 69 | $ brew irb 70 | 1.8.7 :001 > Formula.factory("ace").methods - Object.methods 71 | => [:install, :path, :homepage, :downloader, :stable, :bottle, :devel, :head, :active_spec, :buildpath, :ensure_specs_set, :url, :version, :specs, :mirrors, :installed?, :explicitly_requested?, :linked_keg, :installed_prefix, :prefix, :rack, :bin, :doc, :include, :info, :lib, :libexec, :man, :man1, :man2, :man3, :man4, :man5, :man6, :man7, :man8, :sbin, :share, :etc, :var, :plist_name, :plist_path, :download_strategy, :cached_download, :caveats, :options, :patches, :keg_only?, :fails_with?, :skip_clean?, :brew, :std_cmake_args, :deps, :external_deps, :recursive_deps, :system, :fetch, :verify_download_integrity, :fails_with_llvm, :fails_with_llvm?, :std_cmake_parameters, :mkdir, :mktemp] 72 | 1.8.7 :002 > 73 | ``` 74 | 75 | ## 在完成一个建筑时隐藏啤酒杯表情 76 | 77 | ```sh 78 | export HOMEBREW_NO_EMOJI=1 79 | ``` 80 | 81 | 这就设置了HealBurWyNoyEnJi环境变量,导致自制程序隐藏所有表情符号. 82 | 83 | 啤酒表情也可以用其他字符代替: 84 | 85 | ```sh 86 | export HOMEBREW_INSTALL_BADGE="☕️ 🐸" 87 | ``` 88 | 89 | ## 编辑器插件 90 | 91 | ### 崇高文本 92 | 93 | 在崇高文本2/3中,可以使用包控件来安装[自制公式语法](https://github.com/samueljohn/Homebrew-formula-syntax),它为内嵌补丁添加了高亮显示. 94 | 95 | ### Vim 96 | 97 | [啤酒](https://github.com/xu-cheng/brew.vim)在VIM中增加对内嵌补丁的高亮显示. 98 | 99 | ### Emacs 100 | 101 | [自制模式](https://github.com/dunn/homebrew-mode)为内联修补程序提供语法高亮显示,以及用于编辑公式文件的多个辅助函数. 102 | 103 | [自制芯片](https://github.com/hiddenlotus/pcmpl-homebrew)提供Emacs shell模式和ESHELL模式的完成. 104 | 105 | ### 原子 106 | 107 | [语言自制公式](https://atom.io/packages/language-homebrew-formula)添加突出显示和差异支持(与[语言差异](https://atom.io/packages/language-diff)插件). 108 | -------------------------------------------------------------------------------- /src/Installation.md: -------------------------------------------------------------------------------- 1 | # Installation 2 | 3 | The suggested and easiest way to install Homebrew is on the 4 | [homepage](https://brew.sh). 5 | 6 | The standard script installs Homebrew to `/usr/local` so that 7 | [you don’t need sudo](FAQ.md) when you 8 | `brew install`. It is a careful script; it can be run even if you have stuff 9 | installed to `/usr/local` already. It tells you exactly what it will do before 10 | it does it too. And you have to confirm everything it will do before it starts. 11 | 12 | ## Requirements 13 | * An Intel CPU [1](#1) 14 | * macOS 10.12 or higher [2](#2) 15 | * Command Line Tools (CLT) for Xcode: `xcode-select --install`, 16 | [developer.apple.com/downloads](https://developer.apple.com/downloads) or 17 | [Xcode](https://itunes.apple.com/us/app/xcode/id497799835) [3](#3) 18 | * A Bourne-compatible shell for installation (e.g. bash or zsh) [4](#4) 19 | 20 | ## Alternative Installs 21 | 22 | ### OS X Lion 10.7 and below 23 | 24 | Using the instructions on https://brew.sh or below whenever you call `curl` you must pass `--insecure` as an argument. This is because your system `curl` is too old to speak to GitHub using HTTPS. Don't worry, on the first `brew update` Homebrew will install a newer, more secure `curl` for your machine. 25 | 26 | ### Untar anywhere 27 | Just extract (or `git clone`) Homebrew wherever you want. Just 28 | avoid: 29 | 30 | * Directories with names that contain spaces. Homebrew itself can handle spaces, but many build scripts cannot. 31 | * `/tmp` subdirectories because Homebrew gets upset 32 | * `/sw` and `/opt/local` because build scripts get confused when Homebrew is there instead of Fink or MacPorts, respectively. 33 | 34 | However do yourself a favor and install to `/usr/local`. Some things may 35 | not build when installed elsewhere. One of the reasons Homebrew just 36 | works relative to the competition is **because** we recommend installing 37 | to `/usr/local`. *Pick another prefix at your peril!* 38 | 39 | ```sh 40 | mkdir homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew 41 | ``` 42 | 43 | ### Multiple installations 44 | Create a Homebrew installation wherever you extract the tarball. Whichever `brew` command is called is where the packages will be installed. You can use this as you see fit, e.g. a system set of libs in `/usr/local` and tweaked formulae for development in `~/homebrew`. 45 | 46 | ## Uninstallation 47 | Uninstallation is documented in the [FAQ](FAQ.md). 48 | 49 | 1 Not all formulae have CPU or OS requirements, but 50 | you can assume you will have trouble if you don’t conform. Also, you can find 51 | PowerPC and Tiger branches from other users in the fork network. See 52 | [Interesting Taps and Forks](Interesting-Taps-and-Forks.md). 53 | 54 | 2 10.12 or higher is recommended. 10.5–10.11 are 55 | supported on a best-effort basis. For 10.4 see 56 | [Tigerbrew](https://github.com/mistydemeo/tigerbrew). 57 | 58 | 3 Most formulae require a compiler. A handful 59 | require a full Xcode installation. You can install Xcode, the CLT, or both; 60 | Homebrew supports all three configurations. Downloading Xcode may require an 61 | Apple Developer account on older versions of Mac OS X. Sign up for free 62 | [here](https://developer.apple.com/register/index.action). 63 | 64 | 4 The one-liner installation method found on 65 | [brew.sh](https://brew.sh) requires a Bourne-compatible shell (e.g. bash or 66 | zsh). Notably, fish, tcsh and csh will not work. 67 | -------------------------------------------------------------------------------- /src/Gems,-Eggs-and-Perl-Modules.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 宝石、蛋和Perl模块 3 | 4 | 在一个新的MACOS安装上,有三个空目录供所有用户使用: 5 | 6 | ``` 7 | /Library/Ruby 8 | /Library/Python 9 | /Library/Perl 10 | ``` 11 | 12 | 从OS X狮子(10.7)开始,你需要`sudo`像这样安装到:`sudo gem install`,`sudo easy_install`或`sudo cpan -i`. 13 | 14 | 避免SUDO的选项是使用访问控制列表:`chmod +a 'user:YOUR_NAME_HERE allow add_subdirectory,add_file,delete_child,directory_inherit' /Library/Python/3.y/site-packages`例如,将允许您将包添加到Python 3.Y作为自己.这可能比更改目录的组所有权更安全. 15 | 16 | ### 那我为什么要使用SUDO呢? 17 | 18 | 习惯也许? 19 | 20 | 原因之一是可执行文件进入`/usr/local/bin`. 通常这不是可写的位置.但是如果你按照我们的建议安装自制软件,`/usr/local`将没有SUDO可写.所以现在你可以在不使用SUDO的情况下安装你需要的开发工具. 21 | 22 | ## 没有SUDO的Python软件包(蛋) 23 | 24 | 而不是改变权利`/Library/Python`我们建议以下选项: 25 | 26 | ### 用酿造的蟒蛇 27 | 28 | 注:`easy_install`被贬低.我们安装`pip`(或)`pip2`对于Python 2)以及Python/Python 2. 29 | 30 | 我们建立了这样的ditutul`pip install`总是将模块放入`$(brew --prefix)/lib/pythonX.Y/site-packages`和脚本`$(brew --prefix)/share/python`. 所以,你不需要SUDO! 31 | 32 | 做`brew info python`或`brew info python@2`有关路径的精确信息.注意,一个酿造的Python仍然在搜索模块.`/Library/Python/X.Y/site-packages`而且在`~/Library/Python/X.Y/lib/python/site-packages`. 33 | 34 | ### 使用系统的Python 35 | 36 | *这只是建议如果你**不要**使用酿造的蟒蛇.* 37 | 38 | 关于MaOS,任何[Python版本X.Y也在搜索`~/Library/Python/X.Y/lib/python/site-packages`对于模块](https://docs.python.org/2/install/index.html#inst-alt-install-user). DIR可能还不存在,但你可以创建它: 39 | 40 | ```sh 41 | mkdir -p ~/Library/Python/2.7/lib/python/site-packages 42 | ``` 43 | 44 | 教`easy_install`和`pip`要在那里安装,请使用`--user`切换或创建`~/.pydistutils.cfg`文件内容如下: 45 | 46 | ``` 47 | [install] 48 | install_lib = ~/Library/Python/$py_version_short/lib/python/site-packages 49 | ``` 50 | 51 | ### 使用VimaLeNV——与Burw和Python的Python一起工作 52 | 53 | [虚拟现实](http://www.virtualenv.org/en/latest/)船舶`pip`并使用单独的站点包创建孤立的Python环境,因此不需要SUDO. 54 | 55 | ## 无SUDO的RuuGyMS 56 | 57 | **如果你使用RBEV或RVM,那么你应该忽略这些东西.** 58 | 59 | 酿造的Ruby安装可执行文件`$(brew --prefix)/opt/ruby/bin`没有SUDO.你应该把这个添加到你的路径中.请参阅`ruby`最新信息公式. 60 | 61 | ### 随着系统的红宝石 62 | 63 | 使红宝石安装到`/usr/local`我们需要补充`gem: -n/usr/local/bin`对你`~/.gemrc`. 它是YAML,所以手动或使用它: 64 | 65 | ```sh 66 | echo "gem: -n/usr/local/bin" >> ~/.gemrc 67 | ``` 68 | 69 | **然而,1.3.6之前的所有版本的RuGuEMS都是马车.**并且忽略上述设置.遗憾的是,Snow Leopard的新安装有1.3.5.目前唯一已知的方法是将RuuGEMS升级为根: 70 | 71 | ```sh 72 | sudo gem update --system 73 | ``` 74 | 75 | ### 另一种选择 76 | 77 | 只需将所有东西安装到自制程序的前缀中: 78 | 79 | ```sh 80 | echo "export GEM_HOME=\"$(brew --prefix)\"" >> ~/.bashrc 81 | ``` 82 | 83 | ### 不管用!当我尝试安装东西时,我得到一些"权限"错误! 84 | 85 | *注意,也许你不应该在狮子身上这样做,因为苹果公司已经确定它不是一个好的默认.* 86 | 87 | 如果你曾经做过`sudo gem`等之前,许多文件将被创建的根拥有.固定: 88 | 89 | ```sh 90 | sudo chown -R $USER /Library/Ruby /Library/Perl /Library/Python 91 | ``` 92 | 93 | ## 没有SUDO的Perl CPAN模块 94 | 95 | Perl模块`local::lib`与RBEV/RVM类似(虽然仅用于模块,而不是Perl安装).只会污染你的简单解决方案`/Library/Perl`稍加安装[`local::lib`](https://metacpan.org/pod/local::lib)与SUDO: 96 | 97 | ```sh 98 | sudo cpan local::lib 99 | ``` 100 | 101 | 注意,这将安装一些其他类似的依赖项.`Module::Install`. 然后在你的壳牌的启动中放置适当的咒语,例如`.bash_profile`你插入下面,其他人看到[`local::lib`](https://metacpan.org/pod/local::lib)博士学位. 102 | 103 | ```sh 104 | eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib) 105 | ``` 106 | 107 | 现在(在重新启动外壳之后)`cpan`或`perl -MCPAN -eshell`等将安装模块和二进制文件`~/perl5`相关子目录将在您的`PATH`和`PERL5LIB`等. 108 | 109 | ### Perl完全避免SUDO 110 | 111 | 如果你甚至不想(或不能)使用SUDO进行引导`local::lib`只需手动安装即可`local::lib`在里面`~/perl5`并添加相关路径`PERL5LIB`在巴斯克王朝的咒语之前. 112 | 113 | 另一种选择是使用.`perlbrew`在你的家庭目录中安装一个单独的Perl拷贝,或者在任何你喜欢的地方安装: 114 | 115 | ```sh 116 | curl -L https://install.perlbrew.pl | bash 117 | perlbrew install perl-5.16.2 118 | echo ".~/perl5/perlbrew/etc/bashrc" >> ~/.bashrc 119 | ``` 120 | -------------------------------------------------------------------------------- /src/Homebrew-and-Python.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 蟒蛇 3 | 4 | 本页描述了Python是如何在自制程序中为用户处理的.见[公式作者的Python](Python-for-Formula-Authors.md)有关编写公式以安装Python编写的包的建议. 5 | 6 | 自制应该与任何工作[巨嘴鸟](https://stackoverflow.com/questions/2324208/is-there-any-difference-between-cpython-and-python)默认设置为MyOS系统Python. 7 | 8 | HOMBREW提供公式酿造3.x和一个更新的Python 2.7. 9 | 10 | **重要:**如果选择安装不是这两者之一的Python(系统Python或酝酿的Python),则Homebrew团队不能支持可能发生的任何破坏. 11 | 12 | ## Python 3 .x或Python 2 .x 13 | 14 | HybBurw为Python 3 .x提供了一个公式.`python`另一个用于Python 2.7.`python@2`) 15 | 16 | 可执行文件按如下方式组织,使得Python 2和Python 3都可以安装而不冲突: 17 | 18 | - `python3`指向HOBPROW的Python 3 x(如果安装) 19 | - `python2`指向HOBPROW的Python 2.7 x(如果安装) 20 | - `python`指向HOBPROW的Python 2.7 .x(如果安装的话),否则MaOS系统Python.退房`brew info python`如果你想添加自制软件的3.`python`对你`PATH`. 21 | - `pip3`指向HybBurw的Python 3 .x的PIP(如果安装) 22 | - `pip`和`pip2`指向HOBPROW的Python 2.7 .x的PIP(如果安装) 23 | 24 | ([不知该选哪一个?](https://wiki.python.org/moin/Python2orPython3)) 25 | 26 | ## StupTooP、PIP等. 27 | 28 | Python公式的安装[匹普](http://www.pip-installer.org)(AS)`pip`或`pip2`)[设置工具](https://pypi.python.org/pypi/setuptools). 29 | 30 | 可以通过PIP更新StudioToo工具,而不必重新编写Python: 31 | 32 | ```sh 33 | python -m pip install --upgrade setuptools 34 | ``` 35 | 36 | 类似地,PIP可以用于通过以下方式来升级自己: 37 | 38 | ```sh 39 | python -m pip install --upgrade pip 40 | ``` 41 | 42 | ### 注`pip install --user` 43 | 44 | 正常人`pip install --user`为已酿Python禁用.这是因为ditutul中的一个bug,因为自制程序写了一个`distutils.cfg`设置包`prefix`. 45 | 46 | 一个可能的解决方案(将可执行脚本放入`~/Library/Python/./bin`是: 47 | 48 | ```sh 49 | python -m pip install --user --install-option="--prefix=" 50 | ``` 51 | 52 | ## `site-packages`以及`PYTHONPATH` 53 | 54 | 这个`site-packages`是包含Python模块的目录(特别是由其他公式安装的绑定).自制在这里创造: 55 | 56 | ```sh 57 | $(brew --prefix)/lib/pythonX.Y/site-packages 58 | ``` 59 | 60 | 所以,对于python 3 .yz,你会发现它在`/usr/local/lib/python3.y/site-packages`. 61 | 62 | Python 3 .y也搜索模块: 63 | 64 | - `/Library/Python/3.y/site-packages` 65 | - `~/Library/Python/3.y/lib/python/site-packages` 66 | 67 | 自酿啤酒`site-packages`如果(1)安装了Python绑定的任何自制程序公式,或者(2)`brew install python`. 68 | 69 | ### 为什么在这里? 70 | 71 | 这个位置的推理是在Python的(次要)升级或重新安装之间保存您的模块.此外,自制软件有严格的政策,从来不在外面写东西.`brew --prefix`所以我们不会对你的系统进行垃圾邮件. 72 | 73 | ## 自制程序提供Python绑定 74 | 75 | 一些公式提供Python绑定.有时一`--with-python`或`--with-python@2`选项必须传递给`brew install`为了构建Python绑定.(检查)`brew options `) 76 | 77 | **警告!**Python可能崩溃(参见[常见问题](Common-Issues.md)如果你`import `从一个酿造的蟒蛇,如果你跑`brew install `反对系统Python.如果您决定切换到酝酿的Python,则用Python绑定重新安装所有公式(例如).`pyside`,`wxwidgets`,`pygtk`,`pygobject`,`opencv`,`vtk`和`boost-python`) 78 | 79 | ## 非酿造Python绑定策略 80 | 81 | 这些应该通过`pip install `. 为了发现,你可以使用`pip search`或[HTTPS://PyPI.Python .Org/PyPI](https://pypi.python.org/pypi). (**注:**系统Python不提供`pip`. 跟随[PIP文档](https://pip.readthedocs.io/en/stable/installing/#install-pip)如果你愿意的话,可以为你的系统Python安装它. 82 | 83 | ## 酿Python模块 84 | 85 | 对于酝酿的Python,安装了`pip`或`python setup.py install`将安装到`$(brew --prefix)/lib/pythonX.Y/site-packages`目录(上文解释).可执行的Python脚本将在`$(brew --prefix)/bin`. 86 | 87 | 系统Python可能不知道要设置哪些编译器标志,以便为安装在Homebrew中的软件构建绑定,因此可能需要运行: 88 | 89 | ```sh 90 | CFLAGS=-I$(brew --prefix)/include LDFLAGS=-L$(brew --prefix)/lib pip install 91 | ``` 92 | 93 | ## 虚拟现实 94 | 95 | **警告:**当你`brew install`提供Python绑定的公式,您应该**不处于活跃的虚拟环境中**. 96 | 97 | 激活虚拟现实*之后*你在新的橱窗里酿造或酿造.HybBurw仍然将Python模块安装到自制程序中`site-packages`和*不*进入虚拟环境的站点包. 98 | 99 | VielalEnV有一个`--system-site-packages`切换到允许"全局"(即HOBBURW)`site-packages`可以从ValueLeV内部访问. 100 | 101 | ## 为什么HyBurw的Python被安装为依赖项? 102 | 103 | 声明无条件依赖的公式`"python"`或`"python@2"`公式被装入自制软件的Python 3 .x或2.7.x,并要求它被安装. 104 | -------------------------------------------------------------------------------- /src/Querying-Brew.md: -------------------------------------------------------------------------------- 1 | # Querying `brew` 2 | 3 | _In this document we will be using [jq](https://stedolan.github.io/jq/) to parse JSON, available from Homebrew using `brew install jq`._ 4 | 5 | ## Overview 6 | 7 | `brew` provides commands for getting common types of information out of the system. `brew list` shows installed formulae. `brew deps foo` shows the dependencies that `foo` needs. 8 | 9 | Additional commands, including external commands, can of course be written to provide more detailed information. There are a couple of disadvantages here. First, it means writing Ruby against a possibly changing Homebrew codebase. There will be more code to touch during refactors, and Homebrew can't guarantee that external commands will continue to work. Second, it means designing the commands themselves, specifying input parameters and output formats. 10 | 11 | To enable users to do rich queries without the problems above, Homebrew provides the `brew info` command. 12 | 13 | ## `brew info --json` 14 | 15 | `brew info` outputs JSON-formatted information about formulae. This JSON can then be parsed using your tools of choice. 16 | 17 | From the manpage: 18 | 19 | * `info --json= (--all|--installed|)`: 20 | Print a JSON representation of ``. Currently the only accepted value 21 | for `` is `v1`. 22 | 23 | Pass `--all` to get information on all formulae, or `--installed` to get 24 | information on all installed formulae. 25 | 26 | The current schema version is `v1`. Note that fields may be added to the schema as needed without incrementing the schema. Any significant breaking changes will cause a change to the schema version. 27 | 28 | The schema itself is not currently documented outside of the code that generates it: [Formula#to_hash](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/formula.rb) 29 | 30 | ## Examples 31 | 32 | _The top-level element of the JSON output is always an array, so the `map` operator is used to act on the data._ 33 | 34 | ### Pretty-print a single formula's info 35 | 36 | ```sh 37 | brew info --json=v1 tig | jq . 38 | ``` 39 | 40 | ### Installed formulae 41 | 42 | To show full JSON information about all installed formulae: 43 | 44 | ```sh 45 | brew info --json=v1 --all | jq "map(select(.installed != []))" 46 | ``` 47 | 48 | You'll note that processing all formulae can be slow; it's quicker to let `brew` do this: 49 | 50 | ```sh 51 | brew info --json=v1 --installed 52 | ``` 53 | 54 | ### Linked keg-only formulae 55 | 56 | Some formulae are marked as "keg-only", meaning that installed files are not linked to the shared `bin`, `lib`, etc. directories, as doing so can cause conflicts. Such formulae can be forced to link to the shared directories, but doing so is not recommended (and will cause `brew doctor` to complain.) 57 | 58 | To find the names of linked keg-only formulae: 59 | 60 | ```sh 61 | brew info --json=v1 --installed | jq "map(select(.keg_only == true and .linked_keg != null) | .name)" 62 | ``` 63 | 64 | ### Unlinked normal formulae 65 | 66 | To find the names of normal (not keg-only) formulae that are installed, but not linked to the shared directories: 67 | 68 | ```sh 69 | brew info --json=v1 --installed | jq "map(select(.keg_only == false and .linked_keg == null) | .name)" 70 | ``` 71 | 72 | ## formulae.brew.sh 73 | 74 | formulae.brew.sh has a [documented JSON API](https://formulae.brew.sh/docs/api/) which provides access to the `brew info --json=v1` output without needing access to Homebrew. 75 | 76 | ## Concluding remarks 77 | 78 | Using the JSON output, queries can be made against Homebrew with less risk of being broken due to Homebrew code changes, and without needing to understand Homebrew's Ruby internals. 79 | 80 | If the JSON output does not provide some information that it ought to, please submit a request, preferably with a patch to add the desired information. 81 | -------------------------------------------------------------------------------- /src/Taps.md: -------------------------------------------------------------------------------- 1 | # Taps (third-party repositories) 2 | 3 | `brew tap` adds more repositories to the list of formulae that `brew` tracks, updates, 4 | and installs from. By default, `tap` assumes that the repositories come from GitHub, 5 | but the command isn't limited to any one location. 6 | 7 | ## The command (`brew tap`) 8 | 9 | * `brew tap` without arguments lists the currently tapped repositories. For 10 | example: 11 | 12 | ```sh 13 | $ brew tap 14 | homebrew/core 15 | mistydemeo/tigerbrew 16 | dunn/emacs 17 | ``` 18 | 19 | * `brew tap ` makes a shallow clone of the repository at 20 | https://github.com/user/repo. After that, `brew` will be able to work on 21 | those formulae as if they were in Homebrew's canonical repository. You can 22 | install and uninstall them with `brew [un]install`, and the formulae are 23 | automatically updated when you run `brew update`. (See below for details 24 | about how `brew tap` handles the names of repositories.) 25 | 26 | * `brew tap ` makes a shallow clone of the repository at URL. 27 | Unlike the one-argument version, URL is not assumed to be GitHub, and it 28 | doesn't have to be HTTP. Any location and any protocol that Git can handle is 29 | fine. 30 | 31 | * Add `--full` to either the one- or two-argument invocations above, and Git 32 | will make a complete clone rather than a shallow one. Full is the default for 33 | Homebrew developers. 34 | 35 | * `brew tap --repair` migrates tapped formulae from a symlink-based to 36 | directory-based structure. (This should only need to be run once.) 37 | 38 | * `brew untap user/repo [user/repo user/repo ...]` removes the given taps. The 39 | repositories are deleted and `brew` will no longer be aware of their formulae. 40 | `brew untap` can handle multiple removals at once. 41 | 42 | ## Repository naming conventions and assumptions 43 | 44 | * On GitHub, your repository must be named `homebrew-something` in order to use 45 | the one-argument form of `brew tap`. The prefix 'homebrew-' is not optional. 46 | (The two-argument form doesn't have this limitation, but it forces you to 47 | give the full URL explicitly.) 48 | 49 | * When you use `brew tap` on the command line, however, you can leave out the 50 | 'homebrew-' prefix in commands. 51 | 52 | That is, `brew tap username/foobar` can be used as a shortcut for the long 53 | version: `brew tap username/homebrew-foobar`. `brew` will automatically add 54 | back the 'homebrew-' prefix whenever it's necessary. 55 | 56 | ## Formula duplicate names 57 | 58 | If your tap contains a formula that is also present in 59 | [`homebrew/core`](https://github.com/Homebrew/homebrew-core), that's fine, 60 | but it means that you must install it explicitly by default. 61 | 62 | If you would like to prioritise a tap over `homebrew/core`, you can use 63 | `brew tap-pin username/repo` to pin the tap, 64 | and use `brew tap-unpin username/repo` to revert the pin. 65 | 66 | Whenever a `brew install foo` command is issued, `brew` will find which formula 67 | to use by searching in the following order: 68 | 69 | * pinned taps 70 | * core formulae 71 | * other taps 72 | 73 | If you need a formula to be installed from a particular tap, you can use fully 74 | qualified names to refer to them. 75 | 76 | For example, you can create a tap for an alternative `vim` formula. Without 77 | pinning it, the behaviour will be 78 | 79 | ```sh 80 | brew install vim # installs from homebrew/core 81 | brew install username/repo/vim # installs from your custom repo 82 | ``` 83 | 84 | However if you pin the tap with `brew tap-pin username/repo`, you will need to 85 | use `homebrew/core` to refer to the core formula. 86 | 87 | ```sh 88 | brew install vim # installs from your custom repo 89 | brew install homebrew/core/vim # installs from homebrew/core 90 | ``` 91 | 92 | Do note that pinned taps are prioritized only when the formula name is directly 93 | given by you, i.e. it will not influence formulae automatically installed as 94 | dependencies. 95 | -------------------------------------------------------------------------------- /src/Acceptable-Formulae.md: -------------------------------------------------------------------------------- 1 | # Acceptable Formulae 2 | 3 | Some formulae should not go in 4 | [homebrew/core](https://github.com/Homebrew/homebrew-core). But there are 5 | additional [Interesting Taps and Forks](Interesting-Taps-and-Forks.md) and anyone can start their 6 | own! 7 | 8 | ### Dupes in `homebrew/core` 9 | We now accept stuff that comes with macOS as long as it uses `keg_only :provided_by_macos` to be keg-only by default. 10 | 11 | ### Versioned formulae in `homebrew/core` 12 | We now accept versioned formulae as long as they [meet the requirements](Versions.md). 13 | 14 | ### We don’t like tools that upgrade themselves 15 | Software that can upgrade itself does not integrate well with Homebrew's own 16 | upgrade functionality. The self-update functionality should be disabled (if possible without complicating the formula). 17 | 18 | ### We don’t like install-scripts that download unversioned things 19 | We don't like install scripts that are pulling from the `master` branch of Git repositories or unversioned, unchecksummed tarballs. These should use `resource` blocks with specific revisions or checksummed tarballs instead. Note that we now allow tools like `cargo`, `gem` and `pip` to download specifically versioned libraries during installation. 20 | 21 | ### We don’t like binary formulae 22 | Our policy is that formulae in the core tap 23 | ([homebrew/core](https://github.com/Homebrew/homebrew-core)) must be open-source 24 | and either built from source or produce cross-platform binaries (e.g. Java, Mono). 25 | Binary-only formulae should go to 26 | [Homebrew Cask](https://github.com/Homebrew/homebrew-cask). 27 | 28 | ### Stable versions 29 | Formulae in the core repository must have a stable version tagged by 30 | the upstream project. Tarballs are preferred to Git checkouts, and 31 | tarballs should include the version in the filename whenever possible. 32 | 33 | We don’t accept software without a tagged version because they regularly break 34 | due to upstream changes and we can’t provide [bottles](Bottles.md) for them. 35 | 36 | ### Niche (or self-submitted) stuff 37 | The software in question must: 38 | 39 | * be maintained (i.e. the last release wasn't ages ago, it works without patching on all supported macOS releases and has no outstanding, unpatched security vulnerabilities) 40 | * be known 41 | * be stable (e.g. not declared "unstable" or "beta" by upstream) 42 | * be used 43 | * have a homepage 44 | 45 | We will reject formulae that seem too obscure, partly because they won’t 46 | get maintained and partly because we have to draw the line somewhere. 47 | 48 | We frown on authors submitting their own work unless it is very popular. 49 | 50 | Don’t forget Homebrew is all Git underneath! 51 | [Maintain your own tap](How-to-Create-and-Maintain-a-Tap.md) if you have to! 52 | 53 | There may be exceptions to these rules in the main repository; we may 54 | include things that don't meet these criteria or reject things that do. 55 | Please trust that we need to use our discretion based on our experience 56 | running a package manager. 57 | 58 | ### Stuff that builds an `.app` 59 | Don’t make your formula build an `.app` (native macOS Application); we 60 | don’t want those things in Homebrew. Encourage upstream projects to build and support a `.app` that can be distributed by [Homebrew Cask](https://github.com/Homebrew/homebrew-cask) (and used without it, too). 61 | 62 | ### Stuff that builds a GUI by default (but doesn't have to) 63 | Make it build a command-line tool or a library by default and, if the GUI is useful and would be widely used, add an option to build the GUI. Don't offer an option for multiple GUI backends e.g. X11 is a bad user experience for GUIs on macOS. 64 | 65 | ### Stuff that doesn't build with the latest, stable Xcode's Clang 66 | Clang is the default C/C++ compiler on macOS (and has been for a long time). Software that doesn't build with it hasn't been adequately ported to macOS. 67 | 68 | ### Stuff that requires heavy manual pre/post-install intervention 69 | We're a package manager so we want to do things like resolve dependencies and setup applications for our users. If things require too much manual intervention then they aren't useful in a package manager. 70 | 71 | ### Sometimes there are exceptions 72 | Even if all criteria are met we may not accept the formula. 73 | Documentation tends to lag behind current decision-making. Although some 74 | rejections may seem arbitrary or strange they are based on years of 75 | experience making Homebrew work acceptably for our users. 76 | -------------------------------------------------------------------------------- /src/New-Maintainer-Checklist.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 新维护人员清单 3 | 4 | **这是现有维护人员用来邀请新的维护者的指南.你可能会发现它很有趣,但这里没有什么用户需要知道的.** 5 | 6 | 有人长期为Homebrew做出高质量贡献,并且显示出自己能够做出比公式更新稍微高级一点的贡献?让我们邀请他们成为维护者吧! 7 | 8 | 首先,向他们发送邀请邮件: 9 | 10 | ``` 11 | The Homebrew team and I really appreciate your help on issues, pull requests and 12 | your contributions to Homebrew. 13 | 14 | We would like to invite you to have commit access and be a Homebrew maintainer. 15 | If you agree to be a maintainer, you should spend a significant proportion of 16 | the time you are working on Homebrew fixing user-reported issues, resolving any 17 | issues that arise from your code in a timely fashion and reviewing user 18 | contributions. You should also be making contributions to Homebrew every month 19 | unless you are ill or on vacation (and please let another maintainer know if 20 | that's the case so we're aware you won't be able to help while you are out). 21 | 22 | You will need to watch Homebrew/brew and/or Homebrew/homebrew-core. Let us know 23 | which (or both) so we can grant you commit access appropriately. 24 | 25 | If you're no longer able to perform all of these tasks, please continue to 26 | contribute to Homebrew, but we will ask you to step down as a maintainer. 27 | 28 | A few requests: 29 | 30 | - please make pull requests on any changes to Homebrew/brew code or any 31 | non-trivial (e.g. not a test or audit improvement or version bump) changes 32 | to formulae code and don't merge them unless you get at least one approval 33 | and passing tests. 34 | - use `brew pull` for formulae changes that require new bottles or change 35 | multiple formulae and let it auto-close issues wherever possible (it may 36 | take ~5m). When this isn't necessary use GitHub's "Merge pull request" 37 | button in "create a merge commit" mode for Homebrew/brew or "squash and 38 | merge" for a single formulae change. If in doubt, check with e.g. GitX that 39 | you've not accidentally added merge commits 40 | - still create your branches on your fork rather than in the main repository. 41 | Note GitHub's UI will create edits and reverts on the main repository if you 42 | make edits or click revert on the Homebrew/brew repository rather than your 43 | own fork. 44 | - if still in doubt please ask for help and we'll help you out 45 | - please read: 46 | - https://docs.brew.sh/Brew-Test-Bot-For-Core-Contributors 47 | - https://docs.brew.sh/Maintainer-Guidelines 48 | - anything else you haven't read on https://docs.brew.sh 49 | 50 | How does that sound? 51 | 52 | Thanks for all your work so far! 53 | ``` 54 | 55 | 如果他们接受,遵循几个步骤让他们成立: 56 | 57 | - 邀请他们到[**@自制/维护者**团队](https://github.com/orgs/Homebrew/teams/maintainers)(或任何相关)[子小组](https://github.com/orgs/Homebrew/teams/maintainers/teams)为他们提供对相关存储库的访问权限(但不要让它们成为所有者).他们将需要启用[GITHUB双因素认证](https://help.github.com/articles/about-two-factor-authentication/). 58 | - 请他们签到[双托盘](https://bintray.com)使用他们的GITHUB帐户,他们应该自动同步到[宾托的家庭酿造组织](https://bintray.com/homebrew/organization/edit/members)作为会员,他们可以发布新的瓶子 59 | - 将它们添加到[詹金斯的GITHUB授权设置管理用户名](https://jenkins.brew.sh/configureSecurity/)因此,他们可以调整设置和重新启动作业. 60 | - 将它们添加到[詹金斯的GITHUB拉请求建设者管理列表](https://jenkins.brew.sh/configure)使能`@BrewTestBot test this please`为他们 61 | - 邀请他们到[`homebrew-maintainers`私人维护者邮寄名单](https://lists.sfconservancy.org/mailman/admin/homebrew-maintainers/members/add) 62 | - 邀请他们到[`machomebrew`私人维护者懈怠](https://machomebrew.slack.com/admin/invites)(并确保他们阅读了[通信指南](Maintainer-Guidelines.md#communication)) 63 | - 要求他们禁用SMS作为2FA设备,或者退回到GitHub帐户,支持使用其他认证方法之一. 64 | - 要求他们定期复习删除不必要的东西[GITHUB个人访问令牌](https://github.com/settings/tokens) 65 | - 将它们添加到[自制/酿造自述](https://github.com/Homebrew/brew/edit/master/README.md) 66 | 67 | 如果他们对系统管理工作感兴趣: 68 | 69 | - 邀请他们到[`homebrew-ops`私人操作邮件列表](https://lists.sfconservancy.org/mailman/admin/homebrew-ops/members/add) 70 | - 邀请他们到[`homebrew`私人密码](https://homebrew.1password.com/people) 71 | 72 | 如果他们想要消耗原始匿名聚合分析数据(而不是使用)`brew formula-analytics`): 73 | 74 | - 邀请他们[谷歌分析](https://analytics.google.com/analytics/web/?authuser=1#management/Settings/a76679469w115400090p120682403/%3Fm.page%3DAccountUsers/) 75 | 76 | 一旦他们成为积极的维护者至少一年,并在一个以上的自制组织存储库(或一个存储库,并帮助系统管理工作)上进行了一些活动: 77 | 78 | - 自酿啤酒[自由软件管理机构](https://sfconservancy.org)项目领导委员会可以就是否向维持者提供建议而加入委员会进行表决.如果他们接受了,把他们的名字、电子邮件和雇主发到HealBurW@ sFravaChan.Org,制作它们.[自酿GITHUB组织的所有者](https://github.com/orgs/Homebrew/people)并将它们添加到[自制/酿造自述](https://github.com/Homebrew/brew/edit/master/README.md). 79 | 80 | 如果有问题,请他们作为维护者下台,撤销他们对上述所有的访问. 81 | 82 | 现在坐下来,放松,让新的维护者处理更多的我们的贡献. 83 | -------------------------------------------------------------------------------- /src/Common-Issues.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 常见问题 3 | 4 | 这是一个常见的问题列表,已知的问题,以及它们的解决方案. 5 | 6 | ### `brew`抱怨"命令行工具"缺失 7 | 8 | 您需要安装(更新)XCODE命令行实用程序:运行`xcode-select --install`在终端.(在10.9之前的OS X中,"命令行工具"包可以从xCu码内部安装.`⌘,`会给你带来偏好.访问"下载"选项卡,点击"命令行工具"旁边的安装按钮. 9 | 10 | ### 红宝石:`bad interpreter: /usr/bin/ruby^M: no such file or directory` 11 | 12 | 你克隆了`git`并且您的Git配置被设置为使用Windows行结束.请参阅本页:[HTTPS://Help](https://help.github.com/articles/dealing-with-line-endings) 13 | 14 | ### 红宝石:`bad interpreter: /usr/bin/ruby` 15 | 16 | 你没有`/usr/bin/ruby`或者它不是可执行的.不建议让这种情况持续下去,你会惊讶多少`.app`S,工具和脚本希望你的Mac OS提供的文件和目录是*未修改的*因为安装了MACOS. 17 | 18 | ### `brew update`对未跟踪的工作树文件的抱怨 19 | 20 | 运行后`brew update`您将收到关于未跟踪文件或本地更改的Git错误警告,这些文件或本地更改将由签出或合并覆盖,然后是Homebrew安装内的文件列表. 21 | 22 | 这是由一个老臭虫引起的.`update`早已固定的代码.但是,bug的本质要求您做如下操作: 23 | 24 | ```sh 25 | cd $(brew --repository) 26 | git reset --hard FETCH_HEAD 27 | ``` 28 | 29 | 如果`brew doctor`仍然抱怨未提交的修改,也运行这个命令: 30 | 31 | ```sh 32 | cd $(brew --repository)/Library 33 | git clean -fd 34 | ``` 35 | 36 | ### 红宝石:`invalid multibyte escape: /^\037\213/` 37 | 38 | 你看到类似的错误: 39 | 40 | ``` 41 | Error: /usr/local/Library/Homebrew/download_strategy.rb:84: invalid multibyte escape: /^\037\213/ 42 | invalid multibyte escape: /^\037\235/ 43 | ``` 44 | 45 | 在过去,自酿假设`/usr/bin/ruby`是红宝石1.8.在OS X 10.9上,它现在是Ruby 2.这两个版本之间存在各种不兼容性,因此如果您在使用足够旧的Homebrew版本时升级到OS X 10.9,则会遇到错误. 46 | 47 | 在最近版本的自制程序中已经解决了不兼容性,而不是假设.`/usr/bin/ruby`它使用MACOS的Ruby框架内的可执行文件或被渲染的Ruby. 48 | 49 | 要从这种情况中恢复过来,请做以下几点: 50 | 51 | ```sh 52 | cd $(brew --prefix) 53 | git fetch origin 54 | git reset --hard FETCH_HEAD 55 | brew update 56 | ``` 57 | 58 | ### `launchctl`拒绝加载启动PLIST文件 59 | 60 | 当试图将一个PLIST文件加载到RunCHCTL中时,会收到类似的错误. 61 | 62 | ``` 63 | Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, [...] 64 | launch_msg(): Socket is not connected 65 | ``` 66 | 67 | 或 68 | 69 | ``` 70 | Could not open job overrides database at: /private/var/db/launchd.db/com.apple.launchd/overrides.plist: 13: Permission denied 71 | launch_msg(): Socket is not connected 72 | ``` 73 | 74 | 这可能是由于四个问题之一: 75 | 76 | 1. 您使用的是迭代.解决方案是使用Teleal.App与之交互.`launchctl`. 77 | 2. 您使用的是终端复用器,例如`tmux`或`screen`. 你应该和`launchctl`从一个单独的终端应用程序外壳. 78 | 3. 您正在尝试运行`launchctl`远程登录时.您应该启用远程机器上的屏幕共享,并使用在该机器上运行的Teleal.App发出命令. 79 | 4. 你是`su`作为一个不同的用户. 80 | 81 | ### `brew upgrade`错误出 82 | 83 | 跑步时`brew upgrade`你看到这样的事情: 84 | 85 | ``` 86 | $ brew upgrade 87 | Error: undefined method `include?' for nil:NilClass 88 | Please report this bug: 89 | https://docs.brew.sh/Troubleshooting 90 | /usr/local/Library/Homebrew/formula.rb:393:in `canonical_name' 91 | /usr/local/Library/Homebrew/formula.rb:425:in `factory' 92 | /usr/local/Library/Contributions/examples/brew-upgrade.rb:7 93 | /usr/local/Library/Contributions/examples/brew-upgrade.rb:7:in `map' 94 | /usr/local/Library/Contributions/examples/brew-upgrade.rb:7 95 | /usr/local/bin/brew:46:in `require' 96 | /usr/local/bin/brew:46:in `require?' 97 | /usr/local/bin/brew:79 98 | ``` 99 | 100 | 这是因为旧版本的升级命令由于某种原因而四处徘徊.修复: 101 | 102 | ```sh 103 | cd $(brew --repository)/Library/Contributions/examples 104 | git clean -n # if this doesn't list anything that you want to keep, then 105 | git clean -f # this will remove untracked files 106 | ``` 107 | 108 | ### Python:EasyStudio.PTH不能链接 109 | 110 | ``` 111 | Warning: Could not link . Unlinking... 112 | Error: The `brew link` step did not complete successfully 113 | The formula built, but is not symlinked into /usr/local 114 | You can try again using `brew link ' 115 | 116 | Possible conflicting files are: 117 | /usr/local/lib/python2.7/site-packages/site.py 118 | /usr/local/lib/python2.7/site-packages/easy-install.pth 119 | ==> Could not symlink file: /homebrew/Cellar///lib/python2.7/site-packages/site.py 120 | Target /usr/local/lib/python2.7/site-packages/site.py already exists. You may need to delete it. 121 | To force the link and overwrite all other conflicting files, do: 122 | brew link --overwrite formula_name 123 | 124 | To list all files that would be deleted: 125 | brew link --overwrite --dry-run formula_name 126 | ``` 127 | 128 | 不要听从建议,而是用`Language::Python.setup_install_args`在公式中描述的[公式作者的Python](Python-for-Formula-Authors.md). 129 | 130 | ### 升级MACOS 131 | 132 | 升级MACOS会导致如下错误: 133 | 134 | - `dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.54.dylib` 135 | - `configure: error: Cannot find libz` 136 | 137 | 在MACOS升级之后,可能需要重新安装XCODE命令行工具和`brew upgrade`所有安装公式: 138 | 139 | ```sh 140 | xcode-select --install 141 | brew upgrade 142 | ``` 143 | -------------------------------------------------------------------------------- /src/Node-for-Formula-Authors.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 公式作者节点 3 | 4 | 该文档说明了如何在基于节点模块的HOBBURW公式中成功地使用节点和NPM. 5 | 6 | ## 运行`npm install` 7 | 8 | HOBBURW提供了两种辅助方法`Language::Node`模块:`std_npm_install_args`和`local_npm_install_args`. 它们既为NPM设置了正确的环境,又为返回参数设置了`npm install`针对他们的具体使用情况.您的公式应该使用这些而不是调用`npm install`明确地.标准节点模块安装的语法是: 9 | 10 | ```ruby 11 | system "npm", "install", *Language::Node.std_npm_install_args(libexec) 12 | ``` 13 | 14 | 哪里`libexec`是目的前缀(通常是`libexec`变量). 15 | 16 | ## 下载网址 17 | 18 | 如果Node模块在npm注册表上也是可用的,那么与GitHub(或其他地方)托管的源tarball相比,我们更喜欢npm托管的发布tarballs.这些塔尔球的优点在于它们不包含来自`.npmignore`(如测试)导致较小的下载大小,并且已经完成了任何可能的传输步骤(例如,不需要将CoffeeScript文件编译为构建步骤). 19 | 20 | NPM注册表URL通常具有以下格式: 21 | 22 | ``` 23 | https://registry.npmjs.org//-/-.tgz 24 | ``` 25 | 26 | 或者你可以`curl`JSON在`https://registry.npmjs.org/`寻找价值`versions[].dist.tarball`正确的TabBar URL. 27 | 28 | ## 依赖关系 29 | 30 | 与最新节点版本兼容的节点模块应该声明依赖于`node`公式. 31 | 32 | ```ruby 33 | depends_on "node" 34 | ``` 35 | 36 | 如果您的公式需要用较旧的节点版本执行,则应该使用版本化的节点公式之一(例如`node@6`) 37 | 38 | ### 本地插件的特殊要求 39 | 40 | 如果Node模块是本机addon或在其依赖树中的某个地方有本机addon,则必须声明额外的依赖项.由于本机插件的编译导致调用`node-gyp`我们需要额外的构建时间依赖性.`"python"`(因为GYP依赖于Python 2.7). 41 | 42 | ```ruby 43 | depends_on "python" => :build 44 | ``` 45 | 46 | 还要注意,这样的公式只会与原来编译的同一个节点的主要版本兼容.这意味着我们需要用一个节点本地ADDN来修改每个公式,每个版本的BUMP都是`node`公式.让我们不要忽视你的公式节点上的主要版本的凹凸,写一个有意义的测试,在这种情况下失败(与ABI不兼容版本调用节点). 47 | 48 | ## 安装 49 | 50 | 节点模块应该安装到`libexec`. 这防止节点模块污染全局.`node_modules`这是很重要的,所以NPM不尝试管理自制安装的节点模块. 51 | 52 | 在下面,我们使用公式来区分两种类型的节点模块: 53 | 54 | - 与NPM的全局模块格式兼容的标准节点模块的公式[`std_npm_install_args`](#installing-global-style-modules-with-std_npm_install_args-to-libexec)(像[`azure-cli`](https://github.com/Homebrew/homebrew-core/blob/0f3b27d252b8112c744e0460d871cfe1def6b993/Formula/azure-cli.rb)或[`webpack`](https://github.com/Homebrew/homebrew-core/blob/6282879973d569962e63da7c81ac4623e1a8336b/Formula/webpack.rb)) 55 | - 公式在哪里`npm install`调用不是唯一需要的安装步骤(例如需要编译非JavaScript源)也必须使用.[`local_npm_install_args`](#installing-module-dependencies-locally-with-local_npm_install_args)(像[`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/4bb491b7b246830aed57b97348a17e9401374978/Formula/elixirscript.rb) 56 | 57 | 这两种方法的共同特点是,他们使用NPM在自制程序设置正确的环境和返回的参数调用`npm install`针对他们的具体使用情况.这包括用NPM缓存修复一个重要的边缘情况(由HouBurw重定向引起的)`HOME`在构建和测试过程中,通过使用我们自己的习惯`npm_cache`里面`HOMEBREW_CACHE`,否则会造成很长的构建时间和较高的磁盘空间使用率. 58 | 59 | 要使用它们,必须在公式文件的开头要求节点语言模块: 60 | 61 | ```ruby 62 | require "language/node" 63 | ``` 64 | 65 | ### 安装全局样式模块`std_npm_install_args`到`libexec` 66 | 67 | 在你的公式中`install`方法,简单`cd`在必要时使用节点模块的顶层,然后使用`system`调用`npm install`具有`Language::Node.std_npm_install_args`像: 68 | 69 | ```ruby 70 | system "npm", "install", *Language::Node.std_npm_install_args(libexec) 71 | ``` 72 | 73 | 这将以NPM的全局模块样式将节点模块安装到自定义前缀中.`libexec`. 所有模块的可执行文件将由NPM自动解决.`libexec/bin`对你来说,这并没有融入到自制软件的前缀中.我们需要确保安装这些设备.要做到这一点,我们需要将所有可执行文件都链接到`bin`用: 74 | 75 | ```ruby 76 | bin.install_symlink Dir["#{libexec}/bin/*"] 77 | ``` 78 | 79 | **注:**因为需要解决的问题`npm@5`打电话`npm pack`目前我们不支持安装模块(来自非npm注册表tarballs),这需要预发布步骤(例如,用于传输源).见[自制/酿造2820](https://github.com/Homebrew/brew/pull/2820)欲了解更多信息. 80 | 81 | ### 在本地安装模块依赖项`local_npm_install_args` 82 | 83 | 在你的公式中`install`方法,做任何安装步骤之前需要做的`npm install`步骤然后`cd`到所包含节点模块的顶层.然后,使用`system`具有`Language::Node.local_npm_install_args`调用`npm install`像: 84 | 85 | ```ruby 86 | system "npm", "install", *Language::Node.local_npm_install_args 87 | ``` 88 | 89 | 这将将所有节点模块依赖项安装到本地生成路径.现在您可以继续您的构建步骤,并将安装安装到自制程序中.`prefix`你自己,跟着[通用自制公式指令](Formula-Cookbook.md). 90 | 91 | ## 例子 92 | 93 | 安装基于标准节点模块的公式将是这样的: 94 | 95 | ```ruby 96 | require "language/node" 97 | 98 | class Foo < Formula 99 | desc "..." 100 | homepage "..." 101 | url "https://registry.npmjs.org/foo/-/foo-1.4.2.tgz" 102 | sha256 "..." 103 | 104 | depends_on "node" 105 | # uncomment if there is a native addon inside the dependency tree 106 | # depends_on "python" => :build 107 | 108 | def install 109 | system "npm", "install", *Language::Node.std_npm_install_args(libexec) 110 | bin.install_symlink Dir["#{libexec}/bin/*"] 111 | end 112 | 113 | test do 114 | # add a meaningful test here 115 | end 116 | end 117 | ``` 118 | 119 | 例如使用`local_npm_install_args`方法查看[`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/ec1e40d37e81af63122a354f0101c377f6a4e66d/Formula/elixirscript.rb)或[`kibana`](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb)公式. 120 | 121 | ## 工装 122 | 123 | 你可以使用[自制的NPM NOOB](https://github.com/zmwangx/homebrew-npm-noob)自动生成一个公式,如上面一个NPM包的例子. 124 | -------------------------------------------------------------------------------- /src/Versions.md: -------------------------------------------------------------------------------- 1 | # Versions 2 | 3 | Now that [homebrew/versions](https://github.com/homebrew/homebrew-versions) has been deprecated, [homebrew/core](https://github.com/homebrew/homebrew-core) supports multiple versions of formulae with a new naming format. 4 | 5 | In [homebrew/versions](https://github.com/homebrew/homebrew-versions) the formula for GCC 6 was named `gcc6.rb` and began with `class Gcc6 < Formula`. In [homebrew/core](https://github.com/homebrew/homebrew-core) this same formula is named `gcc@6.rb` and begins with `class GccAT6 < Formula`. 6 | 7 | ## Acceptable versioned formulae 8 | Versioned formulae we include in [homebrew/core](https://github.com/homebrew/homebrew-core) must meet the following standards: 9 | 10 | * Versioned software should build on all Homebrew's supported versions of macOS. 11 | * Versioned formulae should differ in major/minor (not patch) versions from the current stable release. This is because patch versions indicate bug or security updates and we want to ensure you apply security updates. 12 | * Upstream should have a release branch for the versioned formulae version and still make security updates for that version, when necessary. For example, [PHP 5.5 was not a supported version but PHP 7.2 was](http://php.net/supported-versions.php) in January 2018 13 | * Formulae that depend on versioned formulae must not depend on the same formulae at two different versions twice in their recursive dependencies. For example, if you depend on `openssl@1.0` and `foo`, and `foo` depends on `openssl` then you must instead use `openssl`. 14 | * Versioned formulae should only be linkable at the same time as their non-versioned counterpart if the upstream project provides support for it, e.g. using suffixed binaries. If this is not possible, use `keg_only :versioned_formula` to allow users to have multiple versions installed at once. 15 | * A `keg_only :versioned_formula` should not `post_install` anything in the `HOMEBREW_PREFIX` that conflicts with or duplicates the non-versioned counterpart (or other versioned formulae). For example, a `node@6` formula should not install its `npm` into `HOMEBREW_PREFIX` like the `node` formula does. 16 | * Versioned formulae submitted should be expected to be used by a large number of people. If this ceases to be the case: they will be removed. We will aim not to remove those in the [top 3,000 `install_on_request` formulae](https://brew.sh/analytics/install-on-request/). 17 | * Versioned formulae should not have `resource`s that require security updates. For example, a `node@6` formula should not have an `npm` resource but instead rely on the `npm` provided by the upstream tarball. 18 | * Versioned formulae should be as similar as possible and sensible to the unversioned formulae. Creating or updating a versioned formula should be a chance to ask questions of the unversioned formula e.g. can some unused or useless options be removed or made default? 19 | * No more than five versions of a formula (including the non-versioned one) will be supported at any given time, regardless of usage. When removing formulae that violate this we will aim to do so based on usage and support status rather than age. 20 | 21 | Homebrew's versions are not intended to be used for any old versions you personally require for your project. You should create your own [tap](How-to-Create-and-Maintain-a-Tap.md) for formulae you or your organisation wish to control the versioning of or those that do not meet the above standards. Software that has regular API or ABI breaking releases still needs to meet all the above requirements; that a `brew upgrade` has broken something for you is not an argument for us to add and maintain a formula for you. 22 | 23 | If there is a formula that currently exists in the Homebrew/homebrew-core repository or has existed in the past (i.e. was migrated or deleted), you can recover it for your own use with the `brew extract` command. This will copy the desired version of the formula into a custom tap. For example, if your project depends on `automake` 1.12 instead of the most recent version, you can obtain the `automake` formula at version 1.12 by running `brew extract automake $YOUR_GITHUB_USER/$YOUR_TAP_REPOSITORY_NAME --version=1.12`. Formulae obtained this way may have use deprecated, disabled or removed Homebrew syntax (e.g. checksums may have `sha1` checksums instead of `sha256`); the `brew extract` command does not edit or update formulae to meet current standards and style requirements. 24 | 25 | We may temporarily add versioned formulae for our own needs that do not meet these standards in [homebrew/core](https://github.com/homebrew/homebrew-core). The presence of a versioned formula there does not imply it will be maintained indefinitely or that we are willing to accept any more versions that do not meet the requirements above. 26 | -------------------------------------------------------------------------------- /src/External-Commands.md: -------------------------------------------------------------------------------- 1 | # External Commands 2 | 3 | Homebrew, like Git, supports *external commands*. This lets you create new commands that can be run like: 4 | 5 | ```sh 6 | brew mycommand --option1 --option3 formula 7 | ``` 8 | 9 | without modifying Homebrew's internals. 10 | 11 | ## Command types 12 | External commands come in two flavours: Ruby commands and shell scripts. 13 | 14 | In both cases, the command file should be executable (`chmod +x`) and live somewhere in `PATH`. 15 | 16 | ### Ruby commands 17 | An external command `extcmd` implemented as a Ruby command should be named `brew-extcmd.rb`. The command is executed by doing a `require` on the full pathname. As the command is `require`d, it has full access to the Homebrew "environment", i.e. all global variables and modules that any internal command has access to. Be wary of using Homebrew internals; they may change at any time without warning. 18 | 19 | The command may `Kernel.exit` with a status code if it needs to; if it doesn't explicitly exit then Homebrew will return `0`. 20 | 21 | ### Shell scripts 22 | A shell script for a command named `extcmd` should be named `brew-extcmd`. This file will be run via `exec` with some Homebrew variables set as environment variables, and passed any additional command-line arguments. 23 | 24 | | Variable | Description | 25 | |------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 26 | | `HOMEBREW_CACHE` | Where Homebrew caches downloaded tarballs to, by default `~/Library/Caches/Homebrew`. | 27 | | `HOMEBREW_CELLAR` | The location of the Homebrew Cellar, where software is staged. This will be `HOMEBREW_PREFIX/Cellar` if that directory exists, or `HOMEBREW_REPOSITORY/Cellar` otherwise. | 28 | | `HOMEBREW_LIBRARY_PATH`| The directory containing Homebrew’s own application code. | 29 | | `HOMEBREW_PREFIX` | Where Homebrew installs software. This is always the grandparent directory of the `brew` executable, `/usr/local` by default. | 30 | | `HOMEBREW_REPOSITORY` | If installed from a Git clone, the repository directory (i.e. where Homebrew’s .git directory lives). | 31 | 32 | Note that the script itself can use any suitable shebang (`#!`) line, so an external “shell script” can be written for sh, bash, Ruby, or anything else. 33 | 34 | ## Providing `--help` 35 | 36 | All internal and external Homebrew commands can provide styled `--help` output by using lines starting with `#:` (a comment then `:` character in both Bash and Ruby) which are then output by `--help`. 37 | 38 | For example, see the [header of `brew services`](https://github.com/Homebrew/homebrew-services/blob/a5115e47b05e8d2a632ba7775599e698b240e5a2/cmd/brew-services.rb#L1-L31) which is output with `brew services --help`. 39 | 40 | ## Homebrew organisation external commands 41 | 42 | ### homebrew-livecheck 43 | Check if there is a new upstream version of a formula. 44 | See the [`README`](https://github.com/Homebrew/homebrew-livecheck/blob/master/README.md) for more info and usage. 45 | 46 | Install using: 47 | 48 | ```sh 49 | brew tap homebrew/livecheck 50 | ``` 51 | 52 | ### homebrew-command-not-found 53 | Ubuntu's `command-not-found equivalent` for Homebrew. 54 | See the [`README`](https://github.com/Homebrew/homebrew-command-not-found/blob/master/README.md) for more info and usage. 55 | 56 | Install using: 57 | 58 | ```sh 59 | brew tap homebrew/command-not-found 60 | ``` 61 | 62 | ### homebrew-aliases 63 | Allows you to alias your Homebrew commands. 64 | See the [`README`](https://github.com/Homebrew/homebrew-aliases/blob/master/README.md) for more info and usage. 65 | 66 | Install using: 67 | 68 | ```sh 69 | brew tap homebrew/aliases 70 | ``` 71 | 72 | ## Unofficial external commands 73 | These commands have been contributed by Homebrew users but are not included in the main Homebrew organisation, nor are they installed by the installer script. You can install them manually, as outlined above. 74 | 75 | Note they are largely untested, and as always, be careful about running untested code on your machine. 76 | 77 | ### brew-gem 78 | Install any `gem` package into a self-contained Homebrew Cellar location: 79 | 80 | Note this can also be installed with `brew install brew-gem`. 81 | -------------------------------------------------------------------------------- /src/Bottles.md: -------------------------------------------------------------------------------- 1 | # Bottles (binary packages) 2 | 3 | Bottles are produced by installing a formula with `brew install --build-bottle ` and then bottling it with `brew bottle `. This outputs the bottle DSL which should be inserted into the formula file. 4 | 5 | ## Usage 6 | If a bottle is available and usable it will be downloaded and poured automatically when you `brew install `. If you wish to disable this you can do so by specifying `--build-from-source`. 7 | 8 | Bottles will not be used if the user requests it (see above), if the formula requests it (with `pour_bottle?`), if any options are specified during installation (bottles are all compiled with default options), if the bottle is not up to date (e.g. lacking a checksum) or if the bottle's `cellar` is not `:any` nor equal to the current `HOMEBREW_CELLAR`. 9 | 10 | ## Creation 11 | Bottles are created using the [Brew Test Bot](Brew-Test-Bot.md). This happens mostly when people submit pull requests to Homebrew and the `bottle do` block is updated by maintainers when they `brew pull --bottle` the contents of a pull request. For the Homebrew organisations' taps they are uploaded to and downloaded from [Bintray](https://bintray.com/homebrew). 12 | 13 | By default, bottles will be built for the oldest CPU supported by the OS/architecture you're building for (Core 2 for 64-bit OSs). This ensures that bottles are compatible with all computers you might distribute them to. If you *really* want your bottles to be optimized for something else, you can pass the `--bottle-arch=` option to build for another architecture - for example, `brew install foo --bottle-arch=penryn`. Just remember that if you build for a newer architecture some of your users might get binaries they can't run and that would be sad! 14 | 15 | ## Format 16 | Bottles are simple gzipped tarballs of compiled binaries. Any metadata is stored in a formula's bottle DSL and in the bottle filename (i.e. macOS version, revision). 17 | 18 | ## Bottle DSL (Domain Specific Language) 19 | Bottles have a DSL to be used in formulae which is contained in the `bottle do ... end` block. 20 | 21 | A simple (and typical) example: 22 | 23 | ```ruby 24 | bottle do 25 | sha256 "4921af80137af9cc3d38fd17c9120da882448a090b0a8a3a19af3199b415bfca" => :sierra 26 | sha256 "c71db15326ee9196cd98602e38d0b7fb2b818cdd48eede4ee8eb827d809e09ba" => :el_capitan 27 | sha256 "85cc828a96735bdafcf29eb6291ca91bac846579bcef7308536e0c875d6c81d7" => :yosemite 28 | end 29 | ``` 30 | 31 | A full example: 32 | 33 | ```ruby 34 | bottle do 35 | root_url "https://example.com" 36 | prefix "/opt/homebrew" 37 | cellar "/opt/homebrew/Cellar" 38 | rebuild 4 39 | sha256 "4921af80137af9cc3d38fd17c9120da882448a090b0a8a3a19af3199b415bfca" => :sierra 40 | sha256 "c71db15326ee9196cd98602e38d0b7fb2b818cdd48eede4ee8eb827d809e09ba" => :el_capitan 41 | sha256 "85cc828a96735bdafcf29eb6291ca91bac846579bcef7308536e0c875d6c81d7" => :yosemite 42 | end 43 | ``` 44 | 45 | ### Root URL (`root_url`) 46 | Optionally contains the URL root used to calculate bottle URLs. 47 | By default this is omitted and the Homebrew default bottle URL root is used. This may be useful for taps which wish to provide bottles for their formulae or to cater for a non-default `HOMEBREW_CELLAR`. 48 | 49 | ### Cellar (`cellar`) 50 | Optionally contains the value of `HOMEBREW_CELLAR` in which the bottles were built. 51 | Most compiled software contains references to its compiled location so cannot be simply relocated anywhere on disk. If this value is `:any` or `:any_skip_relocation` this means that the bottle can be safely installed in any Cellar as it did not contain any references to its installation Cellar. This can be omitted if a bottle is compiled (as all default Homebrew ones are) for the default `HOMEBREW_CELLAR` of `/usr/local/Cellar`. 52 | 53 | ### Prefix (`prefix`) 54 | Optionally contains the value of `HOMEBREW_PREFIX` in which the bottles were built. 55 | See description of `cellar`. When `cellar` is `:any` or `:any_skip_relocation` the prefix should be omitted. 56 | 57 | ### Rebuild version (`rebuild`) 58 | Optionally contains the rebuild version of the bottle. 59 | Sometimes bottles may need be updated without bumping the version of the formula, e.g. a new patch was applied. In that case the rebuild will have a value of 1 or more. 60 | 61 | ### Checksum (`sha256`) 62 | Contains the SHA-256 hash of a bottle for a particular version of macOS. 63 | 64 | ## Formula DSL 65 | Additionally there is a method available in the formula DSL. 66 | 67 | ### Pour bottle (`pour_bottle?`) 68 | Optionally returns a boolean to decide whether a bottle should be used for this formula. 69 | For example a bottle may break if another formula has been compiled with non-default options, so this method could check for that case and return `false`. 70 | 71 | A full example: 72 | 73 | ```ruby 74 | pour_bottle? do 75 | reason "The bottle needs the Xcode CLT to be installed." 76 | satisfy { MacOS::CLT.installed? } 77 | end 78 | ``` 79 | -------------------------------------------------------------------------------- /src/Tips-N'-Tricks.md: -------------------------------------------------------------------------------- 1 | # Tips and Tricks 2 | 3 | ## Installing previous versions of formulae 4 | 5 | The supported method of installing specific versions of 6 | some formulae is to see if there is a versioned formula (e.g. `gcc@6`) available. If the version you’re looking for isn’t available, consider using `brew extract`. 7 | 8 | ### Installing directly from pull requests 9 | You can [browse pull requests](https://github.com/Homebrew/homebrew-core/pulls) 10 | and install through the direct link. For example, Python 3.3.0 from pull request [Homebrew/homebrew#15199](https://github.com/Homebrew/homebrew/pull/15199): 11 | 12 | ```sh 13 | brew install https://raw.github.com/dsr/homebrew/9b22d42f50fcbc5e52c764448b3ac002bc153bd7/Library/Formula/python3.rb 14 | ``` 15 | 16 | ## Quickly remove something from `/usr/local` 17 | 18 | ```sh 19 | brew unlink 20 | ``` 21 | 22 | This can be useful if a package can't build against the version of something you have linked into `/usr/local`. 23 | 24 | And of course, you can simply `brew link ` again afterwards! 25 | 26 | ## Activate a previously installed version of a formula 27 | 28 | ```sh 29 | brew info 30 | brew switch 31 | ``` 32 | 33 | Use `brew info ` to check what versions are installed but not currently activated, then `brew switch ` to activate the desired version. This can be useful if you would like to switch between versions of a formula. 34 | 35 | ## Install into Homebrew without formulae 36 | 37 | ```sh 38 | ./configure --prefix=/usr/local/Cellar/foo/1.2 && make && make install && brew link foo 39 | ``` 40 | 41 | ## Pre-downloading a file for a formula 42 | Sometimes it's faster to download a file via means other than those 43 | strategies that are available as part of Homebrew. For example, 44 | Erlang provides a torrent that'll let you download at 4–5× the normal 45 | HTTP method. 46 | 47 | Download the file and drop it in `~/Library/Caches/Homebrew`, but 48 | watch the file name. Homebrew downloads files as `-`. 49 | In the case of Erlang, this requires renaming the file from `otp_src_R13B03` to 50 | `erlang-R13B03`. 51 | 52 | `brew --cache -s erlang` will print the correct name of the cached 53 | download. This means instead of manually renaming a formula, you can 54 | run `mv the_tarball $(brew --cache -s )`. 55 | 56 | You can also pre-cache the download by using the command `brew fetch formula` which also displays the SHA-256 hash. This can be useful for updating formulae to new versions. 57 | 58 | ## Installing stuff without the Xcode CLT 59 | 60 | ```sh 61 | brew sh # or: eval $(brew --env) 62 | gem install ronn # or c-programs 63 | ``` 64 | 65 | This imports the `brew` environment into your existing shell; `gem` will pick up the environment variables and be able to build. As a bonus `brew`'s automatically determined optimization flags are set. 66 | 67 | ## Install only a formula's dependencies (not the formula) 68 | 69 | ```sh 70 | brew install --only-dependencies 71 | ``` 72 | 73 | ## Interactive Homebrew Shell 74 | 75 | ```sh 76 | $ brew irb 77 | 1.8.7 :001 > Formula.factory("ace").methods - Object.methods 78 | => [:install, :path, :homepage, :downloader, :stable, :bottle, :devel, :head, :active_spec, :buildpath, :ensure_specs_set, :url, :version, :specs, :mirrors, :installed?, :explicitly_requested?, :linked_keg, :installed_prefix, :prefix, :rack, :bin, :doc, :include, :info, :lib, :libexec, :man, :man1, :man2, :man3, :man4, :man5, :man6, :man7, :man8, :sbin, :share, :etc, :var, :plist_name, :plist_path, :download_strategy, :cached_download, :caveats, :options, :patches, :keg_only?, :fails_with?, :skip_clean?, :brew, :std_cmake_args, :deps, :external_deps, :recursive_deps, :system, :fetch, :verify_download_integrity, :fails_with_llvm, :fails_with_llvm?, :std_cmake_parameters, :mkdir, :mktemp] 79 | 1.8.7 :002 > 80 | ``` 81 | 82 | ## Hiding the beer mug emoji when finishing a build 83 | 84 | ```sh 85 | export HOMEBREW_NO_EMOJI=1 86 | ``` 87 | 88 | This sets the HOMEBREW_NO_EMOJI environment variable, causing Homebrew 89 | to hide all emoji. 90 | 91 | The beer emoji can also be replaced with other character(s): 92 | 93 | ```sh 94 | export HOMEBREW_INSTALL_BADGE="☕️ 🐸" 95 | ``` 96 | 97 | ## Editor plugins 98 | 99 | ### Sublime Text 100 | 101 | In Sublime Text 2/3, you can use Package Control to install 102 | [Homebrew-formula-syntax](https://github.com/samueljohn/Homebrew-formula-syntax), 103 | which adds highlighting for inline patches. 104 | 105 | ### Vim 106 | [brew.vim](https://github.com/xu-cheng/brew.vim) adds highlighting to 107 | inline patches in Vim. 108 | 109 | ### Emacs 110 | [homebrew-mode](https://github.com/dunn/homebrew-mode) provides syntax 111 | highlighting for inline patches as well as a number of helper functions 112 | for editing formula files. 113 | 114 | [pcmpl-homebrew](https://github.com/hiddenlotus/pcmpl-homebrew) provides completion 115 | for emacs shell-mode and eshell-mode. 116 | 117 | ### Atom 118 | [language-homebrew-formula](https://atom.io/packages/language-homebrew-formula) 119 | adds highlighting and diff support (with the 120 | [language-diff](https://atom.io/packages/language-diff) plugin). 121 | -------------------------------------------------------------------------------- /src/Maintainer-Guidelines.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 维护指南 3 | 4 | **本指南适用于维护人员.**这些特殊的人**写访问**HOBPROW的知识库,并帮助合并他人的贡献.你可能会发现这里写的东西很有趣,但绝对不是初学者的指导. 5 | 6 | 也许你在寻找[公式食谱](Formula-Cookbook.md)? 7 | 8 | 这份文件是当前的实践.如果你想改变或讨论以下问题:打开公关建议改变. 9 | 10 | ## 快速检查表 11 | 12 | 这才是真正重要的: 13 | 14 | - 确保名称似乎合理. 15 | - 添加别名. 16 | - 确保使用`keg_only :provided_by_macos`如果它已经配备了MaOS. 17 | - 确保它不是一个可以安装的库[宝石](https://en.wikipedia.org/wiki/RubyGems),[cpan](https://en.wikipedia.org/wiki/Cpan)或[匹普](https://pip.pypa.io/en/stable/). 18 | - 确保任何依赖性都是精确的和最小的.我们不需要支持软件的每一个可能的可选特征. 19 | - 使用不需要瓶子的GITHUB壁纸和合并工作流. 20 | - 使用`brew pull`否则,它会添加消息来自动关闭拉取请求和由BREW测试BOT构建的瓶子. 21 | - 感谢人们的贡献. 22 | 23 | 检查依赖关系很重要,因为它们可能永远存在.没有人真正检查他们是否有必要.使用`:optional`和`:recommended`酌情修饰语. 24 | 25 | 尽可能少的东西.默认情况下禁用X11功能.例如,我们构建WiReSARK,但不是默认的重GTK/QT-GUI. 26 | 27 | 自制软件是关于UNIX软件的.建立的东西`.app`应该是在自制啤酒桶里. 28 | 29 | ### 命名 30 | 31 | 名称是最严格的项目,因为避免以后的名称更改是可取的. 32 | 33 | 选择一个名称,这是项目最常见的名称.例如,我们最初选择`objective-caml`但是我们应该选择`ocaml`. 在谈论这个项目时,选择别人对对方说的话. 34 | 35 | 将其他名称作为别名添加到`Aliases`在龙头根中.确保主页上引用的名称是其中之一,因为它可能是不同的,有下划线和连字符等等. 36 | 37 | 我们现在接受版本化公式只要它们[符合要求](Versions.md). 38 | 39 | ### 合并、再基、樱桃采摘 40 | 41 | 合并应在`Homebrew/brew`用于保存历史记录和GPG提交签名的存储库,以及通过GitHub进行挤压/合并应该用于那些公式不需要瓶子或者更改不需要拉新瓶子的公式.否则,你应该使用`brew pull`(或)`rebase`/`cherry-pick`捐款). 42 | 43 | 不要`rebase`直到你最终`push`. 一次`master`被推,你不能`rebase`:**你现在是维护者了!** 44 | 45 | 樱桃采摘会改变提交的日期,这有点糟透了. 46 | 47 | 不要`merge`不干净的树枝所以如果有人还在学习`git`他们的分支充满了无稽之谈`rebase`压扁这些约定.我们的主要分支历史应该对其他人有用,而不是混淆. 48 | 49 | ### 测试 50 | 51 | 我们至少需要检查一下它是如何建立的.使用[酿造试验机器人](Brew-Test-Bot.md)为此. 52 | 53 | 如果可能的话,验证公式.如果你不能告诉(例如,如果它是一个图书馆)相信原来的贡献者,它为他们工作,所以很可能是好的.如果你不是这个工具的专家,你就不能真正判断公式是否正确安装了程序.在某个时候,一个专家会来,哭诉蓝色的谋杀,它不起作用,并修复它.这就是开源的工作原理.理想情况下,请求A`test do`块以测试功能是否始终可用. 54 | 55 | 如果公式使用存储库,那么`url`参数应该有标记或修订.`url`S有版本并且是稳定的(尚未实现!). 56 | 57 | ## 常见的"哥特斯" 58 | 59 | 1. [确保您已正确设置用户名和电子邮件地址](https://help.github.com/articles/setting-your-email-in-git/) 60 | 2. 如果你修改了樱桃采摘,就签下它们.[GITX DEV](https://github.com/rowanj/gitx)可以这样做,否则有一个命令行标志 61 | 3. 如果提交修复了错误,请使用"修复".γ104"关闭错误报告并链接到提交的语法" 62 | 63 | ### 复制品 64 | 65 | 我们现在接受MACOS附带的东西,只要它使用`keg_only :provided_by_macos`仅默认为桶. 66 | 67 | ### 添加注释 68 | 69 | 查阅问题单可能就足够了,但是要确保更改是清楚的,这样如果您来找他们,而不知道周围的问题,他们就会对您有意义.在其他项目上,我多次看到代码被删除,因为新的家伙不知道为什么会出现在那里.回归是吸吮. 70 | 71 | ### 不要让臃肿的分歧 72 | 73 | 修改樱桃拾取以移除只是空白中的更改的提交.他们是不可接受的,因为我们的历史是重要的.`git blame`应该有用的. 74 | 75 | 如果行本身有某种修改,而不是其中的空格,则允许(对Ruby标准等)进行空格更正(事实上这是一个很好的机会).但是要小心对内嵌修补程序进行更改,以确保它们仍然适用. 76 | 77 | ### 添加或更新公式 78 | 79 | 任何一个维护者都有必要批准和合并一个通过CI的新的或更新的公式的添加.但是,如果公式添加或更新证明有争议,则添加该公式的维护者将预期回答请求并修复将来出现的问题. 80 | 81 | ### 去除公式 82 | 83 | 公式: 84 | 85 | - 在默认的自制程序前缀中至少有2/3个支持的MaOS版本 86 | - 不需要上游拒绝的补丁工作 87 | - 没有已知的安全漏洞或CVS的版本,我们封装 88 | - 显示在我们的分析中仍然由用户安装`BuildError`\<25% 89 | 90 | 不应该从家庭酿造中移除.这个规则的例外是[版本公式](Versions.md)对于给定的公式,使用的标准更高,版本的数量也最大. 91 | 92 | ### 关闭问题/ PRS 93 | 94 | 维护人员(包括主要维护人员)不应关闭由其他维护人员打开的问题或拉出请求(注意,在此情况下合并不被视为关闭),除非它们已经过时(即,28天内没有看到更新),在这种情况下,它们可以被任何维护人员关闭.任何维护者被鼓励重新打开一个关闭的问题,当他们希望在这个问题上做额外的工作时. 95 | 96 | 任何维护者可以合并他们仔细审查过的任何PR,并通过任何其他维护者已经打开的CI.如果您不希望其他维护者合并您的PRS:请使用`do not merge`标签,以表明,直到您准备合并它自己. 97 | 98 | ## 回复PRS 99 | 100 | 任何维护者可以在用户提交的问题或CI失败后,恢复由另一个维护者创建的PR.创建原始PR的维护者应该得到不少于一个小时的时间自己修复问题或者如果愿意的话决定恢复PR本身. 101 | 102 | ## 通信 103 | 104 | 维护者有多种方式互相交流: 105 | 106 | - GITHUB的HOBPROW公共仓库 107 | - HubBurw在私人渠道(如GITHUB/SLAK/话语)之间的两个维护者之间的群组通信 108 | - 家庭频道在私人频道上的两个维护者之间的直接1:1消息(例如imessage /懈怠/话语/ IRC/信鸽) 109 | 110 | 所有的交流都应该在GITHUB上公开进行.如果这是不可能或适当的(例如,安全泄露、两个维护者之间的人际问题、需要解决的紧急中断),则可以转移到维护者的私有组通信,以及,如果必要,1:1通信.技术决策不应该在1:1的通信中发生,但如果它们做了(或在过去做了),那么它们必须以GitHub上可链接的内容作为结束.例如,如果一年前在Slack上做出了一个技术决定,而另一个维护者/贡献者/用户在GitHub上询问它,那么这是一个向他们解释它的好机会,并且有一个将来可以链接到的东西. 111 | 112 | 这使得其他维护人员、贡献者和用户更容易跟上我们正在做的事情(更重要的是,我们为什么这样做),并且意味着决策具有可链接的URL. 113 | 114 | 所有维护者(和保持维护者)通过任何媒介进行通信是受约束的.[家酿行为准则](CODE_OF_CONDUCT.md#code-of-conduct). 对其他维护者、贡献者或用户的虐待行为将不被容忍;维护者将得到警告,如果他们的行为继续下去,他们将作为维护者被删除. 115 | 116 | 维护者应该自由地愉快地不同意其他维护者的工作和决定.积极鼓励维护人员之间健康、友好、技术上的分歧,并且应该在问题跟踪器上公开发生,以使项目更好.人际关系问题应该私下处理,最好是适度.如果工作或决定没有足够的文件或解释,任何维护人员或贡献者都应该随时要求澄清.任何维护者都不可能用"因为我这么说"或"我就是X"来做出决定.关于问题跟踪器的非主题讨论[自行车脱落](https://en.wikipedia.org/wiki/Law_of_triviality)个人攻击是被禁止的. 117 | 118 | ## 维护维护指南 119 | 120 | 应该有一个铅维护家自制.决策是由维护者的共识决定的.当未能达成共识时,主要维护者在决定任何决定的结果时具有最终发言权(尽管这种权力应该被节省使用).它们还应该被视为Homebrew本身的产品经理,并确保对整个Homebrew生态系统所做的更改是一致的,并为Homebrew的用户提供日益积极的体验. 121 | 122 | 正如Homebrew维护人员预计要花费更多的时间来审查和合并来自非维护人员贡献者的贡献而不是做出自己的贡献一样,主要维护人员应该花费大部分时间来审查来自其他维护人员的工作和指导其他维护人员内尔斯. 123 | 124 | 单独的Homebrew存储库不应该有正式的主维护者(尽管那些做最多工作的人会有最响亮的声音). 125 | 126 | 维护人员应该更加自由地愉快地表示不同意主要维护人员的工作和决定:随着更大的权威,处理和缓和技术分歧的责任也越来越大. 127 | 128 | HouBurw的最后一个主要维护者将是Mike McQuaid.2月1日,Mike将辞去Homebrew首席维护员的职务,他的职责将交给项目领导委员会和/或新的技术指导委员会和/或其他机构. 129 | 130 | 这些日期之前的一些思考和讨论: 131 | 132 | - [Apache软件基金会的工作原理](https://www.apache.org/foundation/how-it-works.html) 133 | - [Debian项目负责人文档](<>) 134 | - [Debian技术委员会文件](https://www.debian.org/devel/tech-ctte) 135 | - [Debian的组织结构](https://www.debian.org/intro/organization) 136 | - [QEMU SFC PLC文件](https://wiki.qemu.org/Conservancy) 137 | - [LBGIT2 SFC PLC的创建探讨](https://github.com/libgit2/discussions/issues/9) 138 | 139 | 这些日期之前必须做的一些事情: 140 | 141 | - 决定如何花更多的自制啤酒来帮助这个项目 142 | - 决定如何达成技术和非技术的决策和解决冲突 143 | - 移动自制到一个新的CI系统,不需要任何手动系统管理 144 | - 尽可能多地搭载新的维护人员 145 | - 一般来说,把麦克·麦奎德(Mike McQuaid)单独完成(并且一直如此)的任何其他职责移交给其他团队并记录下来 146 | -------------------------------------------------------------------------------- /src/FAQ.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 常见问题解答 3 | 4 | ## 如何更新本地包? 5 | 6 | 首先更新公式和自制程序: 7 | 8 | ``` 9 | brew update 10 | ``` 11 | 12 | 你现在可以发现什么过时了: 13 | 14 | ``` 15 | brew outdated 16 | ``` 17 | 18 | 升级一切: 19 | 20 | ``` 21 | brew upgrade 22 | ``` 23 | 24 | 或升级一个特定的公式: 25 | 26 | ``` 27 | brew upgrade 28 | ``` 29 | 30 | ## 如何阻止某些公式被更新? 31 | 32 | 阻止某物被更新/升级: 33 | 34 | ``` 35 | brew pin 36 | ``` 37 | 38 | 允许公式再次更新: 39 | 40 | ``` 41 | brew unpin 42 | ``` 43 | 44 | 注意,另一个公式所依赖的固定过时的公式在需要时需要升级,因为我们不允许针对非最新版本构建公式. 45 | 46 | ## 如何卸载旧版本的公式? 47 | 48 | 默认情况下,自制程序不会卸载旧版本的公式,所以随着时间的推移,你会积累旧版本.要删除它们,简单地使用: 49 | 50 | ``` 51 | brew cleanup 52 | ``` 53 | 54 | 或者立刻清理所有的东西: 55 | 56 | ``` 57 | brew cleanup 58 | ``` 59 | 60 | 或者看看会清理什么: 61 | 62 | ``` 63 | brew cleanup -n 64 | ``` 65 | 66 | ## 如何卸载自制软件? 67 | 68 | 要卸载自制程序,请在终端提示中粘贴下面的命令. 69 | 70 | ```sh 71 | ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall)" 72 | ``` 73 | 74 | 下载[卸载脚本](https://raw.githubusercontent.com/Homebrew/install/master/uninstall)并运行`./uninstall --help`查看更多卸载选项. 75 | 76 | ## 如何卸载公式? 77 | 78 | 如果不卸载Homebrew已安装的所有版本,Homebrew将继续尝试安装它运行时知道的最新版本`brew upgrade`. 这可能令人惊讶. 79 | 80 | 要完全删除公式,可以运行`brew uninstall formula_name --force`. 81 | 82 | 小心,因为这是破坏性的操作. 83 | 84 | ## 东西下载到哪里去了? 85 | 86 | ``` 87 | brew --cache 88 | ``` 89 | 90 | 通常是:`~/Library/Caches/Homebrew` 91 | 92 | ## 我的麦克`.app`没有找到`/usr/local/bin`公用事业! 93 | 94 | GoMac上的GUI应用程序没有`/usr/local/bin`在他们`PATH`默认情况下.如果你在山狮子或以后,你可以通过跑步来解决这个问题.`sudo launchctl config user path "/usr/local/bin:$PATH"`然后重新启动,如文件所示`man launchctl`. 注意,这设置了RunChCTL路径*所有用户*. 对于早期版本的MACOS,请参见[本页](https://developer.apple.com/legacy/library/qa/qa1067/_index.html). 95 | 96 | ## 我如何为家庭酿造做出贡献? 97 | 98 | 读[MD的贡献](https://github.com/Homebrew/brew/blob/master/CONTRIBUTING.md). 99 | 100 | ## 你为什么要编译所有的东西? 101 | 102 | 自制程序为许多公式提供了预编译版本.这些预编译版本称为[瓶](Bottles.md)并可在[HTTPS://BiTray.COM/HuBrWW/瓶](https://bintray.com/homebrew/bottles). 103 | 104 | 如果可用,默认情况下将使用瓶装二进制文件,除非在下列条件下: 105 | 106 | - 选项被传递到安装命令,即`brew install `将使用瓶装版本的公式,但`brew install --enable-bar`将触发源代码生成. 107 | - 这个`--build-from-source`选项被调用. 108 | - 环境变量`HOMEBREW_BUILD_FROM_SOURCE`设置(仅用于开发人员). 109 | - 该机器没有运行支持的MaOS版本,因为所有的瓶装构建都是为支持的MaOS版本生成的. 110 | - HygBurw安装到标准以外的前缀`/usr/local`(虽然有些瓶子支持这个). 111 | 112 | 我们的目标是把一切都装满. 113 | 114 | ## 我如何从别人的分支中得到一个公式? 115 | 116 | ```sh 117 | brew install hub 118 | brew update 119 | cd $(brew --repository) 120 | hub pull someone_else 121 | ``` 122 | 123 | 或: 124 | 125 | ``` 126 | brew pull https://github.com/Homebrew/homebrew-core/pull/1234 127 | ``` 128 | 129 | ## 为什么自制啤酒喜欢我安装`/usr/local`? 130 | 131 | 1. **更容易**
`/usr/local/bin`已经在你的心中`PATH`. 132 | 2. **更容易**
如果它们的依赖项不在其中,则生成脚本的数量会减少.`/usr`或`/usr/local`. 我们为Homebrew公式修复了这个问题(虽然我们并不总是测试它),但是您会发现许多RubyGems和Python设置脚本中断,这是我们无法控制的. 133 | 3. **它是安全的**
苹果已经为非系统公用事业分配了这个目录.这意味着没有文件在`/usr/local`默认情况下,不必担心弄乱现有或系统工具. 134 | 135 | **如果你打算安装依赖于酿造的宝石,那就为自己省下一大堆麻烦,然后安装到`/usr/local`!** 136 | 137 | 说出来并不总是直截了当的.`gem`查看头文件和库的非标准目录.如果你选择`/usr/local`很多事情都会"工作". 138 | 139 | ## 为什么家庭酿说SUDO不好? 140 | 141 | **DR**Sudo是危险的,不管怎么说,你安装了TutMata.App. 142 | 143 | 家庭酿拒绝使用SUDO工作. 144 | 145 | 你只应该做一个你信任的工具.当然,你可以信赖自制软件,但你相信自制程序运行的多兆字节的MaX文件吗?开发人员经常理解C++远远优于理解语法.这太危险了苏多这样的东西.它可以修改(或上载)系统中的任何文件.事实上,我们已经看到一些构建脚本试图修改.`/usr`即使前缀被指定为其他的东西. 146 | 147 | 我们使用MACOS沙箱来阻止这个,但是当运行时,这不起作用.`root`用户(对系统上几乎所有的事物都有读写访问权限). 148 | 149 | 是你`chown root /Applications/TextMate.app`?大概不会.所以重要的是`chown root wget`? 150 | 151 | 如果需要在多用户环境中运行自制程序,请考虑创建单独的用户帐户,尤其是使用自制程序. 152 | 153 | ## 为什么没有特定的命令记录? 154 | 155 | 如果不在`man brew`这可能是一个外部命令.这些文件被记录在案.[在这里](External-Commands.md). 156 | 157 | ## 你为什么不拉我的拉动请求? 158 | 159 | 如果已经有一段时间了,用一个"颠簸"的评论来撞击它.有时我们错过请求,而且有很多.也许我们在思考什么.这将鼓励考虑.在此期间,如果你可以重新拉拔请求,使它可以樱桃采摘更容易,我们会爱你很长一段时间. 160 | 161 | ## 我可以自己编辑公式吗? 162 | 163 | 对!这很容易!只是`brew edit `. 你不必把修改提交给`homebrew/core`只需根据个人需要编辑公式即可.`brew install`. 作为奖金`brew update`将合并您的更改与上游,所以您仍然可以保持公式最新**具有**你的个人修改! 164 | 165 | ## 我能做新公式吗? 166 | 167 | 对!这很容易!只是`brew create URL`. Houb酿将打开公式`EDITOR`所以你可以编辑它,但是它可能已经安装了;试试它:`brew 168 | install `. 如果遇到任何问题,请使用以下命令运行命令`--debug`开关如下:`brew install --debug `,这会让您进入调试外壳. 169 | 170 | 如果你希望你的新配方成为`homebrew/core`或者想更多地了解写作公式,那么请阅读[公式食谱](Formula-Cookbook.md). 171 | 172 | ## 我能安装我自己的东西吗?`/usr/local`? 173 | 174 | 对,`brew`被设计成不适合你的方式,所以你可以随心所欲地使用它. 175 | 176 | 安装您自己的东西,但是要注意,如果您自己安装libexpat等公共库,那么在尝试构建某些Homebrew公式时可能会带来麻烦.因此`brew doctor`会警告你这件事. 177 | 178 | 因此,最好把自己的东西安装到地窖里.`brew link`它.像这样: 179 | 180 | ```sh 181 | $ cd foo-0.1 182 | $ brew diy 183 | ./configure --prefix=/usr/local/Cellar/foo/0.1 184 | $ ./configure --prefix=/usr/local/Cellar/foo/0.1 185 | [snip] 186 | $ make && make install 187 | $ brew link foo 188 | Linking /usr/local/Cellar/foo/0.1… 17 symlinks created 189 | ``` 190 | 191 | ## 为什么公式被删除了? 192 | 193 | 使用`brew log `找出答案!可能是因为它有未解决的问题或者我们的分析发现它没有被广泛使用. 194 | 195 | ## 自制是一个很差的名字,太泛泛了,为什么要选择它呢? 196 | 197 | MXCL过于关注啤酒主题,并没有考虑到该项目实际上可能会受到欢迎.当他意识到这一点时,已经太迟了.然而,今天,第一个谷歌击中"自制"不是啤酒有关; 198 | 199 | ## "KEG"是什么意思? 200 | 201 | 这意味着公式只装在地窖里,没有链接到里面.`/usr/local`. 这意味着大多数工具找不到它.我们不会因为愚蠢的原因而这样做.如果需要的话,你仍然可以链接到公式中.`brew link`. 202 | 203 | ## 如何指定公式的不同配置参数? 204 | 205 | `brew edit `并编辑公式.目前没有其他的方法来做到这一点. 206 | 207 | ## 是否有术语术语表? 208 | 209 | 你所有的术语需要都可以[在这里找到](Formula-Cookbook.md#homebrew-terminology). 210 | -------------------------------------------------------------------------------- /src/Homebrew-and-Python.md: -------------------------------------------------------------------------------- 1 | # Python 2 | 3 | This page describes how Python is handled in Homebrew for users. See [Python for Formula Authors](Python-for-Formula-Authors.md) for advice on writing formulae to install packages written in Python. 4 | 5 | Homebrew should work with any [CPython](https://stackoverflow.com/questions/2324208/is-there-any-difference-between-cpython-and-python) and defaults to the macOS system Python. 6 | 7 | Homebrew provides formulae to brew 3.x and a more up-to-date Python 2.7.x. 8 | 9 | **Important:** If you choose to install a Python which isn't either of these two (system Python or brewed Python), the Homebrew team cannot support any breakage that may occur. 10 | 11 | ## Python 3.x or Python 2.x 12 | Homebrew provides one formula for Python 3.x (`python`) and another for Python 2.7.x (`python@2`). 13 | 14 | The executables are organized as follows so that Python 2 and Python 3 can both be installed without conflict: 15 | * `python3` points to Homebrew's Python 3.x (if installed) 16 | * `python2` points to Homebrew's Python 2.7.x (if installed) 17 | * `python` points to Homebrew's Python 2.7.x (if installed) otherwise the macOS system Python. Check out `brew info python` if you wish to add Homebrew's 3.x `python` to your `PATH`. 18 | * `pip3` points to Homebrew's Python 3.x's pip (if installed) 19 | * `pip` and `pip2` point to Homebrew's Python 2.7.x's pip (if installed) 20 | 21 | ([Wondering which one to choose?](https://wiki.python.org/moin/Python2orPython3)) 22 | 23 | ## Setuptools, Pip, etc. 24 | The Python formulae install [pip](http://www.pip-installer.org) (as `pip` or `pip2`) and [Setuptools](https://pypi.python.org/pypi/setuptools). 25 | 26 | Setuptools can be updated via pip, without having to re-brew Python: 27 | 28 | ```sh 29 | python -m pip install --upgrade setuptools 30 | ``` 31 | 32 | Similarly, pip can be used to upgrade itself via: 33 | 34 | ```sh 35 | python -m pip install --upgrade pip 36 | ``` 37 | 38 | ### Note on `pip install --user` 39 | The normal `pip install --user` is disabled for brewed Python. This is because of a bug in distutils, because Homebrew writes a `distutils.cfg` which sets the package `prefix`. 40 | 41 | A possible workaround (which puts executable scripts in `~/Library/Python/./bin`) is: 42 | 43 | ```sh 44 | python -m pip install --user --install-option="--prefix=" 45 | ``` 46 | 47 | ## `site-packages` and the `PYTHONPATH` 48 | The `site-packages` is a directory that contains Python modules (especially bindings installed by other formulae). Homebrew creates it here: 49 | 50 | ```sh 51 | $(brew --prefix)/lib/pythonX.Y/site-packages 52 | ``` 53 | 54 | So, for Python 3.y.z, you'll find it at `/usr/local/lib/python3.y/site-packages`. 55 | 56 | Python 3.y also searches for modules in: 57 | 58 | - `/Library/Python/3.y/site-packages` 59 | - `~/Library/Python/3.y/lib/python/site-packages` 60 | 61 | Homebrew's `site-packages` directory is first created if (1) any Homebrew formula with Python bindings are installed, or (2) upon `brew install python`. 62 | 63 | ### Why here? 64 | The reasoning for this location is to preserve your modules between (minor) upgrades or re-installations of Python. Additionally, Homebrew has a strict policy never to write stuff outside of the `brew --prefix`, so we don't spam your system. 65 | 66 | ## Homebrew-provided Python bindings 67 | Some formulae provide Python bindings. Sometimes a `--with-python` or `--with-python@2` option has to be passed to `brew install` in order to build the Python bindings. (Check with `brew options `.) 68 | 69 | **Warning!** Python may crash (see [Common Issues](Common-Issues.md)) if you `import ` from a brewed Python if you ran `brew install ` against the system Python. If you decide to switch to the brewed Python, then reinstall all formulae with Python bindings (e.g. `pyside`, `wxwidgets`, `pygtk`, `pygobject`, `opencv`, `vtk` and `boost-python`). 70 | 71 | ## Policy for non-brewed Python bindings 72 | These should be installed via `pip install `. To discover, you can use `pip search` or . (**Note:** System Python does not provide `pip`. Follow the [pip documentation](https://pip.readthedocs.io/en/stable/installing/#install-pip) to install it for your system Python if you would like it.) 73 | 74 | ## Brewed Python modules 75 | For brewed Python, modules installed with `pip` or `python setup.py install` will be installed to the `$(brew --prefix)/lib/pythonX.Y/site-packages` directory (explained above). Executable Python scripts will be in `$(brew --prefix)/bin`. 76 | 77 | The system Python may not know which compiler flags to set in order to build bindings for software installed in Homebrew so you may need to run: 78 | 79 | ```sh 80 | CFLAGS=-I$(brew --prefix)/include LDFLAGS=-L$(brew --prefix)/lib pip install 81 | ``` 82 | 83 | ## Virtualenv 84 | **WARNING:** When you `brew install` formulae that provide Python bindings, you should **not be in an active virtual environment**. 85 | 86 | Activate the virtualenv *after* you've brewed, or brew in a fresh Terminal window. 87 | Homebrew will still install Python modules into Homebrew's `site-packages` and *not* into the virtual environment's site-package. 88 | 89 | Virtualenv has a `--system-site-packages` switch to allow "global" (i.e. Homebrew's) `site-packages` to be accessible from within the virtualenv. 90 | 91 | ## Why is Homebrew's Python being installed as a dependency? 92 | Formulae that declare an unconditional dependency on the `"python"` or `"python@2"` formulae are bottled against Homebrew's Python 3.x or 2.7.x and require it to be installed. 93 | -------------------------------------------------------------------------------- /src/Analytics.md: -------------------------------------------------------------------------------- 1 | # Anonymous Aggregate User Behaviour Analytics 2 | 3 | Homebrew has begun gathering anonymous aggregate user behaviour analytics and reporting these to Google Analytics. You will be notified the first time you run `brew update` or install Homebrew. 4 | 5 | ## Why? 6 | Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. For example: 7 | 8 | - If a formula is widely used and is failing often it will enable us to prioritise fixing that formula over others. 9 | - Collecting the OS version allows us to decide what versions of macOS to prioritise and support and identify build failures that occur only on single versions. 10 | 11 | ## How Long? 12 | Homebrew's anonymous user and event data have a 14 month retention period. This is the [lowest possible value for Google Analytics](https://support.google.com/analytics/answer/7667196). 13 | 14 | ## What? 15 | Homebrew's analytics record some shared information for every event: 16 | 17 | - The Homebrew user agent, e.g. `Homebrew/0.9.9 (Macintosh; Intel macOS 10.12.0) curl/7.43.0` 18 | - The Google Analytics version, i.e. `1` (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#v) 19 | - The Homebrew analytics tracking ID, e.g. `UA-75654628-1` (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#tid) 20 | - A Homebrew analytics user ID, e.g. `1BAB65CC-FE7F-4D8C-AB45-B7DB5A6BA9CB`. This is generated by `uuidgen` and stored in the repository-specific Git configuration variable `homebrew.analyticsuuid` within `$(brew --repository)/.git/config`. This does not allow us to track individual users but does enable us to accurately measure user counts vs. event counts (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#cid) 21 | - If the Google Analytics anonymous IP setting is enabled, i.e. `1` (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#aip) 22 | - The Homebrew application name, e.g. `Homebrew` (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#an) 23 | - The Homebrew application version, e.g. `0.9.9` (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#av) 24 | - The Homebrew analytics hit type, e.g. `event` (https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#t) 25 | 26 | Homebrew's analytics records the following different events: 27 | 28 | - an `event` hit type with the `install` event category and the Homebrew formula from a non-private GitHub tap you install plus any used options, e.g. `wget --with-pcre` as the action and an event label e.g. `macOS 10.12, non-/usr/local, CI` to indicate the OS version, non-standard installation location and invocation as part of CI. This allows us to identify the formulae that need fixing and where more easily. 29 | - an `event` hit type with the `install_on_request` event category and the Homebrew formula from a non-private GitHub tap you have requested to install (e.g. explicitly named it with a `brew install`) plus options and an event label as above. This allows us to differentiate the formulae that users intend to install from those pulled in as dependencies. 30 | - an `event` hit type with the `cask_install` event category and the Homebrew cask from a non-private GitHub tap you install as the action and an event label as above. This allows us to identify the casks that need fixing and where more easily. 31 | - an `event` hit type with the `BuildError` event category and the Homebrew formula that failed to install, e.g. `wget` as the action and an event label e.g. `macOS 10.12`. 32 | 33 | You can also view all the information that is sent by Homebrew's analytics by setting `HOMEBREW_ANALYTICS_DEBUG=1` in your environment. Please note this will also stop any analytics from being sent. 34 | 35 | It is impossible for the Homebrew developers to match any particular event to any particular user, even if we had access to the Homebrew analytics user ID (which we do not). An example of the most user-specific information we can see from Google Analytics: 36 | 37 | ![Aggregate user analytics](assets/img/docs/analytics.png) 38 | 39 | As far as we can tell it would be impossible for Google to match the randomly generated Homebrew-only analytics user ID to any other Google Analytics user ID. If Google turned evil the only thing they could do would be to lie about anonymising IP addresses and attempt to match users based on IP addresses. 40 | 41 | ## When/Where? 42 | Homebrew's analytics are sent throughout Homebrew's execution to Google Analytics over HTTPS. 43 | 44 | ## Who? 45 | Summaries of installation and error analytics are publicly available [here](https://brew.sh/analytics/). A JSON API is also available. 46 | 47 | ## How? 48 | The code is viewable in [analytics.rb](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils/analytics.rb) and [analytics.sh](https://github.com/Homebrew/brew/blob/master/Library/Homebrew/utils/analytics.sh). They are done in a separate background process and fail fast to avoid delaying any execution. They will fail immediately and silently if you have no network connection. 49 | 50 | ## Opting out 51 | Homebrew analytics helps us maintainers and leaving it on is appreciated. However, if you want to opt out of Homebrew's analytics, you can set this variable in your environment: 52 | 53 | ```sh 54 | export HOMEBREW_NO_ANALYTICS=1 55 | ``` 56 | 57 | Alternatively, this will prevent analytics from ever being sent: 58 | 59 | ```sh 60 | brew analytics off 61 | ``` 62 | -------------------------------------------------------------------------------- /src/Gems,-Eggs-and-Perl-Modules.md: -------------------------------------------------------------------------------- 1 | # Gems, Eggs and Perl Modules 2 | 3 | On a fresh macOS installation there are three empty directories for 4 | add-ons available to all users: 5 | 6 | /Library/Ruby 7 | /Library/Python 8 | /Library/Perl 9 | 10 | Starting with OS X Lion (10.7), you need `sudo` to install to these like 11 | so: `sudo gem install`, `sudo easy_install` or `sudo cpan -i`. 12 | 13 | An option to avoid sudo is to use an access control list: 14 | `chmod +a 'user:YOUR_NAME_HERE allow add_subdirectory,add_file,delete_child,directory_inherit' /Library/Python/3.y/site-packages`, 15 | for example, will let you add packages to Python 3.y as yourself. That 16 | is probably safer than changing the group ownership of the directory. 17 | 18 | ### So why was I using sudo? 19 | Habit maybe? 20 | 21 | One reason is executables go in `/usr/local/bin`. Usually this isn’t a 22 | writable location. But if you installed Homebrew as we recommend, 23 | `/usr/local` will be writable without sudo. So now you are good to 24 | install the development tools you need without risking the use of sudo. 25 | 26 | ## Python packages (eggs) without sudo 27 | 28 | Rather than changing the rights on `/Library/Python`, we recommend the 29 | following options: 30 | 31 | ### With a brewed Python 32 | Note, `easy_install` is deprecated. We install `pip` (or `pip2` for 33 | Python 2) along with python/python2. 34 | 35 | We set up distutils such that `pip install` will always put modules in 36 | `$(brew --prefix)/lib/pythonX.Y/site-packages` and scripts in 37 | `$(brew --prefix)/share/python`. Therefore, you won’t need sudo! 38 | 39 | Do `brew info python` or `brew info python@2` for precise information 40 | about the paths. Note, a brewed Python still searches for modules in 41 | `/Library/Python/X.Y/site-packages` and also in 42 | `~/Library/Python/X.Y/lib/python/site-packages`. 43 | 44 | ### With system’s Python 45 | _This is only recommended if you **don't** use a brewed Python._ 46 | 47 | On macOS, any [Python version X.Y also searches in 48 | `~/Library/Python/X.Y/lib/python/site-packages` for 49 | modules](https://docs.python.org/2/install/index.html#inst-alt-install-user). 50 | That dir might not yet exist, but you can create it: 51 | 52 | ```sh 53 | mkdir -p ~/Library/Python/2.7/lib/python/site-packages 54 | ``` 55 | 56 | To teach `easy_install` and `pip` to install there, either use the 57 | `--user` switch or create a `~/.pydistutils.cfg` file with the 58 | following content: 59 | 60 | [install] 61 | install_lib = ~/Library/Python/$py_version_short/lib/python/site-packages 62 | 63 | ### Using virtualenv - works with brewed and system’s Python 64 | 65 | [Virtualenv](http://www.virtualenv.org/en/latest/) ships `pip` and 66 | creates isolated Python environments with separate site-packages, 67 | therefore you won’t need sudo. 68 | 69 | ## Rubygems without sudo 70 | 71 | **If you use rbenv or RVM then you should ignore this stuff** 72 | 73 | Brewed Ruby installs executables to `$(brew --prefix)/opt/ruby/bin` 74 | without sudo. You should add this to your path. See the caveats in the 75 | `ruby` formula for up-to-date information. 76 | 77 | ### With system’s Ruby 78 | 79 | To make Ruby install to `/usr/local`, we need to add 80 | `gem: -n/usr/local/bin` to your `~/.gemrc`. It’s YAML, so do it manually 81 | or use this: 82 | 83 | ```sh 84 | echo "gem: -n/usr/local/bin" >> ~/.gemrc 85 | ``` 86 | 87 | **However, all versions of RubyGems before 1.3.6 are buggy** and ignore 88 | the above setting. Sadly a fresh install of Snow Leopard comes with 89 | 1.3.5. Currently the only known way to get around this is to upgrade 90 | rubygems as root: 91 | 92 | ```sh 93 | sudo gem update --system 94 | ``` 95 | 96 | ### An alternative 97 | 98 | Just install everything into the Homebrew prefix like this: 99 | 100 | ```sh 101 | echo "export GEM_HOME=\"$(brew --prefix)\"" >> ~/.bashrc 102 | ``` 103 | 104 | ### It doesn’t work! I get some “permissions” error when I try to install stuff! 105 | 106 | *Note, maybe you shouldn’t do this on Lion, since Apple has decided it 107 | is not a good default.* 108 | 109 | If you ever did a `sudo gem`, etc. before then a lot of files will have 110 | been created owned by root. Fix with: 111 | 112 | ```sh 113 | sudo chown -R $USER /Library/Ruby /Library/Perl /Library/Python 114 | ``` 115 | 116 | ## Perl CPAN modules without sudo 117 | 118 | The Perl module `local::lib` works similarly to rbenv/RVM (although for 119 | modules only, not perl installations). A simple solution that only 120 | pollutes your `/Library/Perl` a little is to install 121 | [`local::lib`](https://metacpan.org/pod/local::lib) with sudo: 122 | 123 | ```sh 124 | sudo cpan local::lib 125 | ``` 126 | 127 | Note that this will install some other dependencies like `Module::Install`. 128 | Then put the appropriate incantation in your shell’s startup, e.g. for 129 | `.bash_profile` you insert the below, for others see the 130 | [`local::lib`](https://metacpan.org/pod/local::lib) docs. 131 | 132 | ```sh 133 | eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib) 134 | ``` 135 | 136 | Now (after you restart your shell) `cpan` or `perl -MCPAN -eshell` etc. 137 | will install modules and binaries in `~/perl5` and the relevant 138 | subdirectories will be in your `PATH` and `PERL5LIB` etc. 139 | 140 | ### Avoiding sudo altogether for Perl 141 | 142 | If you don’t even want (or can’t) use sudo for bootstrapping 143 | `local::lib`, just manually install `local::lib` in 144 | `~/perl5` and add the relevant path to `PERL5LIB` before the .bashrc eval incantation. 145 | 146 | Another alternative is to use `perlbrew` to install a separate copy of Perl in your home directory, or wherever you like: 147 | 148 | ```sh 149 | curl -L https://install.perlbrew.pl | bash 150 | perlbrew install perl-5.16.2 151 | echo ".~/perl5/perlbrew/etc/bashrc" >> ~/.bashrc 152 | ``` 153 | -------------------------------------------------------------------------------- /src/Prose-Style-Guidelines.md: -------------------------------------------------------------------------------- 1 | # Prose Style Guidelines 2 | 3 | This is a set of style and usage guidelines for Homebrew's prose documentation aimed at users, contributors, and maintainers (as opposed to executable computer code). It applies to documents like those in `docs` in the `Homebrew/brew` repository, announcement emails, and other communications with the Homebrew community. 4 | 5 | This does not apply to any Ruby or other computer code. You can use it to inform technical documentation extracted from computer code, like embedded man pages, but it's just a suggestion there. 6 | 7 | ## Goals and audience 8 | 9 | The primary goal of Homebrew's prose documents is communicating with its community of users and contributors. "Users" includes "contributors" here; wherever you see "users" you can substitute "users and contributors". 10 | 11 | Understandability trumps any particular style guideline. 12 | 13 | Users trump maintainers, except in specifically maintainer-focused documents. 14 | 15 | Homebrew's audience includes users with a wide range of education and experience, and users for whom English is not a native language. We aim to support as many of those users as feasible. 16 | 17 | We strive for "correct" but not "fancy" usage. Think newspaper article, not academic paper. 18 | 19 | This is a set of guidelines to be applied using human judgment, not a set of hard and fast rules. It is like [The Economist's Style Guide](https://www.economist.com/styleguide/introduction) or [Garner's Modern American Usage](https://en.wikipedia.org/wiki/Garner's_Modern_American_Usage). It is less like the [Ruby Style Guide](https://github.com/bbatsov/ruby-style-guide). All guidelines here are open to interpretation and discussion. 100% conformance to these guidelines is *not* a goal. 20 | 21 | The intent of this document is to help authors make decisions about clarity, style, and consistency. It is not to help settle arguments about who knows English better. Don't use this document to be a jerk. 22 | 23 | ## Guidelines 24 | 25 | We prefer: 26 | 27 | ### Style and usage 28 | 29 | * British/Commonwealth English over American English, in general 30 | * "e.g." and "i.e.": Go ahead and use "e.g." or "i.e." instead of spelling them out. Don't worry about putting a comma after them. 31 | * "e.g." means "for example"; "i.e." means "that is" 32 | * Offset nontrivial subordinate clauses with commas 33 | 34 | ### Personal pronouns 35 | 36 | * We respect all people's choice of personal pronouns 37 | * Singular "they" when someone's gender is unknown 38 | * Avoid gender-specific language when not necessary 39 | 40 | ### Structure and markup 41 | 42 | * Sentence case in section headings, not Title Case 43 | * Periods at the ends of list items where most items in that list are complete sentences 44 | * More generally, parallel list item structure 45 | * Capitalise all list items if you want, even if they're not complete sentences; just be consistent within each list, and preferably, throughout the whole page 46 | * Use a subordinate list item instead of dropping a multi-sentence paragraph-long item into a list of sentence fragments 47 | * Prefer Markdown over other markup formats unless their specific features are needed 48 | * GitHub Flavoured Markdown. GitHub's implementation is the standard, period. 49 | 50 | ### Typographical conventions 51 | 52 | * Literal text in commands and code is styled in `fixed width font` 53 | * Placeholders inside code snippets are marked up with `<...>` brackets 54 | * e.g. `git remote add https://github.com//homebrew-core.git` 55 | * Names of commands like `git` and `brew` are styled in `fixed width font` 56 | * No "$" with environment variables mentioned outside code snippets 57 | * e.g. "Set `BLAH` to 5", not "Set `$BLAH` to 5" 58 | * One space after periods, not two 59 | * Capitalised proper nouns 60 | * We do not defer to extensive nonstandard capitalisation, typesetting, or other styling of brand names, aside from the normal capitalisation of proper nouns and simple internal capitalisation 61 | * No "TM", ™, SM, ©, ®, or other explicit indicators of rights ownership or trademarks; we take these as understood when the brand name is mentioned 62 | * Tap names like `homebrew/core` are styled in `fixed width font`. Repository names may be styled in either fixed width font like "`Homebrew/homebrew-core`", as links like "[Homebrew/homebrew-core](https://github.com/homebrew/homebrew-core)", or regular text like "Homebrew/homebrew-core", based on which looks best for a given use. 63 | * But be consistent within a single document 64 | * Capitalise repository names to match the user and repository names on GitHub. Keep tap names in lower case. 65 | * Commas 66 | * No Oxford commas 67 | * Prefer a "loose" comma style: "when in doubt, leave it out" unless needed for clarity 68 | 69 | ### Terminology, words, and word styling 70 | 71 | * "pull request", not "Pull Request" 72 | * "check out" is the verb; "checkout" is the noun 73 | * Spell out certain technical words 74 | * "repository", not "repo" 75 | * When abbreviating, introduce the abbreviation with the first usage in any document 76 | * Some abbreviations (near-universally understood among our user base) are fine, though. 77 | * "Mac" is fine; "Macintosh" isn't necessary 78 | * "macOS" for all versions, "OS X" or "Mac OS X" when describing specific older versions 79 | * "RuboCop", not "Rubocop" 80 | * A pull request is made "on" a repository; that repository is "at" a URL 81 | 82 | ## How to use these guidelines 83 | 84 | Refer to these guidelines to make decisions about style and usage in your own writing for Homebrew documents and communication. 85 | 86 | PRs that fix style and usage throughout a document or multiple documents are okay and encouraged. PRs for just one or two style changes are a bit much. 87 | 88 | Giving style and usage feedback on a PR or commit that involves documents is okay and encouraged. But keep in mind that these are just guidelines, and for any change, the author may have made a deliberate choice to break these rules in the interest of understandability or aesthetics. 89 | -------------------------------------------------------------------------------- /src/New-Maintainer-Checklist.md: -------------------------------------------------------------------------------- 1 | # New Maintainer Checklist 2 | 3 | **This is a guide used by existing maintainers to invite new maintainers. You might find it interesting but there's nothing here users should have to know.** 4 | 5 | There's someone who has been making consistently high-quality contributions to Homebrew for a long time and shown themselves able to make slightly more advanced contributions than just e.g. formula updates? Let's invite them to be a maintainer! 6 | 7 | First, send them the invitation email: 8 | 9 | ``` 10 | The Homebrew team and I really appreciate your help on issues, pull requests and 11 | your contributions to Homebrew. 12 | 13 | We would like to invite you to have commit access and be a Homebrew maintainer. 14 | If you agree to be a maintainer, you should spend a significant proportion of 15 | the time you are working on Homebrew fixing user-reported issues, resolving any 16 | issues that arise from your code in a timely fashion and reviewing user 17 | contributions. You should also be making contributions to Homebrew every month 18 | unless you are ill or on vacation (and please let another maintainer know if 19 | that's the case so we're aware you won't be able to help while you are out). 20 | 21 | You will need to watch Homebrew/brew and/or Homebrew/homebrew-core. Let us know 22 | which (or both) so we can grant you commit access appropriately. 23 | 24 | If you're no longer able to perform all of these tasks, please continue to 25 | contribute to Homebrew, but we will ask you to step down as a maintainer. 26 | 27 | A few requests: 28 | 29 | - please make pull requests on any changes to Homebrew/brew code or any 30 | non-trivial (e.g. not a test or audit improvement or version bump) changes 31 | to formulae code and don't merge them unless you get at least one approval 32 | and passing tests. 33 | - use `brew pull` for formulae changes that require new bottles or change 34 | multiple formulae and let it auto-close issues wherever possible (it may 35 | take ~5m). When this isn't necessary use GitHub's "Merge pull request" 36 | button in "create a merge commit" mode for Homebrew/brew or "squash and 37 | merge" for a single formulae change. If in doubt, check with e.g. GitX that 38 | you've not accidentally added merge commits 39 | - still create your branches on your fork rather than in the main repository. 40 | Note GitHub's UI will create edits and reverts on the main repository if you 41 | make edits or click revert on the Homebrew/brew repository rather than your 42 | own fork. 43 | - if still in doubt please ask for help and we'll help you out 44 | - please read: 45 | - https://docs.brew.sh/Brew-Test-Bot-For-Core-Contributors 46 | - https://docs.brew.sh/Maintainer-Guidelines 47 | - anything else you haven't read on https://docs.brew.sh 48 | 49 | How does that sound? 50 | 51 | Thanks for all your work so far! 52 | ``` 53 | 54 | If they accept, follow a few steps to get them set up: 55 | 56 | - Invite them to the [**@Homebrew/maintainers** team](https://github.com/orgs/Homebrew/teams/maintainers) (or any relevant [subteams](https://github.com/orgs/Homebrew/teams/maintainers/teams)) to give them write access to relevant repositories (but don't make them owners). They will need to enable [GitHub's Two Factor Authentication](https://help.github.com/articles/about-two-factor-authentication/). 57 | - Ask them to sign in to [Bintray](https://bintray.com) using their GitHub account and they should auto-sync to [Bintray's Homebrew organisation](https://bintray.com/homebrew/organization/edit/members) as a member so they can publish new bottles 58 | - Add them to the [Jenkins' GitHub Authorization Settings admin user names](https://jenkins.brew.sh/configureSecurity/) so they can adjust settings and restart jobs 59 | - Add them to the [Jenkins' GitHub Pull Request Builder admin list](https://jenkins.brew.sh/configure) to enable `@BrewTestBot test this please` for them 60 | - Invite them to the [`homebrew-maintainers` private maintainers mailing list](https://lists.sfconservancy.org/mailman/admin/homebrew-maintainers/members/add) 61 | - Invite them to the [`machomebrew` private maintainers Slack](https://machomebrew.slack.com/admin/invites) (and ensure they've read the [communication guidelines](Maintainer-Guidelines.md#communication)) 62 | - Ask them to disable SMS as a 2FA device or fallback on their GitHub account in favour of using one of the other authentication methods. 63 | - Ask them to (regularly) review remove any unneeded [GitHub personal access tokens](https://github.com/settings/tokens) 64 | - Add them to [Homebrew/brew's README](https://github.com/Homebrew/brew/edit/master/README.md) 65 | 66 | If they are also interested in doing system administration work: 67 | 68 | - Invite them to the [`homebrew-ops` private operations mailing list](https://lists.sfconservancy.org/mailman/admin/homebrew-ops/members/add) 69 | - Invite them to the [`homebrew` private 1Password](https://homebrew.1password.com/people) 70 | 71 | If they want to consume raw anonymous aggregate analytics data (rather than use `brew formula-analytics`): 72 | 73 | - Invite them to [Google Analytics](https://analytics.google.com/analytics/web/?authuser=1#management/Settings/a76679469w115400090p120682403/%3Fm.page%3DAccountUsers/) 74 | 75 | Once they have been active maintainers for at least a year and had some activity on more than one Homebrew organisation repository (or one repository and helped with system administration work): 76 | 77 | - Homebrew's [Software Freedom Conservancy](https://sfconservancy.org) Project Leadership Committee can take a vote on whether to extend an offer to the maintainer to join the committee. If they accept, email their name, email and employer to homebrew@sfconservancy.org, make them [owners on the Homebrew GitHub organisation](https://github.com/orgs/Homebrew/people) and add them to the relevant section of the [Homebrew/brew's README](https://github.com/Homebrew/brew/edit/master/README.md). 78 | 79 | If there are problems, ask them to step down as a maintainer and revoke their access to all of the above. 80 | 81 | Now sit back, relax and let the new maintainers handle more of our contributions. 82 | -------------------------------------------------------------------------------- /src/Common-Issues.md: -------------------------------------------------------------------------------- 1 | # Common Issues 2 | 3 | This is a list of commonly encountered problems, known issues, and their solutions. 4 | 5 | ### `brew` complains about absence of "Command Line Tools" 6 | You need to have the Xcode Command Line Utilities installed (and updated): run `xcode-select --install` in the terminal. 7 | (In OS X prior to 10.9, the "Command Line Tools" package can alternatively be installed from within Xcode. `⌘,` will get you to preferences. Visit the "Downloads" tab and hit the install button next to "Command Line Tools".) 8 | 9 | ### Ruby: `bad interpreter: /usr/bin/ruby^M: no such file or directory` 10 | You cloned with `git`, and your Git configuration is set to use Windows line endings. See this page: 11 | 12 | ### Ruby: `bad interpreter: /usr/bin/ruby` 13 | You don't have a `/usr/bin/ruby` or it is not executable. It's not recommended to let this persist; you'd be surprised how many `.app`s, tools and scripts expect your macOS-provided files and directories to be *unmodified* since macOS was installed. 14 | 15 | ### `brew update` complains about untracked working tree files 16 | After running `brew update`, you receive a Git error warning about untracked files or local changes that would be overwritten by a checkout or merge, followed by a list of files inside your Homebrew installation. 17 | 18 | This is caused by an old bug in in the `update` code that has long since been fixed. However, the nature of the bug requires that you do the following: 19 | 20 | ```sh 21 | cd $(brew --repository) 22 | git reset --hard FETCH_HEAD 23 | ``` 24 | 25 | If `brew doctor` still complains about uncommitted modifications, also run this command: 26 | 27 | ```sh 28 | cd $(brew --repository)/Library 29 | git clean -fd 30 | ``` 31 | 32 | ### Ruby: `invalid multibyte escape: /^\037\213/` 33 | 34 | You see an error similar to: 35 | 36 | ``` 37 | Error: /usr/local/Library/Homebrew/download_strategy.rb:84: invalid multibyte escape: /^\037\213/ 38 | invalid multibyte escape: /^\037\235/ 39 | ``` 40 | 41 | In the past, Homebrew assumed that `/usr/bin/ruby` was Ruby 1.8. On OS X 10.9, it is now Ruby 2.0. There are various incompatibilities between the two versions, so if you upgrade to OS X 10.9 while using a sufficiently old version of Homebrew, you will encounter errors. 42 | 43 | The incompatibilities have been addressed in more recent versions of Homebrew, and instead of making assumptions about `/usr/bin/ruby`, it uses the executable inside macOS's Ruby framework or a vendored Ruby. 44 | 45 | To recover from this situation, do the following: 46 | 47 | ```sh 48 | cd $(brew --prefix) 49 | git fetch origin 50 | git reset --hard FETCH_HEAD 51 | brew update 52 | ``` 53 | 54 | ### `launchctl` refuses to load launchd plist files 55 | When trying to load a plist file into launchctl, you receive an error that resembles 56 | 57 | ``` 58 | Bug: launchctl.c:2325 (23930):13: (dbfd = open(g_job_overrides_db_path, [...] 59 | launch_msg(): Socket is not connected 60 | ``` 61 | 62 | or 63 | 64 | ``` 65 | Could not open job overrides database at: /private/var/db/launchd.db/com.apple.launchd/overrides.plist: 13: Permission denied 66 | launch_msg(): Socket is not connected 67 | ``` 68 | 69 | These are likely due to one of four issues: 70 | 71 | 1. You are using iTerm. The solution is to use Terminal.app when interacting with `launchctl`. 72 | 2. You are using a terminal multiplexer such as `tmux` or `screen`. You should interact with `launchctl` from a separate Terminal.app shell. 73 | 3. You are attempting to run `launchctl` while logged in remotely. You should enable screen sharing on the remote machine and issue the command using Terminal.app running on that machine. 74 | 4. You are `su`'ed as a different user. 75 | 76 | ### `brew upgrade` errors out 77 | When running `brew upgrade`, you see something like this: 78 | 79 | ``` 80 | $ brew upgrade 81 | Error: undefined method `include?' for nil:NilClass 82 | Please report this bug: 83 | https://docs.brew.sh/Troubleshooting 84 | /usr/local/Library/Homebrew/formula.rb:393:in `canonical_name' 85 | /usr/local/Library/Homebrew/formula.rb:425:in `factory' 86 | /usr/local/Library/Contributions/examples/brew-upgrade.rb:7 87 | /usr/local/Library/Contributions/examples/brew-upgrade.rb:7:in `map' 88 | /usr/local/Library/Contributions/examples/brew-upgrade.rb:7 89 | /usr/local/bin/brew:46:in `require' 90 | /usr/local/bin/brew:46:in `require?' 91 | /usr/local/bin/brew:79 92 | ``` 93 | 94 | This happens because an old version of the upgrade command is hanging around for some reason. The fix: 95 | 96 | ```sh 97 | cd $(brew --repository)/Library/Contributions/examples 98 | git clean -n # if this doesn't list anything that you want to keep, then 99 | git clean -f # this will remove untracked files 100 | ``` 101 | 102 | ### Python: easy-install.pth cannot be linked 103 | 104 | ``` 105 | Warning: Could not link . Unlinking... 106 | Error: The `brew link` step did not complete successfully 107 | The formula built, but is not symlinked into /usr/local 108 | You can try again using `brew link ' 109 | 110 | Possible conflicting files are: 111 | /usr/local/lib/python2.7/site-packages/site.py 112 | /usr/local/lib/python2.7/site-packages/easy-install.pth 113 | ==> Could not symlink file: /homebrew/Cellar///lib/python2.7/site-packages/site.py 114 | Target /usr/local/lib/python2.7/site-packages/site.py already exists. You may need to delete it. 115 | To force the link and overwrite all other conflicting files, do: 116 | brew link --overwrite formula_name 117 | 118 | To list all files that would be deleted: 119 | brew link --overwrite --dry-run formula_name 120 | ``` 121 | 122 | Don't follow the advice here but fix by using 123 | `Language::Python.setup_install_args` in the formula as described in 124 | [Python for Formula Authors](Python-for-Formula-Authors.md). 125 | 126 | ### Upgrading macOS 127 | 128 | Upgrading macOS can cause errors like the following: 129 | 130 | - `dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.54.dylib` 131 | - `configure: error: Cannot find libz` 132 | 133 | Following a macOS upgrade it may be necessary to reinstall the Xcode Command Line Tools and `brew upgrade` all installed formula: 134 | 135 | ```sh 136 | xcode-select --install 137 | brew upgrade 138 | ``` 139 | -------------------------------------------------------------------------------- /src/How-To-Open-a-Homebrew-Pull-Request.md: -------------------------------------------------------------------------------- 1 | # How To Open a Homebrew Pull Request (and get it merged) 2 | 3 | The following commands are used by Homebrew contributors to set up a fork of Homebrew's Git repository on GitHub, create a new branch and create a GitHub pull request ("PR") of the changes in that branch. 4 | 5 | Depending on the change you want to make, you need to send the pull request to the appropriate one of Homebrew's main repositories. If you want to submit a change to Homebrew core code (the `brew` implementation), you should open the pull request on [Homebrew/brew](https://github.com/Homebrew/brew). If you want to submit a change for a formula, you should open the pull request on [the `homebrew/core` tap](https://github.com/Homebrew/homebrew-core) or another [official tap](https://github.com/Homebrew), based on the formula type. 6 | 7 | ## Submit a new version of an existing formula 8 | 1. Use `brew bump-formula-pr` to do everything (i.e. forking, committing, pushing) with a single command. Run `brew bump-formula-pr --help` to learn more. 9 | 10 | ## Set up your own fork of the Homebrew repository 11 | 12 | ### Core `brew` code related pull request 13 | 14 | 1. [Fork the Homebrew/brew repository on GitHub](https://github.com/Homebrew/brew/fork). 15 | * This creates a personal remote repository that you can push to. This is needed because only Homebrew maintainers have push access to the main repositories. 16 | 2. Change to the directory containing your Homebrew installation with `cd $(brew --repository)`. 17 | 3. Add your pushable forked repository with `git remote add https://github.com//brew.git`. 18 | * `` is your GitHub username, not your local machine username. 19 | 20 | ### Formulae related pull request 21 | 22 | 1. [Fork the Homebrew/homebrew-core repository on GitHub](https://github.com/Homebrew/homebrew-core/fork). 23 | * This creates a personal remote repository that you can push to. This is needed because only Homebrew maintainers have push access to the main repositories. 24 | 2. Change to the directory containing Homebrew formulae with `cd $(brew --repository homebrew/core)`. 25 | 3. Add your pushable forked repository with `git remote add https://github.com//homebrew-core.git` 26 | * `` is your GitHub username, not your local machine username. 27 | 28 | ## Create your pull request from a new branch 29 | 30 | To make a new branch and submit it for review, create a GitHub pull request with the following steps: 31 | 32 | 1. Check out the `master` branch with `git checkout master`. 33 | 2. Retrieve new changes to the `master` branch with `brew update`. 34 | 3. Create a new branch from the latest `master` branch with `git checkout -b origin/master`. 35 | 4. Make your changes. For formulae, use `brew edit` or your favourite text editor, following all the guidelines in the [Formula Cookbook](Formula-Cookbook.md). 36 | * If there's a `bottle do` block in the formula, don't remove or change it; we'll update it when we pull your PR. 37 | 5. Test your changes by doing the following, and ensure they all pass without issue. For changed formulae, make sure you do the `brew audit` step while your changed formula is installed. 38 | * `brew tests` 39 | * `brew install --build-from-source ` 40 | * `brew test ` 41 | * `brew audit --strict ` 42 | 6. Make a separate commit for each changed formula with `git add` and `git commit`. 43 | 7. Upload your new commits to the branch on your fork with `git push --set-upstream `. 44 | 8. Go to the relevant repository (e.g. , , etc.) and create a pull request to request review and merging of the commits in your pushed branch. Explain why the change is needed and, if fixing a bug, how to reproduce the bug. Make sure you have done each step in the checklist that appears in your new PR. 45 | * Please note that our preferred commit message format for simple version updates is "` `", e.g. "`source-highlight 3.1.8`". `devel` version updates should have the commit message suffixed with `(devel)`, e.g. "`nginx 1.9.1 (devel)`". If updating both `stable` and `devel`, the format should be a concatenation of these two forms, e.g. "`x264 r2699, r2705 (devel)`". 46 | 9. Await feedback or a merge from Homebrew's maintainers. We typically respond to all PRs within a couple days, but it may take up to a week, depending on the maintainers' workload. 47 | 48 | Thank you! 49 | 50 | ## Following up 51 | 52 | To respond well to feedback: 53 | 54 | 1. Ask for clarification of anything you don't understand and for help with anything you don't know how to do. 55 | 2. Post a comment on your pull request if you've provided all the requested changes/information and it hasn't been merged after a week. Post a comment on your pull request if you're stuck and need help. 56 | * A `needs response` label on a PR means that the Homebrew maintainers need you to respond to previous comments. 57 | 3. Keep discussion in the pull request unless requested otherwise (i.e. do not email maintainers privately). 58 | 4. Do not continue discussion in closed pull requests. 59 | 5. Do not argue with Homebrew maintainers. You may disagree but unless they change their mind, please implement what they request. Ultimately they control what is included in Homebrew, as they have to support any changes that are made. 60 | 61 | To make changes based on feedback: 62 | 63 | 1. Check out your branch again with `git checkout `. 64 | 2. Make any requested changes and commit them with `git add` and `git commit`. 65 | 3. Squash new commits into one commit per formula with `git rebase --interactive origin/master`. 66 | 4. Push to your remote fork's branch and the pull request with `git push --force`. 67 | 68 | If you are working on a PR for a single formula, `git commit --amend` is a convenient way of keeping your commits squashed as you go. 69 | 70 | Once all feedback has been addressed and if it's a change we want to include (we include most changes), then we'll add your commit to Homebrew. Note that the PR status may show up as "Closed" instead of "Merged" because of the way we merge contributions. Don't worry: you will still get author credit in the actual merged commit. 71 | 72 | Well done, you are now a Homebrew contributor! 73 | -------------------------------------------------------------------------------- /src/Node-for-Formula-Authors.md: -------------------------------------------------------------------------------- 1 | # Node for Formula Authors 2 | 3 | This document explains how to successfully use Node and npm in a Node module based Homebrew formula. 4 | 5 | ## Running `npm install` 6 | 7 | Homebrew provides two helper methods in a `Language::Node` module: `std_npm_install_args` and `local_npm_install_args`. They both set up the correct environment for npm and return arguments for `npm install` for their specific use cases. Your formula should use these instead of invoking `npm install` explicitly. The syntax for a standard Node module installation is: 8 | 9 | ```ruby 10 | system "npm", "install", *Language::Node.std_npm_install_args(libexec) 11 | ``` 12 | 13 | where `libexec` is the destination prefix (usually the `libexec` variable). 14 | 15 | ## Download URL 16 | 17 | If the Node module is also available on the npm registry, we prefer npm hosted release tarballs over GitHub (or elsewhere) hosted source tarballs. The advantages of these tarballs are that they don't include the files from the `.npmignore` (such as tests) resulting in a smaller download size and that any possible transpilation step is already done (e.g. no need to compile CoffeeScript files as a build step). 18 | 19 | The npm registry URLs usually have the format of: 20 | 21 | https://registry.npmjs.org//-/-.tgz 22 | 23 | Alternatively you could `curl` the JSON at `https://registry.npmjs.org/` and look for the value of `versions[].dist.tarball` for the correct tarball URL. 24 | 25 | ## Dependencies 26 | 27 | Node modules which are compatible with the latest Node version should declare a dependency on the `node` formula. 28 | 29 | ```ruby 30 | depends_on "node" 31 | ``` 32 | 33 | If your formula requires being executed with an older Node version you should use one of the versioned node formulae (e.g. `node@6`). 34 | 35 | ### Special requirements for native addons 36 | 37 | If your Node module is a native addon or has a native addon somewhere in its dependency tree you have to declare an additional dependency. Since the compilation of the native addon results in an invocation of `node-gyp` we need an additional build time dependency on `"python"` (because GYP depends on Python 2.7). 38 | 39 | ```ruby 40 | depends_on "python" => :build 41 | ``` 42 | 43 | Also note that such a formula would only be compatible with the same Node major version it originally was compiled with. This means that we need to revision every formula with a Node native addon with every major version bump of the `node` formula. To make sure we don't overlook your formula on a Node major version bump, write a meaningful test which would fail in such a case (invoked with an ABI-incompatible Node version). 44 | 45 | ## Installation 46 | 47 | Node modules should be installed to `libexec`. This prevents the Node modules from contaminating the global `node_modules`, which is important so that npm doesn't try to manage Homebrew-installed Node modules. 48 | 49 | In the following we distinguish between two types of Node modules using formulae: 50 | * formulae for standard Node modules compatible with npm's global module format which should use [`std_npm_install_args`](#installing-global-style-modules-with-std_npm_install_args-to-libexec) (like [`azure-cli`](https://github.com/Homebrew/homebrew-core/blob/0f3b27d252b8112c744e0460d871cfe1def6b993/Formula/azure-cli.rb) or [`webpack`](https://github.com/Homebrew/homebrew-core/blob/6282879973d569962e63da7c81ac4623e1a8336b/Formula/webpack.rb)) and 51 | * formulae where the `npm install` call is not the only required install step (e.g. need to compile non-JavaScript sources too) have to use [`local_npm_install_args`](#installing-module-dependencies-locally-with-local_npm_install_args) (like [`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/4bb491b7b246830aed57b97348a17e9401374978/Formula/elixirscript.rb) 52 | 53 | Both methods have in common that they are setting the correct environment for using npm inside Homebrew and are returning the arguments for invoking `npm install` for their specific use cases. This includes fixing an important edge case with the npm cache (caused by Homebrew's redirection of `HOME` during the build and test process) by using our own custom `npm_cache` inside `HOMEBREW_CACHE`, which would otherwise result in very long build times and high disk space usage. 54 | 55 | To use them you have to require the Node language module at the beginning of your formula file with: 56 | 57 | ```ruby 58 | require "language/node" 59 | ``` 60 | 61 | ### Installing global style modules with `std_npm_install_args` to `libexec` 62 | 63 | In your formula's `install` method, simply `cd` to the top level of your Node module if necessary and then use `system` to invoke `npm install` with `Language::Node.std_npm_install_args` like: 64 | 65 | ```ruby 66 | system "npm", "install", *Language::Node.std_npm_install_args(libexec) 67 | ``` 68 | 69 | This will install your Node module in npm's global module style with a custom prefix to `libexec`. All your modules' executables will be automatically resolved by npm into `libexec/bin` for you, which is not symlinked into Homebrew's prefix. We need to make sure these are installed. To do this we need to symlink all executables to `bin` with: 70 | 71 | ```ruby 72 | bin.install_symlink Dir["#{libexec}/bin/*"] 73 | ``` 74 | 75 | **Note:** Because of a required workaround for `npm@5` calling `npm pack` we currently don't support installing modules (from non-npm registry tarballs), which require a prepublish step (e.g. for transpiling sources). See [Homebrew/brew#2820](https://github.com/Homebrew/brew/pull/2820) for more information. 76 | 77 | ### Installing module dependencies locally with `local_npm_install_args` 78 | 79 | In your formula's `install` method, do any installation steps which need to be done before the `npm install` step and then `cd` to the top level of the included Node module. Then, use `system` with `Language::Node.local_npm_install_args` to invoke `npm install` like: 80 | 81 | ```ruby 82 | system "npm", "install", *Language::Node.local_npm_install_args 83 | ``` 84 | 85 | This will install all of your Node modules dependencies to your local build path. You can now continue with your build steps and take care of the installation into the Homebrew `prefix` on your own, following the [general Homebrew formula instructions](Formula-Cookbook.md). 86 | 87 | ## Example 88 | 89 | Installing a standard Node module based formula would look like this: 90 | 91 | ```ruby 92 | require "language/node" 93 | 94 | class Foo < Formula 95 | desc "..." 96 | homepage "..." 97 | url "https://registry.npmjs.org/foo/-/foo-1.4.2.tgz" 98 | sha256 "..." 99 | 100 | depends_on "node" 101 | # uncomment if there is a native addon inside the dependency tree 102 | # depends_on "python" => :build 103 | 104 | def install 105 | system "npm", "install", *Language::Node.std_npm_install_args(libexec) 106 | bin.install_symlink Dir["#{libexec}/bin/*"] 107 | end 108 | 109 | test do 110 | # add a meaningful test here 111 | end 112 | end 113 | ``` 114 | 115 | For examples using the `local_npm_install_args` method look at the [`elixirscript`](https://github.com/Homebrew/homebrew-core/blob/ec1e40d37e81af63122a354f0101c377f6a4e66d/Formula/elixirscript.rb) or [`kibana`](https://github.com/Homebrew/homebrew-core/blob/c6202f91a129e2f994d904f299a308cc6fbd58e5/Formula/kibana.rb) formulae. 116 | 117 | ## Tooling 118 | 119 | You can use [homebrew-npm-noob](https://github.com/zmwangx/homebrew-npm-noob) to automatically generate a formula like the example above for an npm package. 120 | -------------------------------------------------------------------------------- /src/Python-for-Formula-Authors.zh.md: -------------------------------------------------------------------------------- 1 | 2 | # 公式作者的Python 3 | 4 | 这个文档解释了如何在一个自制公式中成功地使用Python. 5 | 6 | 自制程序可以区分Python.**应用**和蟒蛇**图书馆**. 不同之处在于用户通常并不关心应用程序是用Python编写的;用户期望能够`import foo`安装应用程序后.应用实例如下[`ansible`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/ansible.rb)和[`jrnl`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/jrnl.rb). 7 | 8 | Python库是由其他Python模块导入的,它们通常是Python应用程序的依赖项.它们通常不受Taleal.App命令行的附带帮助.图书馆的例子[`py2cairo`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/py2cairo.rb)以及安装的绑定[`protobuf --with-python`](https://github.com/Homebrew/homebrew-core/blob/master/Formula/protobuf.rb). 9 | 10 | 绑定是允许Python代码与用其他语言实现的库或应用程序交互的库的特殊情况. 11 | 12 | HypBurw很乐意接受在Python中构建的应用程序,无论应用程序是否从PyPI中获得.自制程序一般不会接受可以正确安装的库.`pip install foo`. 绑定可以为提供它们的包安装,特别是如果PIP没有可用的等效功能. 13 | 14 | 应用程序应该无条件地捆绑它们的所有Python语言依赖项和库,并且应该安装任何不满意的依赖项;这些策略将在以下部分中深入讨论. 15 | 16 | ## 应用 17 | 18 | ### Python声明 19 | 20 | 需要Python 3的应用程序的公式**应该**声明无条件依赖`"python"`. 这些应用程序**必须**使用当前的自制软件Python 3.x公式. 21 | 22 | 与Python 2兼容的应用程序**应该**使用苹果提供的系统Python`/usr/bin`在提供Python 2.7的系统上.要做到这一点,声明: 23 | 24 | ```ruby 25 | depends_on "python@2" if MacOS.version <= :snow_leopard 26 | ``` 27 | 28 | 自从最近的OS版本以来,不需要显式的Python依赖性.`/usr/bin`总是在`PATH`对于自制配方,在豹子和老者身上`python`在里面`PATH`如果它至少是版本2.7,或者安装了自制软件的Python 2.7. 29 | 30 | ### 安装 31 | 32 | 应用程序应该安装到Python中.[虚拟现实](https://virtualenv.pypa.io/en/stable/)根植于环境`libexec`. 这防止了应用程序的Python模块污染系统站点包,反之亦然. 33 | 34 | 应用程序的所有Python模块依赖关系(以及它们的依赖性,递归地)都应该声明为`resource`S中的公式,并安装到VielalEnv,以及.每个依赖项都应该明确指定,请不要依赖`setup.py`或`pip`为执行自动依赖性解析,[这里描述的原因](Acceptable-Formulae.md#we-dont-like-install-scripts-that-download-things). 35 | 36 | 你可以使用[自酿诗人](https://pypi.python.org/pypi/homebrew-pypi-poet)帮助您编写资源节.要使用它,请设置ValueLeNV并安装包及其所有依赖项.然后,`pip install homebrew-pypi-poet`进入同一虚拟时代.运行`poet some_package`将生成必要的资源节.你可以这样做: 37 | 38 | ```sh 39 | # Install virtualenvwrapper 40 | brew install python 41 | python -m pip install virtualenvwrapper 42 | source $(brew --prefix)/bin/virtualenvwrapper.sh 43 | 44 | # Set up a temporary virtual environment 45 | mktmpenv 46 | 47 | # Install the package of interest as well as homebrew-pypi-poet 48 | pip install some_package homebrew-pypi-poet 49 | poet some_package 50 | 51 | # Destroy the temporary virtualenv you just created 52 | deactivate 53 | ``` 54 | 55 | HOBBRW提供了实例化和填充ValualEnVS的辅助方法.你可以通过放`include Language::Python::Virtualenv`在顶部`Formula`类定义. 56 | 57 | 对于大多数应用程序,您需要写的是: 58 | 59 | ```ruby 60 | def install 61 | virtualenv_install_with_resources 62 | end 63 | ``` 64 | 65 | 这与写作完全一样: 66 | 67 | ```ruby 68 | def install 69 | # Create a virtualenv in `libexec`. If your app needs Python 3, make sure that 70 | # `depends_on "python"` is declared, and use `virtualenv_create(libexec, "python3")`. 71 | venv = virtualenv_create(libexec) 72 | # Install all of the resources declared on the formula into the virtualenv. 73 | venv.pip_install resources 74 | # `pip_install_and_link` takes a look at the virtualenv's bin directory 75 | # before and after installing its argument. New scripts will be symlinked 76 | # into `bin`. `pip_install_and_link buildpath` will install the package 77 | # that the formula points to, because buildpath is the location where the 78 | # formula's tarball was unpacked. 79 | venv.pip_install_and_link buildpath 80 | end 81 | ``` 82 | 83 | ### 例子 84 | 85 | 安装依赖关系的公式将是这样的: 86 | 87 | ```ruby 88 | class Foo < Formula 89 | include Language::Python::Virtualenv 90 | 91 | url "..." 92 | 93 | resource "six" do 94 | url "https://pypi.python.org/packages/source/s/six/six-1.9.0.tar.gz" 95 | sha256 "e24052411fc4fbd1f672635537c3fc2330d9481b18c0317695b46259512c91d5" 96 | end 97 | 98 | resource "parsedatetime" do 99 | url "https://pypi.python.org/packages/source/p/parsedatetime/parsedatetime-1.4.tar.gz" 100 | sha256 "09bfcd8f3c239c75e77b3ff05d782ab2c1aed0892f250ce2adf948d4308fe9dc" 101 | end 102 | 103 | def install 104 | virtualenv_install_with_resources 105 | end 106 | end 107 | ``` 108 | 109 | 您还可以使用更冗长的形式,并要求安装特定的资源: 110 | 111 | ```ruby 112 | def install 113 | venv = virtualenv_create(libexec) 114 | %w[six parsedatetime].each do |r| 115 | venv.pip_install resource(r) 116 | end 117 | venv.pip_install_and_link buildpath 118 | end 119 | ``` 120 | 121 | 如果你需要为不同的资源做不同的事情. 122 | 123 | ## 绑定 124 | 125 | 若要为Python 3添加绑定,请添加`depends_on "python"`. 126 | 127 | 默认情况下,使用系统Python构建Python 2绑定(不要添加选项),并且它们应该可用于任何二进制兼容的Python.如果情况不是这样,那就是上游错误;[这里有一些解决它的建议](http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/). 128 | 129 | ### 依赖关系 130 | 131 | 绑定应遵循与库相同的Python模块依赖性建议;请参阅下面的更多内容. 132 | 133 | ### 安装绑定 134 | 135 | 如果绑定是通过调用`setup.py`做一些类似的事情: 136 | 137 | ```ruby 138 | cd "source/python" do 139 | system "python", *Language::Python.setup_install_args(prefix) 140 | end 141 | ``` 142 | 143 | 如果配置脚本需要`--with-python`标志,它通常不需要额外的帮助找到Python. 144 | 145 | 如果`configure`和`make`脚本不想安装到地窖中,有时你可以: 146 | 147 | 1. 呼叫`./configure --without-python`(或者类似的命名选项) 148 | 2. `cd`进入包含Python绑定的目录 149 | 3. 呼叫`setup.py`具有`system`和`Language::Python.setup_install_args`(如上所述) 150 | 151 | 有时我们不得不`inreplace`一`Makefile`使用Python绑定的前缀.(`inreplace`是HOBRUW的助手方法之一,它可以动态地编辑和编辑文本文件. 152 | 153 | ## 图书馆 154 | 155 | ### Python声明 156 | 157 | 为Python 3构建的库应该包括`depends_on "python"`Python 2.x库在安装时必须与系统Python或已生成的Python相对应. 158 | 159 | Python 2库不需要`depends_on "python@2"`声明将用系统Python构建,但仍然可以与任何其他Python 2.7一起使用.如果不是这样,它是上游错误;[这里有一些解决它的建议.](http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/). 160 | 161 | ### 安装 162 | 163 | 可以将库安装到`libexec`并添加到`sys.path`通过将.pthfile(命名为"HutBurw Fo.pth.")写入`prefix`站点包.这简化了随后的戏剧.`pip`意外地用于升级安装了Homebrew的包,并防止在Homebrew的站点包中累积过时的.pyc文件. 164 | 165 | 大多数公式目前只安装到`prefix`. 166 | 167 | ### 依赖关系 168 | 169 | 必须安装库的依赖关系,以便它们可以导入.为了最小化链接冲突的可能性,应将依赖项安装到`libexec/"vendor"`并添加到`sys.path`通过编写第二个.pthfile(命名为"HutBurw FoApple Reliest.PTH")到`prefix`站点包. 170 | 171 | ## 再下兔子洞 172 | 173 | 额外的评论,解释了为什么家庭自制做了一些事情. 174 | 175 | ### StupTooSvs. diStudisvs PIP 176 | 177 | ditudil是Python标准库中的一个模块,它为开发人员提供了一个基本的包管理API.SETUPoToes是分布在标准库之外扩展ditudil的模块.Python软件包提供了一种惯例.`setup.py`那叫`setup()`函数来自ditudil或StudioToots. 178 | 179 | 提供了`easy_install`命令,它是一个最终用户包管理工具,它从pypy-PythPodePype获取和安装包.`pip`是另一种更新的最终用户包管理工具,它也被提供在标准库之外.PIP植入`easy_install`PIP并没有取代StudioTooCAD模块的其他功能. 180 | 181 | ditudil和PIP使用一个"扁平"安装层次结构,它将模块安装为站点包下的单个文件.`easy_install`安装拉链鸡蛋代替现场包装. 182 | 183 | 分发(不与ditudil混淆)是StupToo工具的过时分支.Distlib是一个在标准库之外维护的包,它由pip用于一些低级包装操作,与大多数包装操作无关.`setup.py`用户. 184 | 185 | ### 运行`setup.py` 186 | 187 | 在一个公式需要交互的情况下`setup.py`而不是打电话`pip`家庭自制提供了一种帮手方法,`Language::Python.setup_install_args`为调用返回有用的参数`setup.py`. 你的公式应该使用这个,而不是调用`setup.py`明确地.语法是: 188 | 189 | ```ruby 190 | system "python", *Language::Python.setup_install_args(prefix) 191 | ``` 192 | 193 | 在哪里?`prefix`目的地前缀(通常是`libexec`或`prefix`) 194 | 195 | ### 是什么`--single-version-externally-managed`? 196 | 197 | `--single-version-externally-managed`("sVEM")只是一个StudioToo工具[论证`setup.py install`](https://setuptools.readthedocs.io/en/latest/setuptools.html?#install-run-easy-install-or-old-style-installation). SVEM的主要作用是使用ditudil来执行安装,而不是使用StudioToots.`easy_install`. 198 | 199 | `easy_install`做一些我们需要避免的事情: 200 | 201 | - 获取和安装依赖项 202 | - 升级依赖项`sys.path`就位 203 | - PPTH和SIT.PY文件,这些文件对我们不起作用,导致链接冲突. 204 | 205 | SETUPoToT需要使用SVEM`--record`提供一个文件列表,这些文件稍后可以用来卸载包.我们不需要或不想要这个,因为自制程序可以管理卸载,但是既然StuuToots需要它,我们就遵从.自制程序的约定是调用记录文件"安装.txt". 206 | 207 | 检测A是否`setup.py`使用`setup()`从StudioTo工具或ditudil很难,但是我们总是需要把这个标志传递给基于StudioToobe的脚本.`pip`我们面临同样的问题和力量`setup()`使用SETUPoToE版本加载一个垫片`setup.py`在做其他事情之前导入StudioToo工具.自从StUpToo工具猴子补丁ditudil取代它`setup`函数,这提供了一个单一的、一致的接口.我们借用了这个代码并使用它.`Language::Python.setup_install_args`. 208 | 209 | ### `--prefix` vs `--root` 210 | 211 | `setup.py`接受一些令人困惑的安装选项.正确的家庭自制开关`--prefix`,它自动设置`--install-foo`使用Shan-Posi-y值的选项系列. 212 | 213 | `--root` [使用](https://mail.python.org/pipermail/distutils-sig/2010-November/017099.html)当安装到不会成为文件最终安装位置的一部分的前缀中时,比如在构建.rpm或二进制发行版时.当使用`setup.py`基于SETUPoTo机,`--root`有副作用`--single-version-externally-managed`. 使用不安全`--root`空着`--prefix`因为`root`当字节编译模块时,从路径中删除. 214 | 215 | 使用可能是安全的.`--prefix`具有`--root=/`应该使用基于StudioTo工具或ditudil的`setup.py`但是有点难看. 216 | 217 | ### `pip`VS`setup.py` 218 | 219 | [PEP 453](http://legacy.python.org/dev/peps/pep-0453/#recommendations-for-downstream-distributors)向下游经销商(美国)推荐安装SDIST TARPOLL`pip`而不是通过调用`setup.py`直接.我们不这样做是因为苹果的Python分布不包括PIP,所以我们不能假定PIP是可用的.我们可以做一些聪明的事情来解决苹果的困境,但价值主张尚不明确. 220 | -------------------------------------------------------------------------------- /en.md: -------------------------------------------------------------------------------- 1 | # Homebrew 2 | [![GitHub release](https://img.shields.io/github/release/Homebrew/brew.svg)](https://github.com/Homebrew/brew/releases) 3 | 4 | Features, usage and installation instructions are [summarised on the homepage](https://brew.sh). Terminology (e.g. the difference between a Cellar, Tap, Cask and so forth) is [explained here](https://docs.brew.sh/Formula-Cookbook#homebrew-terminology). 5 | 6 | ## What Packages Are Available? 7 | 1. Type `brew search` for a list. 8 | 2. Or visit [formulae.brew.sh](https://formulae.brew.sh) to browse packages online. 9 | 3. Or use `brew search --desc ` to browse packages from the command line. 10 | 11 | ## More Documentation 12 | `brew help`, `man brew` or check [our documentation](https://docs.brew.sh/). 13 | 14 | ## Troubleshooting 15 | First, please run `brew update` and `brew doctor`. 16 | 17 | Second, read the [Troubleshooting Checklist](https://docs.brew.sh/Troubleshooting). 18 | 19 | **If you don't read these it will take us far longer to help you with your problem.** 20 | 21 | ## Contributing 22 | [![Travis](https://img.shields.io/travis/Homebrew/brew.svg)](https://travis-ci.org/Homebrew/brew) 23 | [![Codecov](https://img.shields.io/codecov/c/github/Homebrew/brew.svg)](https://codecov.io/gh/Homebrew/brew) 24 | 25 | We'd love you to contribute to Homebrew. First, please read our [Contribution Guide](CONTRIBUTING.md) and [Code of Conduct](CODE_OF_CONDUCT.md#code-of-conduct). 26 | 27 | We explicitly welcome contributions from people who have never contributed to open-source before: we were all beginners once! We can help build on a partially working pull request with the aim of getting it merged. We are also actively seeking to diversify our contributors and especially welcome contributions from women from all backgrounds and people of colour. 28 | 29 | A good starting point for contributing is running `brew audit --strict` with some of the packages you use (e.g. `brew audit --strict wget` if you use `wget`) and then read through the warnings, try to fix them until `brew audit --strict` shows no results and [submit a pull request](https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request). If no formulae you use have warnings you can run `brew audit --strict` without arguments to have it run on all packages and pick one. 30 | 31 | Alternatively, for something more substantial, check out one of the issues labeled `help wanted` in [Homebrew/brew](https://github.com/homebrew/brew/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) or [Homebrew/homebrew-core](https://github.com/homebrew/homebrew-core/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22). 32 | 33 | Good luck! 34 | 35 | ## Security 36 | Please report security issues to our [HackerOne](https://hackerone.com/homebrew/). 37 | 38 | ## Who Are You? 39 | Homebrew's lead maintainer is [Mike McQuaid](https://github.com/mikemcquaid). 40 | 41 | Homebrew's project leadership committee is [Mike McQuaid](https://github.com/mikemcquaid), [JCount](https://github.com/jcount), [Misty De Meo](https://github.com/mistydemeo) and [Markus Reiter](https://github.com/reitermarkus). 42 | 43 | Homebrew/brew's other current maintainers are [Claudia](https://github.com/claui), [Michka Popoff](https://github.com/imichka), [Shaun Jackman](https://github.com/sjackman), [Chongyu Zhu](https://github.com/lembacon), [commitay](https://github.com/commitay), [Vitor Galvao](https://github.com/vitorgalvao), [JCount](https://github.com/jcount), [Misty De Meo](https://github.com/mistydemeo), [Gautham Goli](https://github.com/GauthamGoli), [Markus Reiter](https://github.com/reitermarkus), [Steven Peters](https://github.com/scpeters), [Jonathan Chang](https://github.com/jonchang) and [William Woodruff](https://github.com/woodruffw). 44 | 45 | Homebrew/brew's Linux support (and Linuxbrew) maintainers are [Michka Popoff](https://github.com/imichka) and [Shaun Jackman](https://github.com/sjackman). 46 | 47 | Homebrew/homebrew-core's other current maintainers are [Claudia](https://github.com/claui), [Michka Popoff](https://github.com/imichka), [Shaun Jackman](https://github.com/sjackman), [Chongyu Zhu](https://github.com/lembacon), [commitay](https://github.com/commitay), [Izaak Beekman](https://github.com/zbeekman), [Sean Molenaar](https://github.com/SMillerDev), [Jan Viljanen](https://github.com/javian), [Viktor Szakats](https://github.com/vszakats), [FX Coudert](https://github.com/fxcoudert), [Steven Peters](https://github.com/scpeters), [JCount](https://github.com/jcount), [Misty De Meo](https://github.com/mistydemeo) and [Tom Schoonjans](https://github.com/tschoonj). 48 | 49 | Former maintainers with significant contributions include [Dominyk Tiller](https://github.com/DomT4), [Tim Smith](https://github.com/tdsmith), [Baptiste Fontaine](https://github.com/bfontaine), [Xu Cheng](https://github.com/xu-cheng), [Martin Afanasjew](https://github.com/UniqMartin), [Brett Koonce](https://github.com/asparagui), [Charlie Sharpsteen](https://github.com/Sharpie), [Jack Nagel](https://github.com/jacknagel), [Adam Vandenberg](https://github.com/adamv), [Andrew Janke](https://github.com/apjanke), [Alex Dunn](https://github.com/dunn), [neutric](https://github.com/neutric), [Tomasz Pajor](https://github.com/nijikon), [Uladzislau Shablinski](https://github.com/vladshablinsky), [Alyssa Ross](https://github.com/alyssais), [ilovezfs](https://github.com/ilovezfs) and Homebrew's creator: [Max Howell](https://github.com/mxcl). 50 | 51 | ## Community 52 | - [discourse.brew.sh (forum)](https://discourse.brew.sh) 53 | - [freenode.net\#machomebrew (IRC)](irc://irc.freenode.net/#machomebrew) 54 | - [@MacHomebrew (Twitter)](https://twitter.com/MacHomebrew) 55 | 56 | ## License 57 | Code is under the [BSD 2-clause "Simplified" License](LICENSE.txt). 58 | Documentation is under the [Creative Commons Attribution license](https://creativecommons.org/licenses/by/4.0/). 59 | 60 | ## Donations 61 | Homebrew is a non-profit project run entirely by unpaid volunteers. We need your funds to pay for software, hardware and hosting around continuous integration and future improvements to the project. Every donation will be spent on making Homebrew better for our users. 62 | 63 | Please consider a regular donation through Patreon: 64 | 65 | [![Donate with Patreon](https://img.shields.io/badge/patreon-donate-green.svg)](https://www.patreon.com/homebrew) 66 | 67 | Alternatively, if you'd rather make a one-off payment: 68 | 69 | - [Donate with PayPal](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=V6ZE57MJRYC8L) 70 | - Donate by USA $ check from a USA bank: 71 | - Make check payable to "Software Freedom Conservancy, Inc." and place "Directed donation: Homebrew" in the memo field. Checks should then be mailed to: 72 | - Software Freedom Conservancy, Inc. 73 | 137 Montague ST STE 380 74 | BROOKLYN, NY 11201 USA 75 | - Donate by wire transfer: contact accounting@sfconservancy.org for wire transfer details. 76 | 77 | Homebrew is a member of the [Software Freedom Conservancy](https://sfconservancy.org) which provides us with an ability to receive tax-deductible, Homebrew earmarked donations (and [many other services](https://sfconservancy.org/members/services/)). Software Freedom Conservancy, `Inc. is a 501(c)(3)` organization incorporated in New York, and donations made to it are fully tax-deductible to the extent permitted by law. 78 | 79 | ## Sponsors 80 | Our Xserve ESXi boxes for CI are hosted by [MacStadium](https://www.macstadium.com). 81 | 82 | [![Powered by MacStadium](https://cloud.githubusercontent.com/assets/125011/22776032/097557ac-eea6-11e6-8ba8-eff22dfd58f1.png)](https://www.macstadium.com) 83 | 84 | Our Jenkins CI installation is hosted by [DigitalOcean](https://m.do.co/c/7e39c35d5581). 85 | 86 | ![DigitalOcean](https://cloud.githubusercontent.com/assets/125011/26827038/4b7b5ade-4ab3-11e7-811b-fed3ab0e934d.png) 87 | 88 | Our physical hardware is hosted by [Commsworld](https://www.commsworld.com). 89 | 90 | ![Commsworld powered by Fluency](https://user-images.githubusercontent.com/125011/30822845-1716bc2c-a222-11e7-843e-ea7c7b6a1503.png) 91 | 92 | Our bottles (binary packages) are hosted by [Bintray](https://bintray.com/homebrew). 93 | 94 | [![Downloads by Bintray](https://bintray.com/docs/images/downloads_by_bintray_96.png)](https://bintray.com/homebrew) 95 | 96 | Secure password storage and syncing provided by [1Password for Teams](https://1password.com/teams/) by [AgileBits](https://agilebits.com). 97 | 98 | [![AgileBits](https://da36klfizjv29.cloudfront.net/assets/branding/agilebits-fcca96e9b8e815c5c48c6b3e98156cb5.png)](https://agilebits.com) 99 | 100 | Homebrew is a member of the [Software Freedom Conservancy](https://sfconservancy.org). 101 | 102 | [![Software Freedom Conservancy](https://sfconservancy.org/img/conservancy_64x64.png)](https://sfconservancy.org) 103 | -------------------------------------------------------------------------------- /src/FAQ.md: -------------------------------------------------------------------------------- 1 | # FAQ 2 | 3 | ## How do I update my local packages? 4 | First update the formulae and Homebrew itself: 5 | 6 | brew update 7 | 8 | You can now find out what is outdated with: 9 | 10 | brew outdated 11 | 12 | Upgrade everything with: 13 | 14 | brew upgrade 15 | 16 | Or upgrade a specific formula with: 17 | 18 | brew upgrade 19 | 20 | ## How do I stop certain formulae from being updated? 21 | To stop something from being updated/upgraded: 22 | 23 | brew pin 24 | 25 | To allow that formulae to update again: 26 | 27 | brew unpin 28 | 29 | Note that pinned, outdated formulae that are depended on by another formula need to be upgraded when required as we do not allow formulae to be built against non-latest versions. 30 | 31 | ## How do I uninstall old versions of a formula? 32 | By default, Homebrew does not uninstall old versions of a formula, so 33 | over time you will accumulate old versions. To remove them, simply use: 34 | 35 | brew cleanup 36 | 37 | or clean up everything at once: 38 | 39 | brew cleanup 40 | 41 | or to see what would be cleaned up: 42 | 43 | brew cleanup -n 44 | 45 | ## How do I uninstall Homebrew? 46 | To uninstall Homebrew, paste the command below in a terminal prompt. 47 | 48 | ```sh 49 | ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall)" 50 | ``` 51 | 52 | Download the [uninstall script](https://raw.githubusercontent.com/Homebrew/install/master/uninstall) 53 | and run `./uninstall --help` to view more uninstall options. 54 | 55 | ## How do I uninstall a formula? 56 | If you do not uninstall all of the versions that Homebrew has installed, 57 | Homebrew will continue to attempt to install the newest version it knows 58 | about when you run `brew upgrade`. This can be surprising. 59 | 60 | To remove a formula entirely, you may run `brew uninstall formula_name --force`. 61 | 62 | Be careful as this is a destructive operation. 63 | 64 | ## Where does stuff get downloaded? 65 | 66 | brew --cache 67 | 68 | Which is usually: `~/Library/Caches/Homebrew` 69 | 70 | ## My Mac `.app`s don’t find `/usr/local/bin` utilities! 71 | GUI apps on macOS don’t have `/usr/local/bin` in their `PATH` by 72 | default. If you’re on Mountain Lion or later, you can fix this by 73 | running `sudo launchctl config user path "/usr/local/bin:$PATH"` and 74 | then rebooting, as documented in `man launchctl`. Note that this sets 75 | the launchctl PATH for _all users_. For earlier versions of macOS, see 76 | [this page](https://developer.apple.com/legacy/library/qa/qa1067/_index.html). 77 | 78 | ## How do I contribute to Homebrew? 79 | Read [CONTRIBUTING.md](https://github.com/Homebrew/brew/blob/master/CONTRIBUTING.md). 80 | 81 | ## Why do you compile everything? 82 | Homebrew provides pre-compiled versions for many formulae. These 83 | pre-compiled versions are referred to as [bottles](Bottles.md) and are available 84 | at . 85 | 86 | If available, bottled binaries will be used by default except under the 87 | following conditions: 88 | 89 | * Options were passed to the install command, i.e. `brew install ` 90 | will use a bottled version of the formula, but 91 | `brew install --enable-bar` will trigger a source build. 92 | * The `--build-from-source` option is invoked. 93 | * The environment variable `HOMEBREW_BUILD_FROM_SOURCE` is set 94 | (intended for developers only). 95 | * The machine is not running a supported version of macOS as all 96 | bottled builds are generated only for supported macOS versions. 97 | * Homebrew is installed to a prefix other than the standard 98 | `/usr/local` (although some bottles support this). 99 | 100 | We aim to bottle everything. 101 | 102 | ## How do I get a formula from someone else’s branch? 103 | 104 | ```sh 105 | brew install hub 106 | brew update 107 | cd $(brew --repository) 108 | hub pull someone_else 109 | ``` 110 | 111 | Or: 112 | 113 | brew pull https://github.com/Homebrew/homebrew-core/pull/1234 114 | 115 | ## Why does Homebrew prefer I install to `/usr/local`? 116 | 117 | 1. **It’s easier**
`/usr/local/bin` is already in your 118 | `PATH`. 119 | 2. **It’s easier**
Tons of build scripts break if their dependencies 120 | aren’t in either `/usr` or `/usr/local`. We 121 | fix this for Homebrew formulae (although we don’t always test for 122 | it), but you’ll find that many RubyGems and Python setup scripts 123 | break which is something outside our control. 124 | 3. **It’s safe**
Apple has assigned this directory for non-system utilities. Which means 125 | there is no files in `/usr/local` by default, so there 126 | is no need to worry about messing up existing or system tools. 127 | 128 | **If you plan to install gems that depend on 129 | brews then save yourself a bunch of hassle and install to 130 | `/usr/local`!** 131 | 132 | It is not always straightforward to tell `gem` to look in non-standard directories for headers and libraries. If you choose `/usr/local`, many things will "just work". 133 | 134 | ## Why does Homebrew say sudo is bad? 135 | **tl;dr** Sudo is dangerous, and you installed TextMate.app without sudo 136 | anyway. 137 | 138 | Homebrew refuses to work using sudo. 139 | 140 | You should only ever sudo a tool you trust. Of course, you can trust Homebrew 141 | 😉 But do you trust the multi-megabyte Makefile that Homebrew runs? Developers 142 | often understand C++ far better than they understand make syntax. It’s too high 143 | a risk to sudo such stuff. It could modify (or upload) any files on your 144 | system.And indeed, we’ve seen some build scripts try to modify `/usr` even when 145 | the prefix was specified as something else entirely. 146 | 147 | We use the macOS sandbox to stop this but this doesn't work when run as the `root` user (which also has read and write access to almost everything on the system). 148 | 149 | Did you `chown root /Applications/TextMate.app`? Probably 150 | not. So is it that important to `chown root wget`? 151 | 152 | If you need to run Homebrew in a multi-user environment, consider 153 | creating a separate user account especially for use of Homebrew. 154 | 155 | ## Why isn’t a particular command documented? 156 | 157 | If it’s not in `man brew`, it’s probably an external command. These are documented [here](External-Commands.md). 158 | 159 | ## Why haven’t you pulled my pull request? 160 | If it’s been a while, bump it with a “bump” comment. Sometimes we miss requests and there are plenty of them. Maybe we were thinking on something. It will encourage consideration. In the meantime if you could rebase the pull request so that it can be cherry-picked more easily we will love you for a long time. 161 | 162 | ## Can I edit formulae myself? 163 | Yes! It’s easy! Just `brew edit `. You don’t have to submit modifications back to `homebrew/core`, just edit the formula as you personally need it and `brew install`. As a bonus `brew update` will merge your changes with upstream so you can still keep the formula up-to-date **with** your personal modifications! 164 | 165 | ## Can I make new formulae? 166 | Yes! It’s easy! Just `brew create URL`. Homebrew will then open the formula in 167 | `EDITOR` so you can edit it, but it probably already installs; try it: `brew 168 | install `. If you encounter any issues, run the command with the 169 | `--debug` switch like so: `brew install --debug `, which drops you 170 | into a debugging shell. 171 | 172 | If you want your new formula to be part of `homebrew/core` or want 173 | to learn more about writing formulae, then please read the [Formula Cookbook](Formula-Cookbook.md). 174 | 175 | ## Can I install my own stuff to `/usr/local`? 176 | Yes, `brew` is designed to not get in your way so you can use it how you 177 | like. 178 | 179 | Install your own stuff, but be aware that if you install common 180 | libraries like libexpat yourself, it may cause trouble when trying to 181 | build certain Homebrew formula. As a result `brew doctor` will warn you 182 | about this. 183 | 184 | Thus it’s probably better to install your own stuff to the Cellar and 185 | then `brew link` it. Like so: 186 | 187 | ```sh 188 | $ cd foo-0.1 189 | $ brew diy 190 | ./configure --prefix=/usr/local/Cellar/foo/0.1 191 | $ ./configure --prefix=/usr/local/Cellar/foo/0.1 192 | [snip] 193 | $ make && make install 194 | $ brew link foo 195 | Linking /usr/local/Cellar/foo/0.1… 17 symlinks created 196 | ``` 197 | 198 | ## Why was a formula deleted? 199 | Use `brew log ` to find out! Likely because it had unresolved issues or 200 | our analytics identified it was not widely used. 201 | 202 | ## Homebrew is a poor name, it's too generic, why was it chosen? 203 | @mxcl was too concerned with the beer theme and didn’t consider that the 204 | project may actually prove popular. By the time he realised it was, it was too 205 | late. However, today, the first Google hit for “homebrew” is not beer 206 | related ;-) 207 | 208 | ## What does "keg-only" mean? 209 | It means the formula is installed only into the Cellar; it is not linked 210 | into `/usr/local`. This means most tools will not find it. We don’t do 211 | this for stupid reasons. You can still link in the formula if you need 212 | to with `brew link`. 213 | 214 | ## How can I specify different configure arguments for a formula? 215 | `brew edit ` and edit the formula. Currently there is no 216 | other way to do this. 217 | 218 | ## Is there a glossary of terms around? 219 | All your terminology needs can be [found here](Formula-Cookbook.md#homebrew-terminology). 220 | --------------------------------------------------------------------------------