无论你在 Python 编程过程中处于什么阶段，这些 Python 热门文章将会对你有很大帮助。

2019 年是 Python 的好年景。根据 GitHub 和 Stack Overflow 的受欢迎资源程度来看，它正在成为全球第二大流行语言。（LCTT 译注：原文发表于 2019 年底，但是这里提及的文章并没有过时。）

“在我们的调查中，Python 作为增长最快的程序设计语言，在程序设计语言中排名再次上升，今年排在 Java 之前，成为第二大最受欢迎的程序设计语言（仅次于 Rust ）。”

— Stack Overflow Insights

同样，Python 的读者人数呈跳跃式激增。以下是按主题分组的 2019 年以来最热门的 Python 文章，供你仔细阅读。

为什么选择 Python ？

在众多的程序设计语言中，是什么使 Python 成为首选呢？从文章的阅读量来看，那就是因为它的灵活性。正如 Jigyasa Grover 解释的那样，Python 开发人员可以使用 多种范例，包括 Seth Kenlon 教程所展示的流行的 面向对象程序设计。

如果你是 Python 的长期用户，并且正在寻找 Python 为什么是完美的程序设计语言的高级例子，那么可以看 Moshe Zadka 的 喜欢 Python 的 5 大理由。如果这还不够的话，你也可以使用功能强大的工具来尝试，无需编写大量代码，例如 Parul Pandey 关于 图像处理 的教程。

配置 Python

随着 Python 的受欢迎程度不断提高，使用它的人越来越多。这些新手中的许多人都是在 Mac 操作系统上进行的，并且正在使用 Moshe 和我写的 Python3 配置向导。

安装 Python 之后，接下来就是决定利用什么工具编写代码。关于文本编辑器和集成开发环境（IDE），有很多选择，但是读者似乎更喜欢图形界面，在有关该主题的文章中，Stephan Avenwedde 的关于 Pythonic 和我关于 JupyterLab 的文章的读者最多。

在对程序设计语言充满信心的途径上，开发人员将不得不面对众多选择，来管理程序设计语言的版本和项目依赖。幸运的是，László Kiss Kollár 的文章 Python 包管理 让其变得更加容易。

当你准备好配置一个具有所有功能的 IDE，以最大限度地利用这门语言时，请一定尝试一下 linter Black，如 Moshe 说的，保持代码的清洁。

小结

无论你处在 Python 程序设计的哪个阶段，这些热门 Python 文章都将为你提供帮助。如果没有至少一次对测试重要性的认可，我无法对此进行总结，为此，Moshe 提供了另一篇 关于 tox 的好文章。

via: https://opensource.com/article/19/12/learn-python

作者：Matthew Broberg 选题：lujun9972 译者：stevenzdg988 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

想学习 Git？看看这个最重要的术语和命令的快速总结。

如今，对于任何希望跟踪他们的变化的人来说，版本控制是一个重要的工具。它对程序员、系统管理员和 网站可靠性工程师 site reliability engineers （SRE）都特别有用。确保可以从错误中恢复到已知的良好状态是一个巨大的胜利，比以前给复制的文件添加 .old 后缀的策略更友好。

但学习 Git 这件事往往被告诉大家“投身开源”的好心同行们过度简化了。在你还不明白之前，就有人要你给一个从 上游 upstream 变基 rebase 的 拉取请求 pull request （PR）或 合并请求 merge request （MR），然后他们才能从你的 远程版本库 remote 合并 —— 而且一定会删除 合并提交 merge commits 。无论你想给开源项目做出什么好的贡献，当你看到这些你不认识的单词时，都会觉得难以融入。

• 下载 我们的 Git 速查表。

如果你有一两个月的时间和足够的好奇心，Git SCM 是你需要学习所有术语的权威来源。但如果你正在寻找来自实践的总结，请继续阅读。

提交就是提醒

对我来说，Git 最难理解的部分是 Git 最简单的概念：一个 提交 commit 就是一个内容的集合，包括一个关于描述的信息，以及之前的提交。没有固有的代码发布策略，甚至没有内置的明确建议。这个内容甚至不一定是代码 —— 可以是任何你想添加到版本库的东西。 提交消息 commit message 会对这些内容进行注释。

我喜欢把提交信息看作是给未来的自己的礼物：它可能会提到你编辑的文件，但更重要的是它提醒你修改这些文件的意图。添加更多关于你为什么编辑这些内容的信息，可以帮助任何使用你的版本库的人，即使那个人是你。

origin/master 在哪里？

要知道自己在 Git 项目中的位置，首先把它想成一棵树。所有 Git 项目都有一个根目录，类似于文件系统的根目录。所有的提交都是这个根目录下的分支。这样一来，分支只是一个提交的指针。按照惯例，master 是根目录下默认的分支名称。（LCTT 译注：世界变得快，原文发表于 2019 年，而现在有些地方开始用 main 替代这个名字。）

由于 Git 是一个分布式的版本控制系统，同一个代码库分布在多个地方，所以人们经常用 版本库 repository 这个词来表示同一个项目的所有副本。（LCTT 译注：“repository” 英文原意是仓库、存储库，在计算机环境中，常用于版本控制、软件分发等方面，有时候会统一译作“仓库”、“存储库”。但我们认为，应该根据不同语境采用更有指向性的译法。在 Git 等版本控制语境中，采用“版本库”；在软件分发方面，采用“软件库”；其它泛指或不确定的语境中，可采用“仓库”、“存储库”译法。）有 本地版本库 local repository ，这是你编辑代码的地方（稍后会有更多的介绍），还有 远程版本库 remote repository ，这是你完成后想把代码发送到的地方。远程版本库可以在任何地方，甚至在你的本地版本库所在的同一台计算机上，但它们通常托管在 GitLab 或 GitHub 等版本库服务上。

我在哪里？

虽然不是官方的卖点，但迷路也是 Git 仓库的“乐趣”之一。你可以通过这套可靠的命令来找到自己的方向：

• git branch —— 找到你所在的分支。
• git log —— 查看你正在进行的提交。
• git status —— 查看自上次提交以来你所做的编辑。
• git remote —— 查看你正在跟踪的远程仓库。

用这些命令来定位自己的方向，当你被卡住的时候，会让你有一种方向感。

我是否已将我的提交暂存或缓存起来？

你电脑上的代码俗称为你的 工作空间 workspace 。但不是很明显的是，当你在 Git 仓库中时，你还有两个（是的，两个！）其他位置： 索引 index 和 暂存 stash 。当你写了一些内容，然后添加时，你是把它添加到索引中，也就是准备提交的缓存内容。有的时候，你的索引中的文件还没有准备好提交，但你想查看另一个分支。这时，暂存就派上用场了。你可以使用 git stash 将索引了但尚未提交的文件存储到暂存区中。当你准备好取回文件时，运行 git stash pop 将更改带回索引中。

下面是一些你需要使用暂存区和缓存区的命令：

• git diff ...origin/master —— 显示最近的本地提交和远程的 origin 版本库的 master 分支之间的差异。
• git diff --cached —— 显示最近的本地提交与添加到本地索引的内容之间的任何差异。
• git stash —— 将索引的（已添加但未提交的）文件放在暂存区堆栈中。
• git stash list —— 显示暂存区堆栈中的变化。
• git stash pop —— 将最近的变化从暂存库中删除。

无头骑士

Git 里面有各种比喻。当我想到 HEAD 是哪里的时候，我就会想到火车线路。如果你最终处于 脱离的 HEAD detached HEAD 模式，就意味着你已经脱离了这个隐喻的轨道。

HEAD 是指向当前签出分支中最近一次提交的指针。默认的“签出checkout”是指当你创建一个 Git 仓库并进入到 master 分支的时候。每次创建或修改到另一个分支时，你都会切换到该分支行。如果你在当前分支的某处进行 git checkout <commit>，HEAD 就会移动到该提交。如果没有提交历史记录将你的当前提交连接到已签出的提交，那么你将处于脱离的 HEAD 状态。如果你找不到 HEAD 的位置，你可以随时用 git reset --hard origin/master 来删除修改，回到已知状态。警告：这将删除你上次推送到 master 后的任何改动。

你是上游还是下游？

你的项目的本地副本被认为是你的本地版本库，它可能有也可能没有远程版本库 —— 远程版本库的副本是用于协作或保存的。也可能还有一个 上游 upstream 版本库，在那里，项目的第三个副本由不同的贡献者托管和维护。

例如，假设我想为 Kubernetes 做贡献。我会首先将 kubernetes/kubernetes 项目 复刻 fork 到我的账户下 mbbroberg/kubernetes。然后我会将我的项目克隆到我的本地工作区。在这种情况下，我的本地克隆是我的本地仓库，mbbroberg/kubernetes 是我的远程仓库，kubernetes/kubernetes 是上游。

合并的隐喻

当你深入 Git 分支时，根系统的视觉效果就会和火车轨道的形象合二为一。分支通常被用作开发一个新功能的方式，最终你想把它 合并 merge 到主分支中。当这样做时，Git 会按顺序保留共同的提交历史，然后将你的分支的新提交追加到历史中。这个过程有一大堆的细节：是否 变基 rebase ，是否添加一个 合并提交 merge commit ，Brent Laster 在《如何在 Git 中重置、恢复和返回之前的状态》中会有更详细的探讨。

我想现在就去 Git

要掌握 Git 命令的世界，有大量的术语和需要探索的地方。我希望这篇关于日常使用术语的第一人称探索能帮助你适应这一切。如果你觉得自己被卡住了或者遇到了挫折，欢迎在 Twitter @mbbroberg 上联系我。

回顾

• 提交 Commit —— 将当前索引的内容保存在一个新的提交中，并附上用户描述更改的日志信息。
• 分支 Branch —— 指向一个提交的指针。
• master —— 第一个分支的默认名称。
• HEAD —— 指向当前分支上最近一次提交的指针。
• 合并 Merge —— 合并两个或多个提交的历史。
• 工作空间 Workspace —— Git 仓库本地副本的通俗名称。
• 工作树 Working tree —— 工作区中的当前分支；任何时候你都可以在 git status 的输出中看到这个。
• 缓存 Cache —— 用于临时存储未提交的变更的空间。
• 索引 Index —— 变更提交前存储其变化的缓存。
• 跟踪和未跟踪的文件 —— 没有被索引缓存的文件或尚未加入其中的文件。
• 暂存 Stash —— 另一个缓存，作为一个堆栈，在这里可以存储更改而不需要提交它们。
• origin —— 远程版本库的默认名称。
• 本地仓库 Local repository —— 也就是你在工作站上保存 Git 仓库副本的地方。
• 远程存储库 Remote repository —— Git 存储库的第二副本，你可以在这里推送变更以便协作或备份。
• 上游存储库 Upstream repository —— 你跟踪的远程存储库的通俗说法。
• 拉取请求 Pull request —— 这是 GitHub 的专用术语，用于让其他人知道你推送到仓库分支的变化。
• 合并请求 Merge request —— 这是 GitLab 的专用术语，用于让其他人知道你推送到仓库分支的变化。
• origin/master —— 远程版本库及其主要分支的默认名称。

后记：双关语是 Git 最好的部分之一，愿你喜欢。

via: https://opensource.com/article/19/2/git-terminology

作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

不管你是想要更舒服地从 Mac 搬到 Linux，还是不满意常规的 Linux 包管理器，都可以试试 Homebrew。

Homebrew 项目最初是为了给 Mac 用户提供一个非官方的 Linux 式的包管理器。用户很快就爱上了它友好的界面以及帮助性的提示，而且，它已经被移植到 Linux 系统 —— 这看起来像是一个奇怪的命运转折。

一开始，有两个分开的项目分别针对 macOS 和 Linux （Homebrew 与 Linuxbrew），但是现在是由 Homebrew 核心管理着这两个操作系统。由于我正 从 Mac 切换到 Linux，所以一直在研究我在 macOS 最常用的开源软件在 Linux 表现如何，最终，我很高兴地发现 Homebrew 对 Linux 的支持太赞了！

为什么要在 Linux 使用 Homebrew 呢？

长期使用 Linux 的用户对 Homebrew 的第一反应是：“为什么不直接使用……呢”，省略号代表他们喜欢的某个 Linux 包管理器。基于 Debian 的系统早就有了 apt，基于 Fedora 的系统则有 dnf 和 yum，并且像 Flatpak 跟 AppImage 这样的项目，在两种系统上都能流畅运行。我花了不少时间尝试这些技术，不得不说，它们都有其强大之处。

那我为什么还要 坚持使用 Homebrew 呢？首先，我对它非常熟悉。在为我过去使用的专有软件寻找开源替代品的过程中，我已经学会了许多使用方法，而保持一些熟悉的东西，比如 Homebrew，可以让我专注于一次学习一件事情，而不是被不同系统间的差异搞垮。

此外，我没有看到哪一个包管理器像 Homebrew 一样，对用户如此友好。正如默认的帮助命令一样，命令井然有序：

$ brew -h
Example usage:
  brew search [TEXT|/REGEX/]
  brew info [FORMULA...]
  brew install FORMULA...
  brew update
  brew upgrade [FORMULA...]
  brew uninstall FORMULA...
  brew list [FORMULA...]

Troubleshooting:
  brew config
  brew doctor
  brew install --verbose --debug FORMULA

Contributing:
  brew create [URL [--no-fetch]]
  brew edit [FORMULA...]

Further help:
  brew commands
  brew help [COMMAND]
  man brew
  <https://docs.brew.sh>

过于简短的输出可能会被误解为它功能局限，但是你简单看看每一个子命令，都有很丰富的功能。虽然上面的列表只有短短 23 行，但对高级用户来说，光是子命令 install 就包含整整 79 行的帮助信息：

$ brew --help | wc -l
23
$ brew install --help | wc -l
79

它可以选择忽略或者安装依赖关系，也可以选择用源代码编译以及用什么编译器来编译某个确切的上游 Git 提交，或者选择应用的官方 “灌装” 版。总而言之，Homebrew 即适合新手，也同样能满足老鸟。

开始在 Linux 使用 Homebrew

如果你想要试着使用 Homebrew，可以用这个单行脚本在 Mac 或者 Linux 上进行安装：

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

这条命令会立即开始安装 Homebrew。如果你比较谨慎，可以使用 curl 将该文件下载到本地，检查完毕之后再运行。

$ curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh --output homebrew_installer.sh
$ more homebrew_installer.sh # 审核该脚本，直到你觉得没问题了
$ bash homebrew_installer.sh

对 Linux 的安装步骤还包括如何配置点文件，对于 Debian 系统来说是 ~/.profile，对于 Fedora 系统是 ~/.bash_profile。

$ test -d /home/linuxbrew/.linuxbrew && eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv)
$ test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile
$ echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile

为了确认已经安装好，Homebrew 团队提供一个空的 hello “秘方” 供测试：

$ brew install hello
==> Downloading https://linuxbrew.bintray.com/bottles/hello-2.10.x86_64_linux.bottle.tar.gz
######################################################################## 100.0%
==> Pouring hello-2.10.x86_64_linux.bottle.tar.gz
?  /home/linuxbrew/.linuxbrew/Cellar/hello/2.10: 52 files, 595.6KB

看起来安装毫无问题，让我来试试更多操作。

命令行工具 Brew

Homebrew 宣称自己是一款默认只 “安装你需要而 [Linux] 没有的东西”的应用程序。

你可以用 brew 命令安装任何打包在 Homebrew 中的命令行软件。这些包的定义文件叫做 “ 秘方 formula ”，而且它们通过“ 瓶子 bottle ”来编译并分享。在 Homebrew 的世界里，还有许多 “啤酒方面” 的术语，但这个包管理器主要目的是让软件便于使用。

都有些什么样的软件呢？对我这样的技术玩家（既然你已经在读这篇文章，估计你也是）来说最方便的东西。例如，便利的 tree 命令，可以展示目录结构，或者 pyenv，我用它来 在 Mac 管理不同版本 Python。

你可以用 search 命令查看所有可以安装的“秘方”，在后面加上 wc 命令看看一共有多少：

# -l 选项统计行数
$ brew search | wc -l
    5087

迄今为止，一共有 5000 多个 “秘方”，这囊括了很多软件。需要注意的是：并非所有 “秘方” 都能在 Linux 运行。在 brew search --help 输出中有一节提到可以按软件运行的操作系统来筛选软件。它会在浏览器打开用于每个操作系统的软件仓库。我运行的是 Fedora，所以我会用它来试一试：

$ brew search --fedora tree

浏览器打开了网址 https://apps.fedoraproject.org/packages/s/tree，向我展示了所有 Fedora 的可用选项。你也可以通过其它方法进行浏览。“秘方” 被集中整理到由操作系统划分的核心仓库当中（Mac 在 Homebrew Core，Linux 在 Linux Core）。同样也可以通过 Homebrew API 在网页显示。

即使有这些选择，我还是通过其它用户的推荐找到很多新工具。我列出一些我最喜欢的工具，你可以在里面找点灵感：

• pyenv、rbenv 和 nodenv 用来管理（相应的） Python、Ruby 和 Node.js 版本
• imagemagick 用于脚本化编辑图片
• pandoc 用于脚本化转换文档格式（我通常将 .docx 文件转成 .md 或者 .html）
• hub 为 GitHub 用户提供 更好的 Git 体验
• tldr 展示了命令工具的使用范例

想要深入了解 Homebrew，可以去 trldr 页面 看看，比起应用的 man 页面，它要友好得多。使用 search 命令确认你可以安装：

$ brew search tldr
==> Formulae
tldr ✔

太好了！对勾说明你可以安装。那么继续吧：

$ brew install tldr
==> Downloading https://linuxbrew.bintray.com/bottles/tldr-1.3.0_2.x86_64_linux.bottle.1.tar.gz
######################################################################## 100.0%
==> Pouring tldr-1.3.0_2.x86_64_linux.bottle.1.tar.gz
?  /home/linuxbrew/.linuxbrew/Cellar/tldr/1.3.0_2: 6 files, 63.2KB

Homebrew 提供了编译好的二进制文件，所以你不必在本地机器上从源码编译。这能节省很多时间，也不用听 CPU 风扇的噪声。我很欣赏 Homebrew 的另外一点是，你不完全理解每一个选项的含义也不会影响正常使用。若你想自己编译，可以在 brew install 命令后面加上 -s 或者 --build-from-source 标识，这样就能从源码编译 “秘方”（即便已经有一个 “瓶子” 存在）。

同样，软件底层的复杂性也很有意思。使用 info 可以查看 tldr 软件的依赖管理，“秘方” 的源代码存放在磁盘上的何处，甚至还能查看公开分析。

$ brew info tldr
tldr: stable 1.3.0 (bottled), HEAD
Simplified and community-driven man pages
https://tldr.sh/
Conflicts with:
  tealdeer (because both install `tldr` binaries)
/home/linuxbrew/.linuxbrew/Cellar/tldr/1.3.0_2 (6 files, 63.2KB) *
  Poured from bottle on 2020-06-08 at 15:56:15
From: https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/tldr.rb
==> Dependencies
Build: pkg-config ✔
Required: libzip ✔, curl ✔
==> Options
--HEAD
        Install HEAD version
==> Analytics
install: 197 (30 days), 647 (90 days), 1,546 (365 days)
install-on-request: 197 (30 days), 646 (90 days), 1,546 (365 days)
build-error: 0 (30 days)

从 Mac 到 Linux 的一点不足

在 macOS，Homebrew 的 cask（“酒桶”）子命令可以让用户使用命令行安装、管理整个应用软件。不幸的是，cask还不能在任何 Linux 发行版上使用。我在安装一个开源工具时发现了这点：

$ brew cask install tusk
Error: Installing casks is supported only on macOS

我在 论坛上 问了一下，很快得到其他用户的反馈。总结一下，方案如下：

• 复刻 Homebrew 项目，构建这个特性，然后像别人展示其价值
• 给该软件写一个 “秘方”，然后从源代码编译
• 为该软件创建一个第三方仓库

最后一个是我最感兴趣的。Homebrew 通过 创建并维护 “ 水龙头 tap ” （另一个受啤酒影响的术语）管理第三方仓库。随着你对系统越来越熟悉，并想加入生态系统， “水龙头” 是值得研究的。

备份 Homebrew 的安装记录

我最中意的 Homebrew 特性之一就是你可以像其它任何 用版本控制工具来备份点文件 一样备份你的安装记录。为了实现这个目的，Homebrew 提供 bundle（“捆扎”）子命令，它可以控制一个叫 dump（“倾倒”）的子命令生成一个 Brewfile。这个文件包含你目前所有安装的工具列表，可以重复使用。进入你想使用的目录然后运行命令，它会根据你所安装的软件生成 Brewfile：

$ cd ~/Development/dotfiles # This is my dotfile folder
$ brew bundle dump
$ ls Brewfile
Brewfile

当我换了一台机器，想要安装一样的软件时，进入含有 Brewfile 的文件夹，然后重新安装：

$ ls Brewfile
Brewfile
$ brew bundle

它会在我的新机器上安装所有列出的 “秘方”。

在 Mac 和 Linux 同时管理 Brewfile

Brewfile 非常适合备份你目前的安装记录，但是如果某些在 Mac 上运行的软件无法运行在 Linux 呢？或者刚好相反？我发现不管是 Mac 还是 Linux，如果软件无法在当前操作系统运行，Homebrew 会优雅地忽略那一行。如果它遇到不兼容的请求（比如使用 brew 在 Linux 安装 “ 酒桶 cask ” 时），它会选择跳过，继续安装过程：

$ brew bundle --file=Brewfile.example

Skipping cask licecap (on Linux)
Skipping cask macdown (on Linux)
Installing fish
Homebrew Bundle complete! 1 Brewfile dependency now installed.

为了保持配置文件的简洁，我在两个操作系统上使用同一份 Brewfile，因为它只安装与操作系统相关的版本，所以我一直没有遇到任何问题。

使用 Homebrew 管理软件包

Homebrew 已经成了我必备的命令行工具，由于我很熟悉它，所以在 Linux 上的体验也充满乐趣。Homebrew 让我的工具井然有序，并且时刻保持更新，我愈发欣赏它在实用性与功能上找到的平衡点。我更喜欢将软件包管理的细节保持在用户需要了解的最小程度，大多数人都会从中受益。如果你已经很熟悉 Linux 包管理器了，Homebrew 可能会让你觉得很基础，但稍微深入一点看，就会发现它的高级选项远远超过本文的内容。

对 Linux 用户来说，他们有很多包管理器可以选择。如果你来自 MacOS，Homebrew 会让你宾至如归。

via: https://opensource.com/article/20/6/homebrew-linux

作者：Matthew Broberg 选题：lujun9972 译者：nophDog 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Homebrew 软件包管理器可以让你轻松地在 Mac 上安装和更新应用程序和实用程序。

在我追求“万物自动化”的过程中，我一直坚持走在用代码来管理我的 Mac 笔记本电脑的路上。与其用鼠标或触控板手动管理我的应用程序和实用程序，我更喜欢使用软件包管理软件来安装、更新和删除不需要的软件。

这对 Mac 用户来说是个挑战。Mac 的操作系统 macOS 始终落后于 Linux 的一个地方就是在包管理方面。Mac 用户没有默认的软件包管理器，而 Linux 用户则有很多选择 —— 从熟悉的 yum 和 apt 到现代的 Flatpak。但 Mac 呢？

这就是 Homebrew 的作用。Homebrew（自酿）填补了 MacOS 事实上的软件包管理器的空白（它也是 Linux 上的又一个可选的包管理器）。它为任何熟悉命令行的人提供了令人难以置信的流畅而直接的体验，如果你是新手，它是学习命令行的好方法。

（LCTT 译注：Homebrew 系统中采用了大量针对自酿啤酒相关的比喻，大家在使用过程中会发现这些有趣的形容。）

如果你在 Mac 上还没有 Homebrew，你可以这样来安装：

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

该命令将执行 Homebrew 团队提供的安装程序脚本。如果你喜欢谨慎一点，可以 curl 下来这个文件，审核后再手动运行。

$ curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh --output homebrew_installer.sh
$ more homebrew_installer.sh # 审核该脚本，直到你觉得没问题了
$ bash homebrew_installer.sh

使用“酿造”来管理你的命令行实用程序

Homebrew 号称它“可以安装苹果（或你的 Linux 系统）默认没有安装的必需之物”。安装是通过 brew（酿造）命令进行的，它使我们能够访问成千上万的命令行实用程序，但不是更复杂的应用程序。

对于我们这些搞技术的人来说，符合“必需之物”类别的实用工具包括显示目录结构的方便的 tree 命令和我用来 管理多个 Python 版本 的 pyenv。

你可以用 search 子命令看到 Homebrew 中所有的“ 秘方 formula ”，我用 wc 命令显示有多少个“秘方”。

# -l 统计行数
$ brew search | wc -l
    5013

有 5000 多个“秘方”，这是一个不可思议的软件数量。所以，在搜索那个庞大的清单之前，最好先对自己想要的东西有个概念。值得庆幸的是，浏览起来很方便。“秘方”被编入并集中存储到核心库中，核心库按操作系统划分（Mac 在 Homebrew Core，Linux 在 Linux Core）。它们也可以通过 Homebrew API 和网站列出。

口碑是另一个寻找实用工具的好方法。考虑到这一点，如果你正在寻找灵感，这里有一些我的最爱：

• pyenv、rbenv 和 nodenv 分别用于管理 Python、Ruby 和 Node.js 的版本
• imagemagick 用于可脚本化的图像编辑
• pandoc 用于可脚本化的文件转换（我经常从 .docx 切换到 .md 或 .html）
• hub 为 GitHub 用户提供了更好的 Git 体验。
• tldr 提供了解如何使用命令行工具的例子

举个例子，看看 tldr 页面，这是一个用户友好的替代方式，可以滚动浏览应用程序的手册页。你可以通过再次运行 search 来确认它是否可用：

$ brew search tldr
==> Formulae
tldr ✔

成功了！这个对勾让你知道它是可用的。现在你可以安装它了：

$ brew install tldr
==> Downloading https://homebrew.bintray.com/bottles/tldr-1.3.0_2.catalina.bottle.tar.gz
Already downloaded: /Users/mbbroberg/Library/Caches/Homebrew/downloads/901bc14594a9283e9ab20aec942dc5a9a2befb7e96e1b0fcccb4e3257918813c--tldr-1.3.0_2.catalina.bottle.tar.gz
==> Installing tldr
==> Pouring tldr-1.3.0_2.catalina.bottle.tar.gz
?  /usr/local/Cellar/tldr/1.3.0_2: 6 files, 35.5KB

值得庆幸的是，Homebrew 预先构建了二进制文件，所以你不必在本地机器上从源代码构建。这样就节省了很多时间，并免除了 CPU 风扇的噪音。我对 Homebrew 赞赏的另一件事是，你可以在不完全了解其含义的情况下欣赏此功能。

但如果你喜欢，看看复杂的东西也是很有趣的。对 tldr 运行 info 子命令，你可以看到所有的依赖管理、源代码，甚至公共分析。

$ brew info tldr
tldr: stable 1.3.0 (bottled), HEAD
Simplified and community-driven man pages
https://tldr.sh/
Conflicts with:
  tealdeer (because both install `tldr` binaries)
/usr/local/Cellar/tldr/1.3.0_2 (6 files, 35.5KB) *
  Poured from bottle on 2020-05-20 at 15:12:12
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/tldr.rb
==> Dependencies
Build: pkg-config ✔
Required: libzip ✔
==> Options
--HEAD
        Install HEAD version
==> Analytics
install: 2,811 (30 days), 7,875 (90 days), 27,105 (365 days)
install-on-request: 2,806 (30 days), 7,860 (90 days), 27,080 (365 days)
build-error: 0 (30 days)

最后，和其他优秀的软件包管理器一样，Homebrew 的 brew uninstall 子命令可用于快速清理和删除未使用的实用程序。

用“酒桶”管理你的应用程序

命令行实用程序是一匹孤狼，但完整的应用程序呢？Homebrew 保持了其标准命令的简单性，只通过其默认的 brew 命令行界面安装单文件应用。而应用程序不符合这种结构。它们的目录层次比较复杂，比单一的二进制要复杂得多。

幸运的是，Mac 上的 Homebrew 包含了一个名为 cask（酒桶）的子命令，用于处理更复杂的多目录结构。特别好的是，cask 使用了与标准 brew 命令类似的命令结构，所以你可以使用类似的 search、install 和 info 子命令：

brew search --cask | wc -l
    4772

哇，有近 5000 个应用程序，在 Homebrew 的网站上浏览更方便。

我将用我新喜欢的一款应用来引导你完成 cask。Meld（我在 Opensource.com 上读到的）。这是一个功能丰富的编辑器，可以帮助管理合并冲突。在它的网站上有下载的链接，我可以运行安装程序，并将其拖放到我的应用程序文件夹中。但我不想再这样做了，我用的是 Homebrew。

首先，我可以通过稍微不同的语法确认它可以使用：

$ brew search --casks meld
==> Casks
meld

然后我使用 cask 子命令来安装它：

$ brew cask install meld
==> Downloading https://github.com/yousseb/meld/releases/download/osx-19/meldmerge.dmg
==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/28624006/66cb25
######################################################################## 100.0%
==> Verifying SHA-256 checksum for Cask 'meld'.
==> Installing Cask meld
==> Moving App 'Meld.app' to '/Applications/Meld.app'.
==> Linking Binary 'meld.wrapper.sh' to '/usr/local/bin/meld'.
?  meld was successfully installed!

Homebrew 不仅安装了应用程序，而且还在我当前的路径 /usr/local/bin/ 下提供了它。现在，我可以从命令行运行 meld 或从应用程序文件夹中启动应用程序。

更新一切的“酿造升级”

我一直使用软件包管理器的主要原因是，我可以不断升级我的软件，以避免已知的安全漏洞，并确保我总是有最新的功能。如果我手工安装所有的东西，我必须关注每一个工具和应用程序，以了解它是否有自动更新程序，如果没有，就得自己拉回最新的版本。

升级功能是优秀的软件包管理的闪光点。由于我没有什么特殊的版本要求，所以我只需要运行一个命令就可以顺利更新一切：

$ brew upgrade
==> Upgrading 6 outdated packages:
helm 3.2.1 -> 3.2.2
[email protected] 3.8.2_4 -> 3.8.3
ipython 7.14.0 -> 7.15.0
go 1.14.2_1 -> 1.14.3
libzip 1.6.1 -> 1.6.1_1
sqlite 3.31.1 -> 3.32.1

如果你有更复杂的需求，或者想在安装升级前关注一下升级情况，有很多功能标志可供选择。例如，-n 提供了一个 “模拟运行”，列出了可用的升级，而不会进行安装。你也可以 “钉” 住应用程序版本来防止它升级。

备份你的安装

当该工具允许你像其它点文件的版本控制方案一样备份你的安装环境时，命令行实用程序和应用程序的管理就跳到了一个全新的水平。Homebrew 就有这样的功能，可以在 dump 子命令下使用。它会生成一个 Brewfile，这是一个可重复使用的当前所有安装的工具的列表。要从你的安装的环境中生成一个，进入你的合适的文件夹并运行：

$ cd ~/Development/dotfiles # 这是我的点文件的文件夹
$ brew bundle dump

当我换了机器，想用 Homebrew 安装相同的应用程序时，我就会进入装有 Brewfile 的文件夹并运行。

$ brew bundle

它将在我的新机器上安装所有列出的“秘方”和“酒桶”。

用 Homebrew 进行软件包管理

Homebrew 是我常用的命令行工具和应用程序的管理器。它可以让我保持有条理和及时更新，它的设计在易用性和功能深度之间取得了美丽的平衡。Homebrew 将软件包管理的细节最小化到只需要你知道的程度，大多数用户都会从中受益。

如果你对 Linux 软件包管理器已经驾轻就熟，你可能会认为 Homebrew 太简单了，但不要误以为 Homebrew 的易用性是功能的缺乏。稍微深入一点看，就会发现很多高级选项，远远超出了我在这里向你展示的范围。将 -h 添加到任何 brew 子命令中，会显示可用来升级、删除、故障排除，甚至使用模板贡献新 “秘方” 的丰富功能。

总的来说，Homebrew 可以让一个重度命令行的 Mac 用户变得很开心。此外，它是开源的，所以如果你愿意，你可以贡献代码。尝试一下它，让我知道你的想法，在下面留下评论。

via: https://opensource.com/article/20/6/homebrew-mac

作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你在 macOS 上运行的项目需要没有安装的 Python 版本，请试试 pyenv。

即使对于有经验的开发人员，管理本地 Python 开发环境仍然是一个挑战。尽管有详细的软件包管理策略，但仍需要采取另外的步骤来确保你在需要时运行所需的 Python 版本。

为什么 Python 版本重要？

起初这是一个奇怪的概念，但是编程语言会像其他任何软件一样发生变化。它们有错误、修复和更新，就像你喜欢的 API 和任何其他软件一样。同样，不同的发行版由称为语义化版本的三位数标识。

??? pic.twitter.com/yt1Z2439W8

— Denny Perez (@dennyperez18) May 28, 2019

多年来，Python 2 是该语言的常用主要版本。在 2020 年 1 月，Python 2 到达最后寿命，此后，Python 的核心维护者将仅支持 Python 3。Python 3 稳步发展，并定期发布新更新。对我来说定期获取这些更新很重要。

最近，我试图在 macOS 上运行一个依赖于 Python 3.5.9 的项目，而我的系统上并没有安装这个版本。我认为 Python 包管理器 pip 可以安装它，但事实并非如此：

$ pip install python3.5.9
Collecting python3.5.9
  ERROR: Could not find a version that satisfies the requirement python3.5.9 (from versions: none)
ERROR: No matching distribution found for python3.5.9

或者，我也可以从官方 Python 网站下载该版本，但我如何在我的 Mac 上与现有的 Python 版本一起运行？每次运行时指定 Python 解释器版本（例如 python3.7 或 python3.5）似乎很容易出错。一定会有更好的方法。

（说明：我知道这对经验丰富的 Python 开发人员没有意义，但对当时的我来说是有意义的。我很乐意谈一谈为什么我仍然认为它应该这样做。）

安装和设置 pyenv

值得庆幸的是，pyenv 可以绕开这一系列复杂的问题。首先，我需要安装 pyenv。我可以从源码克隆并编译它，但是我更喜欢通过 Homebrew 包管理器来管理软件包：

$ brew install pyenv

为了通过 pyenv 使用 Python 版本，必须了解 shell 的 PATH 变量。PATH 决定了 shell 通过命令的名称来搜索文件的位置。你必须确保 shell 程序能够找到通过 pyenv 运行的 Python 版本，而不是默认安装的版本（通常称为系统版本）。如果不更改路径，那么结果如下：

$ which python
/usr/bin/python

这是 Python 的系统版本。

要正确设置 pyenv，可以在 Bash 或 zsh 中运行以下命令：

$ PATH=$(pyenv root)/shims:$PATH

现在，如果你检查 Python 的版本，你会看到它是 pyenv 管理的版本：

$ which python
/Users/my_username/.pyenv/shims/python

该导出语句（PATH=）仅会对该 shell 实例进行更改，为了使更改永久生效，你需要将它添加到点文件当中。由于 zsh 是 macOS 的默认 shell，因此我将重点介绍它。将相同的语法添加到 ~/.zshrc 文件中：

$ echo 'PATH=$(pyenv root)/shims:$PATH' >> ~/.zshrc

现在，每次我们在 zsh 中运行命令时，它将使用 pyenv 版本的 Python。请注意，我在 echo 中使用了单引号，因此它不会评估和扩展命令。

.zshrc 文件仅管理 zsh 实例，因此请确保检查你的 shell 程序并编辑关联的点文件。如果需要再次检查默认 shell 程序，可以运行 echo $SHELL。如果是 zsh，请使用上面的命令。如果你使用 Bash，请将 ~/.zshrc 更改为 ~/.bashrc。如果你想了解更多信息，可以在 pyenv 的 README 中深入研究路径设置。

使用 pyenv 管理 Python 版本

现在 pyenv 已经可用，我们可以看到它只有系统 Python 可用：

$ pyenv versions
system

如上所述，你绝对不想使用此版本（阅读更多有关信息）。现在 pyenv 已正确设置，我希望它能有我经常使用的几个不同版本的 Python。

有一种方法可以通过运行 pyenv install --list 来查看 pyenv 可以访问的所有仓库中的所有 Python 版本。这是一个很长的列表，将来回顾的时候可能会有所帮助。目前，我决定在 Python 下载页面找到的每个最新的“点版本”（3.5.x 或 3.6.x，其中 x 是最新的）。因此，我将安装 3.5.9 和 3.8.0：

$ pyenv install 3.5.9
$ pyenv install 3.8.0

这将需要一段时间，因此休息一会（或阅读上面的链接之一）。有趣的是，输出中显示了该版本的 Python 的下载和构建。例如，输出显示文件直接来自 Python.org。

安装完成后，你可以设置默认值。我喜欢最新的，因此将全局默认 Python 版本设置为最新版本：

$ pyenv global 3.8.0

该版本立即在我的 shell 中设置完成。确认一下：

$ python -V
Python 3.8.0

我要运行的项目仅适于 Python 3.5，因此我将在本地设置该版本并确认：

$ pyenv local 3.5.9
$ python -V
Python 3.5.9

因为我在 pyenv 中使用了 local 选项，所以它向当前目录添加了一个文件来跟踪该信息。

$ cat .python-version
3.5.9

现在，我终于可以为想要的项目设置虚拟环境，并确保运行正确版本的 Python。

$ python -m venv venv
$ source ./venv/bin/activate
(venv) $ which python
/Users/mbbroberg/Develop/my_project/venv/bin/python

要了解更多信息，请查看有关在 Mac 上管理虚拟环境的教程。

总结

默认情况下，运行多个 Python 版本可能是一个挑战。我发现 pyenv 可以确保在我需要时可以有我需要的 Python 版本。

你还有其他初学者或中级 Python 问题吗？ 请发表评论，我们将在以后的文章中考虑介绍它们。

via: https://opensource.com/article/20/4/pyenv

作者：Matthew Broberg 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我们邀请 Opensource.com 的 DevOps 团队，希望他们能够谈一谈作为 DevOps 内向者的休验，同时给 DevOps 外向者一些建议。下面是他们的回答。

我们邀请我们的 DevOps 团队 谈一谈他们作为一个内向者的体验，并给外向者们一些建议。但是在我们开始了解他们的回答之前，让我们先来定义一下这些词汇。

“内向者”是什么意思？

内向者通常指的是一部分人群，当他们和别人相处的时候，会使他们的能量耗尽，而不是激发他们更多的能量。当我们思考我们是如何恢复能量时，这是一个非常有用的词汇：内向者通常需要更多的独处时间来恢复能量，特别是和一群人在一起很长时间后。关于内向者的一个非常大的误解就是他们一定是“害羞的”，但是科学表明，那不过是另一种不同的性格特征。

内向性与外向性是通过 Myers Briggs 类型指标 而为人所知的，现在也常常被称作一个 光谱 的两端。虽然这个世界看起来好像外向者比内向者要多，但是心理学者则倾向于认为大部分人在光谱上的位置是落在 中间性格或偏内向性格的。

现在，我们来看看问答。

DevOps 技术主管可以通过哪些方式来让内向者感觉他们是团队的一部分并且愿意分享他们的想法？

“每个人都会不大一样，所以观察敏锐就很重要了。从 GitLab 过来的一个人告诉我，他们的哲学就是如果他们没有提供任何意见，那么他们就是被排除在外的。如果有人在一个会议上没有提供任何的意见，那就想办法让他们加入进来。当我知道一个内向者对我们将要讨论的会议论题感兴趣的时候，我会提前请他写一些书面文本。有非常多的会议其实是可以避免的，只要通过把讨论放到 Slack 或者 GitLab 上就行了，内向者会更愿意参与进来。在站立会议中，每个人都会交代最新的进展，在这个环境下，内向者表现得很好。有时候我们在其实会议上会重复做一些事情，仅仅是为了保证每个人都有时间发言。我同时也会鼓励内向者在工作小组或者社区小组面前发言，以此来锻炼他们的这些技能。”—— 丹·巴克

“我觉得别人对我做的最好的事情，就是他们保证了当重大问题来临的时候，我拥有必要的技能去回答它。彼时，我作为一名非常年轻的入伍空军的一员，我需要给我们部队的高级领导做状态简报的汇报。我必须在任何时候都有一些可用的数据点，以及在实现我们确立的目标的过程中，产生延误以及偏差的背后的原因。那样的经历推动着我从一个‘幕后人员’逐渐变得更加愿意和别人分享自己的观点和想法。”—— 克里斯·肖特

“通过文化去领导。为你的同僚一起设计和尝试仪式。你可以为给你的小组或团队设计一个小的每周仪式，甚至给你的部门或组织设计一个年度的大仪式。它的意义在于去尝试一些事物，并观察你在其中的领导角色。去找到你们文化当中的代沟以及对立。回顾团队的信仰和行为。你能从哪里观察到对立？你们的文化中缺失了什么？从一个小陈述开始‘我从 X 和 Y 之间看到了对立’，或者‘我的团队缺少了 Z’。接着，将代沟与对立转换为问题：写下三个‘我们如何能……(How might we’s, HMWs)’。”—— 凯瑟琳·路易斯

“内向者不是一个不同的群体，他们要么是在分享他们的想法之前想得太多或等得太久的一些人，要么就是一些根本不知道发生了什么的人。我就是第一种，我想太多了，有时候还担心我的意见会被其他人嘲笑，或者没有什么意思，或者想偏了。形成那样的思维方式很难，但它同时也在吞噬着我学习更好事物的机会。有一次，我们团队在讨论一个实现问题。我当时的老大一次又一次地问我，为什么我没有作为团队中更具经验的人参与进来，然后我就（集齐了全宇宙的力量之后）开口说我想说的大家都已经说过了。他说，有时候我可以重复说一次，事情纷繁，如果你能够重复一遍你的想法，即使它已经被讨论过了，也会大有裨益。好吧，虽然它不是一种特别信服的方式，但是我知道了至少有人想听听我怎么说，它给了我一点信心。

“现在，我所使用的让团队中的人发言的方法是我经常向内向的人求助，即使我知道解决方法，并且在团队会议和讨论中感谢他们来建立他们的自信心，通过给他们时间让他们一点一点的从他们寡言的本性中走出来，从而跟团队分享很多的知识。他们在外面的世界中可能仍然会有一点点孤立，但是在团队里面，有些会成为我们可以信赖的人。”—— 阿布希什克·塔姆拉卡尔

“我给参加会议的内向者的建议是，找一个同样要参加会议的朋友或者同事，这样到时你就会有人可以跟你一起舒服地交谈，在会议开始之前，提前跟其他的与会者（朋友、行业联系人、前同事等等）约着见个面或者吃顿饭，要注意你的疲劳程度，并且照顾好自己：如果你需要重新恢复能量，就跳过那些社交或者夜晚的活动，在事后回顾中记录一下自己的感受。”—— 伊丽莎白·约瑟夫

和一个内向者倾向的同事一起工作时，有什么提高生产效率的小建议？

“在保证质量时，生产效率会越来越具备挑战性。在大多数时候，工作中的一个小憩或者轻松随意的交谈，可能正是我们的创造性活动中需要的一个火花。再说一次，我发现当你的团队中有内向者时， Slack 和 Github 会是一个非常有用的用于交换想法以及和其他人互动的媒介。我同时也发现，结对编程对于大部分的内向者也非常有用，虽然一对一的交流对于他们来说，并不像交税那么频繁，但是生产质量和效率的提升却是重大的。但是，当一个内向者在独自工作的时间，团队中的所有人都不应该去打断他们。最好是发个邮件，或者使用没有那么强的侵入性的媒介。”—— 丹·巴克

“给他们趁手的工具，让他们工作并归档他们的工作。让他们能够在他们的工作上做到最好。要足够经常地去检查一下，保证他们没有走偏路，但是要记住，相比外向者而言，这样做是更大的一种让人分心的困扰。”—— 克里斯·肖特

“当我低着头的时候，不要打断我。真的，别打断我！当我沉浸在某件事物中时，这样做会造成我至少需要花费两个小时，才能让我的大脑重新回到之前的状态。感觉很痛苦。真的。你可以发个邮件让我去有白板的地方。然后从客户的角度而不是你的角度——通过画图的方式——分享下有什么问题。要知道，可能同时会有十几个客户问题缠绕在我的脑海中，如果你的问题听起来就是‘这样子做会让我在我的领导面前显得很好’的那一类问题，那么相比我脑袋中已经有的真正的客户问题而言，它不会得到更多的关注的。画个图，给我点时间思考。当我准备分享我的看法的时候，保证有多支马克笔可以使用。准备好接受你对问题的假设有可能完全是错误的。”—— 凯瑟琳·路易斯

“感谢和鼓励就是解决的方法，感谢可能不是一份工作评估，但是感谢能让人舒服地感受到自己并不仅仅是一个活着的独立实体，因而每个人都能够感觉到自己是被倾听的，而不是被嘲笑或者低估的。”—— 阿布希什克·塔姆拉卡尔

结语

在与内向的 DevOps 爱好者的这次交谈中，我们最大的启迪就是平等：其他人需要被怎样对待，就怎样对待他们，同时你想被怎样对待，就去要求别人怎样对待你。无论你是内向还是外向，我们都需要承认我们并非全以相同的一种方式体验这个世界。我们的同事应当被给予足够的空间以完成他们的工作，通过讨论他们的需求作为了解如何支持他们的开始。我们的差异正是我们的社区如此特别的原因，它让我们的工作对更多的人更加的有用。与别人沟通最有效的方式，就是对于你们两者而言都可行的方式。

via: https://opensource.com/article/19/7/devops-introverted-people

作者：Matthew Broberg 选题：lujun9972 译者：XLCYun 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出