Julia版本控制在生产环境中

Fer*_*enc 4 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...
Run Code Online (Sandbox Code Playgroud)

建议您Pkg.update()经常使用,以便在所有软件包上都有最新的修补程序.

如果由于这些补丁需要更新软件包,或者需要使用新功能,则可能会破坏代码,并且各种软件包之间也可能存在依赖关系.

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

Iai*_*ing 7

在生产环境中,您不应Pkg.update()经常使用,或者至少在非生产环境中不进行测试.这对每个包装系统都是如此,而不仅仅是朱莉娅.特别是对于Julia,我还建议建立一组适合您的版本,然后在REQUIRE文件中使用适当的下限和上限.

例如,假设JuMP0.9.2对我来说效果很好,就像Gadfly 0.4.2一样.我可能会做以下事情~/.julia/v0.3/REQUIRE:

JuMP 0.9.2 0.10
Gadfly 0.4.2 0.5
Run Code Online (Sandbox Code Playgroud)

这样,如果我跑,Pkg.update()我会得到0.9.3,0.4.3如果他们出来,但我不会自动升级到JuMP 0.10.当然,这只有在您信任软件包维护人员合理使用版本号时才有效,这是一个严重的问题,尤其是当它们预先存在时1.0.


Dav*_*ers 5

DeclarativePackages.jl包 ( https://github.com/rened/DeclarativePackages.jl ) 允许您准确指定要用于每个项目的每个包的哪个版本:它以这些可用包的那些版本启动 Julia。这听起来可能就是您要查找的内容。