gx-trn-beg-c_GX的先驱指南-IPFS上的分散依赖管理

gx-trn-beg-c

对于当今的开发人员而言，分散式软件包管理是工具开发的一个令人兴奋的领域。 分散式软件包管理器有可能从现代软件库的互连网络中消除集中式故障点。 他们为开发团队提供了一种简单明了的方法，以确保其内部代码网络始终可用，同时确保整个Internet的冗余。 分散的程序包管理器可以使我们的代码（现代社会最有价值的输出之一）更加抵制篡改，检查和操纵。

也就是说，分散式软件包管理仍不完整。 在将我们的代码发布到围绕数字信息不变性的网络中时，有许多问题需要解决，其中随时可能存在无限数量的信息副本。 没有中央机构，他们需要新的解决方案来发现，删除信息（例如，出版商不拥有的内容），纠纷和潜在的不良行为者。 这些问题不仅由分散的软件包管理者共享，而且通常由分散的网络共享，因此已经提出了一些解决方案，并且正在积极开发许多其他解决方案。 就是说，在使用任何分散式软件包管理器之前，了解您的风险和责任很重要。

我已经对去中心化源代码和网络依赖关系时所面临的承诺（以及一些陷阱）进行了更完整的讨论。 如果您不熟悉该主题，强烈建议您在阅读本教程之前先阅读它。 您可以在此处找到面向开源未来的分散式代码分发。

因此，这里简要介绍了使用分散式软件包管理器GX （特别是Golang实现， gx-go ）分发代码并管理基于IPFS的代码依赖性。 开始之前的最后一件事是GX开发人员在自述文件中所说的内容，

gx是Alpha质量 。 它还不是很完美，但是事实证明它足够可靠，可以管理go-ipfs中的依赖关系，并为开拓性开发人员和早期用户准备尝试和探索。

GX和gx-go简介

gx-go和gx-js软件包管理器都使用了GX库的核心功能。 他们共同分享的基本原则是，

1. 您发布的代码版本由包含的代码的不可变哈希值引用。
2. 您链接到代码中的依赖项链接到那些不可变的哈希，以查找和检索代码，并确保您使用的是您期望的版本。
3. 不变的哈希是IPFS上发布的代码可用的地址。

这是什么意思？ 好吧，首先，它不是使用语义版本控制作为对特定代码发布的全局引用，而是使用代码本身的指纹（哈希）。 GX还实现了哈希到语义版本的辅助映射，这主要是为了改善人类与代码的交互（例如，可读性）。 这些哈希成为IPFS中使用的内容寻址系统的一部分。

如果您不熟悉IPFS，则可以通过一些很棒的概述来说明系统是什么， 系统 如何工作以及如何 在 GX 之外使用它 。 要了解的是，它是一组技术和协议，使任何用户都可以在分散的计算机网络上分发媒体或数据。 对于GX用户，请输入他们的代码。 只要有人分发您要查找的媒体，就可以使用IPFS通过网络检索该数据。

对于GX，此分发模型意味着，如果要在系统上发布代码，则需要首先使其在IPFS网络上可用。 尽管您可能是第一个托管该数据的人，但是一旦其他人开始使用它，则很可能很快就会从其他节点上获得这些数据。 纺织品和其他GX用户经常镜像他们使用的代码，从而增加了网络的冗余性和速度。 例如，在Textile Photos Go库中，我们有一个团队IPFS节点，我们可以在其中固定我们依赖于GX的所有依赖项。

好的，那是基本机制。 让我们尝试使用它。

安装GX和gx-go

下两个部分（分发和依赖管理）都需要此简单步骤。 让GX和gx-go在您的系统上运行，只需运行以下两个命令。

go get -u github.com/whyrusleeping/gx
go get -u github.com/whyrusleeping/gx-go

只要您将Go根目录和/bin正确地添加到path ，以上内容都应该使GX命令行工具可用。 如果上一行对您没有意义，那么在继续此处之前，有一些关于 Go 入门的教程可能会很有用。

在GX上共享代码

我们或多或少发现GX，因为它是IPFS相关项目中使用的软件包管理器。 但是使用它使我们真正考虑了上面提到的所有好处。 GX最初是为了支持gx-go而编写的，但也有gx-js ，并且原始的GX代码已准备好以任何语言分叉给程序包管理器。 它的可扩展性足以使我们思考IPFS上的移动应用程序商店的未来会是什么样子……不过我们会将其保存一天。 在下面的博客文章中，让我们逐步介绍在自己的项目中使用gx-go的基础知识。

在Go项目中设置GX

在Go项目的文件夹内，您只需在终端中运行以下命令，

gx init --lang=go

运行上述操作将向您的文件夹中添加一个package.json文件，其中包含一些与GX一起使用的必要位。 如果您的项目由于其他原因已经有了package.json文件，则会添加重要的位。 这是GX存储在package.json文件中的信息的概述。

您的package.json将列出您在此项目中使用的GX版本：

"gxVersion": "0.12.1",

同样从package.json ，GX添加导入重写路径。 这将指定如何用用户代码重写import语句（与始终显示非人类可读的哈希相反）。 这是我的样子，从我的Go路径中自动检测到。

"gx": {
  "dvcsimport": "github.com/textileio/gx-demo"
}

接下来， package.json包含helper命令，该命令稍后将告诉GX如何为您处理新版本。

"releaseCmd": "git commit -a -m \"gx publish $VERSION\""

而已。 现在，您的代码已准备好开始在GX上发布。 让我们尝试在GX上发布代码的版本。 为此，我们可以使用GX提交代码，该代码将运行上面的releaseCmd脚本。

gx release 0.0.1-dev

Error: ipfs daemon isn't running

现在...您可能已经击中了第一个陷阱。 就像我在介绍中所说的那样，GX使用IPFS分发代码，这意味着您需要在系统上运行IPFS守护程序。 我不会在这里逐步完成安装步骤 ，也不会介绍启动和运行守护程序所需的单行代码 。 但是一旦完成，您应该可以再次运行gx release 0.0.1-dev并获得如下输出：

gx release 0.0.1-dev

package gx-demo published with hash: QmZFb51F1rJcHy9UUWWgPvwJAMorMgdzw2a52y2xgjVZJu

现在，任何人都应该能够通过GX或直接通过IPFS（甚至是网关）访问您的代码。

您可能已经注意到，当您运行gx release ，创建了一个新文件.gx/lastpubver 。 该文件包含语义版本号到IPFS哈希的映射。 您应该将此文件夹包括在git历史记录中，因为它可以在以后的任何时候将代码链接到发行版。 与哈希不同，不能保证语义版本是不可变的。 即使在GX中，您也可以使用一组全新的代码重新发布相同的语义版本，从而获得新的哈希值。

在GX上发布新版本

好的，您已经遍历并更改了代码，现在可以发布新版本了。 您现在有两个选择。 GX此处没有太多规则，因此从技术上讲，您只需运行gx release 0.0.1-dev再次重新发布相同的版本号。 但是您更有可能想要发布下一个版本，因此只需运行，

gx release 0.0.1

package gx-demo published with hash: QmcUaXVES69qZEhV8tdUbhYtVBkbGU7b9h7bpvAo6xnvC9
[master 6f1a98f] gx publish 0.0.1
 2 files changed, 2 insertions(+), 2 deletions(-)

您会注意到您的.gx/lastpubver已更新，现在可以与网络共享新的哈希值。

从GX安装依赖项

如果要编写可抵抗集中式服务脱机，更改路线图或被阻止的源代码，则可能要使用GX来管理依赖项。 您不必一定要在GX上发布项目才能以这种方式使用GX，并且IPFS上不是每个库都可用，但是希望在未来的几个月中会有越来越多的库。

因此，让我们来看看。

您可以做的第一件事是导入新的依赖项。 您需要具有GX的目标哈希才能执行任何操作。 好的，这是一个开源项目，我们可以使用https://github.com/mr-tron/base58 。 这是一个简单base58库，可以在Go base58 strings转换进出base58 。 因此，如果您知道要查找的内容，则会注意到该存储库不包含任何.gx/pubver文件。 因此，我们有两种选择：

• 我们可以使用上一节中的步骤将GX添加到项目中，并以这种方式获取哈希。 之后，我们可以使用并共享这种依赖性，并且可以通过将源固定在IPFS节点上来帮助网络。
• 我们可以说服所有者自己做。

让我们轻松起来，已经有人在这个项目上走了第一步。 分叉原始的base58项目，并在此处发布带有GX版本的fork， https://github.com/gxed/base58 。 因此，现在我们可以使用发布的哈希值尝试并安装导入。

gx import QmWFAMPqsEyUX7gDUsRVmMWz59FxSpJ1b2v6bJ1yYzo7jY

update imports of github.com/mr-tron/base58 to the newly imported package? [y/N]

通过 对提示 回答“ yes ” ，您将提示GX重写该库的导入，以使用GX提供的库。 因此在这种情况下import github.com/mr-tron/base58看起来更像是import gx/ipfs/QmWFAMPqsEyUX7gDUsRVmMWz59FxSpJ1b2v6bJ1yYzo7jY/go-base58-fast/base58 ，建议您不要 将其导入内容重写后发布到GX。 相反，让它由GX下游处理。

GX将使用您的package.json文件来跟踪这些依赖关系，并处理将来的重写/取消重写。 您可以在gxDependencies部分中找到GX托管依赖项的列表，该列表如下所示：

"gxDependencies": [
    {
      "author": "mr-tron",
      "hash": "QmWFAMPqsEyUX7gDUsRVmMWz59FxSpJ1b2v6bJ1yYzo7jY",
      "name": "go-base58-fast",
      "version": "0.1.1"
    }
  ]

立即开始使用GX！

就是这样，只需执行几个命令，您就可以启动并运行...但是...哦，等等。 您可能会遇到一些有关项目可用性的障碍。 在Textile ，我们在代码上进行协作，并且每个人都可以更新依赖关系。 这意味着，如果我添加一个依赖项，并且是第一个固定源代码的IPFS对等设备，那么我的任何协作者在尝试安装它时都可能遇到障碍，并且代码不可用。 GX尽力而为，但有时仍然存在问题。 为了解决我们团队中的这一问题，我们一直将所有GX依赖项固定到共享IPFS服务器上。

通过固定代码，我们的工作将取决于我们，同时也使网络的冗余性和可用性更好。 您应该努力：)

如果您对我们的更多开发工作感兴趣，请查看我们的Textile-go库或GitHub上的Textile -mobile库。 如果您对IPFS网络上的其他想法感兴趣，请查看我们的计划，以将下一个1,000,000个对等方添加到网络中 。 当然，如果您只是想在手机上运行IPFS，存储和保存照片或启用对等共享，请上清单试试我们的移动应用程序 。

翻译自: https://hackernoon.com/the-pioneers-guide-to-gx-decentralized-dependency-management-on-ipfs-90064858f4c2

gx-trn-beg-c