Nim包管理器--Nimble

Nimble

Nimble是一个非常轻量级的Nim语言的软件包管理器，它使用你的文件系统来确定已经安装的包。它的重点是易于实现，所以即使出了一些错误，它也很容易规避。它支持3个主要的操作系统，并且也可以工作在鲜为人知的系统上。

安装包下载:https://github.com/nim-lang/nimble

1.安装

你需要0.9.6或者更高版本的Nim编译器(OSX用户必须使用开发版本0.10.1或者更高)。要运行nimble你将需要已安装一些工具，它依赖于检查源代码。例如，如果包托管在Github上，你需要安装git添加到你的环境PAHT。与托管在Bitbucket上的Mercurial仓库一样。在Windows上为了安全的网络链接你需要OpenSSL DLLs。

1.1 Unix

在Unix操作系统上，使用两条简单的命令就可以编译以及安装Nimble。在成功的取得最新的Nim编译器之后，简单的执行下面的命令来克隆nimble,编译它然后安装它。

git clone https://github.com/nim-lang/nimble.git
cd nimble
nim c -r src/nimble install

在这些步骤之后，nimble应该已经编译和安装。你应该添加~/.nimble/bin到你的$PATH。通过执行nimble install nimble可以更新nimble。

1.2 Windows

你可以通过一个预构建安装可以在发布页得到的存档文件或者从源码安装。

1.2.1 使用预构建存档文件

从发布页面下载最新版本的存档文件。这个存档文件将有一个nimble-x_win32形式的文件名，x是当前版本号。

下载文档并解压，然后执行install.bat文件。重要的一点是该安装要求在你的PATH中有Nim编译器。一旦安装完成，你应该将C:\Users\YourName\.nimble\bin添加到你的PATH。

1.2.2 From source

在windows上从源安装Nimble是稍微复杂的：

git clone https://github.com/nim-lang/nimble.git
cd nimble
nim c src/nimble
cp src/nimble.exe src/nimble1.exe
src/nimble1.exe install

这是有必要的，因为在将要运行和安装期间Windows将锁定进程，Nimble将重新编译它本身。一旦完成安装你应该添加C:\Users\YourName\.nimble\bin到你的PATH。

2.Nimble的文件夹结构和包

在Unix系统上Nimble将所有已经安装的软件存储在~/.nimble中，windows系统中存储在$home/.nimble中。库文件存储在$nimbleDir/pkgs以及二进制文件存储在$nimbleDir/bin。大多数Nimble包将提供.nim文件和一些文档。Nim编译器会意识到Nimble并且将自动找到模块，所以你可以import modulename，不用额外的设置就可以工作。

然而，一些Nimble包可以提供额外的工具或命令。如果你不将它们的位置($nimbleDir/bin)添加到你的$PATH，它们将不能工作并且你将无法运行它们。

3.Nimble的用法

一旦在你的系统上安装了Nimble，你可以运行nimble命令来获取可用的参数列表。

3.1 nimble update

update命令被用来获取和更新Nimble packages列表。这没有自动更新机制，所以你需要自己运行更新命令如果你需要刷新你本地的已知可用的Nimble packages列表。例如：

$ nimble update
Downloading package list from https://.../packages.json
Done.

一些命令可能提醒你运行nimble update或者如果它们失败将会为你运行nimble update。

如果你想使用一个第三方软件包列表，你也可以选择使用带有一个URL的update命令。

3.2 nimble install

install命令将下载并安装一个包。你需要传递你想安装的包名(或者)。如果有任何包依赖于其他的Nimble包，Nimble也将会安装它们。例如：

$ nimble install nake
Downloading nake into /tmp/nimble/nake...
Executing git...
...
nake installed successfully

Nimble总是获取和安装一个包的最新版本。注意：最新的版本是在git(或者hg)仓库中被定义为最新标签的版本，如果包没有版本标签，将会安装远程仓库中最新的提交。如果你已经有那个版本，安装Nmble将会询问你是否希望它改写你的本地副本。

你可以强制Nimble从包的仓库中下载最新提交，例如：

$ nimble install nimgame@#head

当然这是git特性。对于hg使用tip而不是head。一个分支，标签或者提交哈希也可以在head的位置指定。

替代指定一个版本控制系统分支，你也可以指定一个版本范围，例如：

$ nimble install nimgame@"> 0.5"

在这种情况下，将会安装一个高于0.5的版本。

如果没有指定一个参数，并且在你的当前工作目录中有一个package.nimble文件，Nimble将安装驻留在当前工作目录中的包。这对于正在测试他们本地的.nimble文件，再将它们提交给官方软件包列表的开发者可能是有用的。有关此更多的信息请看developers.markdown。

也可以指定到一个仓库的URL,Nimble将会自动检测url指向的仓库类型，并安装它。

3.3 nimble uninstall

uninstall命令卸载已经安装的包。试图卸载一个其它包依赖的包是不允许的并且将会导致错误。在此之前你必须手动卸载反向依赖。

类似于install命令，你可以指定一个版本范围，例如：

$ nimble uninstall nimgame@0.5

3.4 nimble build

build命令常用于想要测试构建其.nimble包的开发者。这个命令将会在调试模式下构建包，不会安装任何东西。install命令将会在发布模式下构建包。

如果你是一个开发者想要生成新的Nimble packages，详细信息请阅读developers.markdown文档。

3.5 nimble c

c(或者compile,js,cc,cpp)命令可以被开发者用来编译其包中的单个模块。所有传递给Nimble的选项，在编译期间都将传递给Nim编译器。

如果指定了c或者compile命令Nimble将使用包中.nimble文件指定的后端。更具体的js,cc,cpp可以用来覆盖它。

3.6 nimble list

list命令将显示已知的可用于Nimble的包列表。可以指定一个--ver参数选项用来告诉Nimble查询远程git仓库得到packages的版本列表并打印版本。请注意这可能是缓慢的，因为每个包必须单独查询。

3.7 nimble search

如果你不想查看list命令的全部输出，你可以使用search命令限定你想筛选的包名或者标签作为参数。Nimble将搜索已知的可用软件包列表，并且仅显示那些匹配指定关键字的记录(也可能是子串)，例如：

$ nimble search math
linagl:
  url:         https://bitbucket.org/BitPuffin/linagl (hg)
  tags:        library, opengl, math, game
  description: OpenGL math library
  license:     CC0

extmath:
  url:         git://github.com/achesak/extmath.nim (git)
  tags:        library, math, trigonometry
  description: Nim math library
  license:     MIT

搜索是不区分大小写的。

可以指定可选项--ver参数来告诉Nimble查询远程git仓库得到packages的版本列表并打印版本。请注意：这可能是缓慢的，因为每个包必须分开查询。

3.8 nimble path

nimble path命令将显示匹配指定参数已安装包的绝对路径。可能同一个已经安装的包有多个版本，path命令将总是显示最新的版本。例如：

$ nimble path argument_parser
/home/user/.nimble/pkgs/argument_parser-0.1.2

在Unix下，你可以使用反引号来快速进入一个包的目录，这对于阅读绑定文档非常有用。例如：

$ pwd
/usr/local/bin
$ cd `nimble path argument_parser`
$ less README.md

3.9 nimble init

nimble init命令将启动一个简单的向导，它将为你的项目创建一个快速的.nimble文件。

4.配置

在启动时，在Linux平台上，Nimble将尝试读取~/.config/nimble/nimble.ini(在windows平台上将尝试读取C:\Users\<YourUser>\AppData\Roaming\nimble\nimble.ini)。

此文件的格式对应于一些Nim增强ini格式。例如：

nimbleDir = r"C:\Nimble\"

目前在该文件中，可以配置如下：

nimbleDir - nimble用于安装包的目录 默认: ~/.nimble/

chcp - 当执行Nim应用程序包时是否改变当前代码页.如果为true，这将添加chcp 65001到在~/.nimble/bin/中生成的.cmd存根中默认: true

5.创建Packages

相关链接：http://blog.csdn.net/dajiadexiaocao/article/details/50009009

Nimble工作在git仓库中，packages作为它的主要来源。它的包列表存储在nim-lang/packages仓库中可自由访问的JSON文件中。这个JSON文件提供nimble所需的Git URL用来克隆包并安装它。安装和构建命令包含在一个带有.nimble文件拓展名的ini风格的文件中。nimble文件共享包的名称，一个命名为foobar的包应该有一个对应的foobar.nimble文件。

这个文件指定有关该包的信息，包括它的名字，作者，许可证，依赖关系以及更多。没有该文件,Nimble是不能安装一个包的。一个最低配置的minmum.nimble文件如下：

[Package]
name          = "ProjectName"
version       = "0.1.0"
author        = "Your Name"
description   = "Example .nimble file."
license       = "MIT"

[Deps]
Requires: "nim >= 0.10.0"

你可以完全忽略依赖。但是推荐指定Nim编译器需求的最低版本。

Nimble目前支持从一个本地目录，git仓库以及一个mercurial仓库安装包。.nimble文件必须出现在目录的根目录或者将安装的仓库中。

5.1 库文件

库包可能是Nimble packages最流行的形式。它们意味着被其他库包或者最终的二进制包使用。

当nimble安装一个库时它将复制包中的所有文件到$nimbleDir/pkgs/pkgname-ver。这取决于包创建者确保包目录布局是正确的，如此用户的包才可以正确的导入到包。

按照惯例，建议的布局如下。目录布局取决于你的包的性质，也就是说，是否你的包仅公开一个模块或者多个模块。

如果你的包仅公开一个模块，该模块应该出现在你的git仓库的根目录(.nimble文件所在的目录)中，在这种情况下推荐使用你的模块名与你的包名一致，无论你的包名是什么。这方面一个很好的例子是jester包公开jester模块。在这种情况下，使用import jester导入jester包。

如果你的包公开了多个模块，这些模块应该在一个PackageName目录中。这将给予从其它包公开有相同名字的模块一个特定的隔离措施。在这种情况下，使用import PackageName/module将导入包的模块。

你可以自由的结合描述的这两种方法。

有关你不想公开的模块。你应该将它们放在一个PackageName/private目录下。然后你的模块可以使用import PackageName/private/module导入这些私有的模块。这个目录结构在将来可能会被强制。

.nimble文件所在目录下的所有文件和目录都将被复制，但是你可以通过在你的.nimble文件设置SkipDirs，SkipFiles或者SkipExt选项跳过某些目录和文件。目录和文件也可以在一个whitelist基础上指定，如果你指定InstallDirs，InstallFiles或者InstallExt其中一个，Nimble将只安装指定的文件。

5.2   二进制文件

这些是应用程序包，它们要求在安装之前先构建。一个包自动地是一个二进制包只要它至少设置一个bin值，例如这样：

bin = "main"

在这种情况下当调用nimble install,nimble将会创建main.nim文件，将它复制到$nimbleDir/pkgs/pkgname-ver/，随后在$nimbleDir/bin/中创建一个二进制的符号链接。在windows下，创建一个.bat存根文件。

其他的文件将以同样的方式被复制，因为它们是二进制包。

二进制包不能安装.nim文件，所以在你的.nimble文件中应该包含SkipExt = "nim"，除非你打算让你的包成为一个binary/library组合，这是代价。

在构建之前，依赖关系自动安装。在发布你的包之前，你应该确保你指定的依赖关系是正确的。你可以通过在你的软件包的目录中运行nimble build或者nimble install达到检验的目的。

5.3 Hybrids

关于库包和二进制包混合需要注意的一点是，你的二进制将最有可能分享包名。这将意味着，你将不能把你的.nim文件放到pkgname目录中。目前解决这个问题的惯例是，给名字附加pkg，当做nimble所做的。

5.4 依赖关系

依赖在一个nimble文件的[Deps]部分指定。关键字域requires用于指定它们。例如：

[Deps]
Requires: "nim >= 0.10.0, jester > 0.1 & <= 0.5"

依赖列出支持版本范围。这些版本可能是一个具体的版本如0.1，或者它们可能包含任何,小于(<),大于 (>), 小于或等于 (<=) and 大于或等于 (>=)。使用&操作符可合并两个版本范围，例如：> 0.2 & < 1.0将安装一个版本高于0.2，低于1.0版本的包。

指定一个具体的版本作为一个依赖不是一个好注意，因为你的包可能最终取决于同一个包的两个版本。如果发生这种情况，Nimble将拒绝安装包。同样地，你不应该指定一个上限，因为这样可以导致同样的问题。

除版本外，你也可以指定git/hg标签，分支和提交。然而，这些都必须是具体的。这是用#字符完成，例如:jester#head,它将使你的包依赖于最新提交的Jester。

5.4 Nim编译器

Nim编译器不能读取.nimble文件。它对Nimble的了解限制于nimblePaths功能，这允许它当编译你的软件时在Nimble的包目录中使用packages。这意味着它不能解决依赖关系，以及它仅可以在编译时使用最新版本的包。

当Nimble创建你的包时它实际执行Nim编译器。它解决了依赖关系并且为编译器提供每一个包的路径，所以，它准确的知道使用哪个版本。

这意味着在开发软件的时候你可以安全的使用编译器编译，但是在发布之前，你应该使用nimble来创建包，已确保你所指定的依赖关系是正确的。

5.5 版本

通过git或者mercurial克隆的包的版本由仓库的标签决定。

当安装一个需要下载的包时，在下载完成之后并且如果该包通过一个版本控制系统分配，nimble将会检查克隆仓库的标签列表。如果没有标签存在，nimble将简单的安装仓库的HEAD(在mercurial中是tip).如果标签存在，nimble将试图寻找类似版本的标签(e.g. v0.1),然后会找到最新版本的可用标签，一旦它这样做，在检查到最新版本后它将安装包。

通过在你的依赖列表中包名之后指定#head，你可以强制安装仓库的HEAD版本(最新版本)。

6. 将你的包提交到Nimble packages

Nimble packages列表存储在github上，并且每个人都被鼓励将自己的包添加到它中!查看nim-lang/packages学习更多。

7 .   .nimble reference 

[Package]

必选项

name - 包名

version - 这个包的当前版本。这应该是递增的，在使用git tag或者hg tag标记当前版本之后。

author - 这个包的作者名。

description - 描述这个包的字符串。

license - 该包的许可证名称。

可选项

SkipDirs - 在安装期间应该跳过的目录名列表，用逗号分割。

SkipFiles - 在安装期间应该跳过的文件名列表，用逗号分割。

SkipExt - 在安装期间应该跳过的文件拓展名列表，拓展名应该使用不带引导的.指定，并且应使用逗号分割。

InstallDirs - 应专门安装的目录列表，如果这个选项没有指定任何其他，将安装除这里列出的目录，文件在InstallFiles中列出，在InstallFiles中列出的文件共享在InstallExt，.nimble文件以及二进制文件中列出的文件拓展名。用逗号分割。

InstallFiles - 应专门安装的文件列表，它补充InstallDirs和InstallExt。只有文件列出在这里，目录列在InstallDirs中，在InstallFiles中列出的文件共享在InstallExt，.nimble文件以及二进制文件中列出的文件拓展名。用逗号分割。

InstallExt - 应专门安装的文件拓展名列表，它补充InstallDirs和InstallFiles。用逗号分割。

srcDir - 指出包含.nim源文件的目录。默认:.nimble文件所在的目录；包的根目录。

binDir - 指定nimble bulid将输出二进制文件的路径。默认:.nimble文件所在的目录；包的根目录。

bin - 应该使用逗号分开构建并不带特定的文件拓展名的文件列表。该选项将你的包转化成一个二进制包，nimble将构建指定的文件并适当的安装它们。 

backend - 指定后端将用于构建在bin中列出的文件。可能的值包括:c, cc, cpp, objc, js.默认:c

[Deps]/[Dependencies]

可选项

requires - 指定一个有可选版本范围的包名列表，用逗号分割。例如:nim >= 0.10.0, jester;使用这个值你的包将取决于nim的0.10.0版本或者更高，以及任何版本的jester.

8.贡献

如果你愿意帮助，自由fork，做任何你认为合适的补充，然后发送一个pull request.

关于这个项目，如果你有任何问题，你可以直接在github向提问，在Nim论坛上提问，或者在Freenode in the #nim channel上提问。

9.关于

Nimble由Dominik Picheta完成，得到了来自一些贡献者的帮组。它在BSD许可证下授权(更多信息查看license.txt)