Version control 生产环境中的Julia包版本控制

如果您想在生产环境中使用它，那么如何在Julia中进行版本控制。也就是说，大多数Julia软件包和Julia本身都有0.3.10或类似的版本号，因此您应该为（近期）的主要界面更改做好准备，尤其是当第一个数字从0变为1时

我的包状态如下所示：

julia> Pkg.status()
4 required packages:
 - DataFrames                    0.6.9
 - Gadfly                        0.3.13
 - Jewel                         1.0.5
 - Mongo                         0.1.3
44 additional packages:
 - ArrayViews                    0.6.3
 - BinDeps                       0.3.15
 - Calculus                      0.1.10
 - Codecs                        0.1.4
 - Color                         0.4.7
 - Compat                        0.6.0
 - Compose                       0.3.13
 - Contour                       0.0.7
 - DataArrays                    0.2.17
 - DataStructures                0.3.12
etc...

建议您经常使用

Pkg.update（）

，以便在所有软件包上都有最新的补丁程序

如果由于这些修补程序而需要更新软件包，或者需要使用新功能，则可能会破坏代码，并且不同软件包之间也可能存在依赖关系

---

Julia可能是一种足够成熟的语言，没有严重的版本控制问题，但我觉得有必要对Julia用户的体验进行民意调查。

在生产环境中，您不应该经常使用

Pkg.update（）

，或者至少不需要先在非生产环境中进行测试。这适用于所有包装系统，而不仅仅是Julia。 特别是对于Julia，我还建议建立一组适合您的版本，然后在

REQUIRE

文件中使用适当的上下限

例如，假设

JuMP

0.9.2适合我，Gadfly 0.4.2也适合我。我可能会在

~/.julia/v0.3/REQUIRE

中执行以下操作：

JuMP 0.9.2 0.10
Gadfly 0.4.2 0.5

---

这样，如果我运行

Pkg.update（）

我将得到

0.9.3

和

0.4.3

，如果它们出现，但我不会自动升级到

跳转0.10

。当然，只有当您信任包维护人员明智地使用版本号时，这才有效，这是一个严重的问题，尤其是当他们是

1.0之前的
声明性包.jl
包（）允许您指定每个项目要使用的每个包的确切版本：它从这些包的确切可用版本开始。这听起来像是你在寻找的东西。
Hmm。作为Julia的新用户，看到所有Julia软件包的痛苦，这听起来真的很有用。Julia的创建者迟早应该开始考虑一个严肃的包管理系统，例如人们开始为各种javascript库/框架编写的系统。还没有听说过多少“包痛苦”
Pkg
在许多方面与
npm
和
pip
非常相似，其中许多不同之处在于有意识的决策。