在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
接触ruby有一段时间了,说起来自己和这门语言倒挺有缘。学生时代的时候,曾经沉迷于一款叫做RPG Maker的软件。当时和朋友以班上的同学为原型写了一部武侠剧,并计划用RPG Maker制作成游戏,乐此不疲。这个RPG Maker在内部使用了一门脚本语言来描述其游戏逻辑,这门语言便是Ruby。于是乎为了修改游戏框架、拓展引擎原有特性,自己花了不少功夫学习Ruby。可惜最后,由于高考临近,Ruby随着RPG Maker一块儿,淹没在了记忆的深处。
最近突然间有了兴趣,又把Ruby拿出来看看,却发觉这五六年间,Ruby语言的变化之大,是我难以预期的。无论是语言特性本身,还是周边的开发工具、程序库,都较之前有了较大的发展,于是重温变成了重新学习。
既然是学习,光说不练可不行,于是乎又一边开始学习起了Ruby on Rails来,希望能够学以致用。RoR在Ruby社区内可是有着响当当的名号,可以说Ruby之所以名声大噪,很大程度上都是由于RoR的功劳。RoR是一个纯粹的开源软件,它凝聚了世界上最优秀Ruby程序员的勤劳和天分。而我自己,也由于对RoR的研读,了解到了不少Ruby的精妙之处。喟叹之际,便也想对其抽丝剥茧,习其精髓,并记录于博客之中,以飨诸位同好。 Y(^_^)Y
require到底干了什么?
第一次看到require语句的时候,立刻有一种似曾相识的感觉。作为一名C语言起家的技术人,我看到了include的影子。从开发者的角度来说,这两条指令完成了相似的工作:告诉编译器我们想要引用其它地方的代码。但是,仔细思考和实验过后,却不难发觉,这两条指令在实现层面上乃是千差万别。
当我们include一个头文件的时候发生了什么?答案是编译器找到对应的头文件,并将其原地展开。通过对头文件中代码的解析,编译器知道了我们要引用的代码的声明(Declaration)。所谓声明,即是指编译器知道将要引用的代码到底长成什么样,而并不知道代码具体是什么(Definition)。而为了让我们的代码真正地用上所引用的代码,我们需要在链接的时候,向linker指明引用库的地址。而这个所谓的引用库,才包含了我们欲引用代码的具体定义。
反观require呢?当我们require某个外部代码的时候,我们实际上是告诉编译器寻找对应的rb文件。这个rb文件中有什么?答案是,引用代码的具体定义。这时候require和include有何区别的答案便呼之欲出了:由于Ruby没有传统意义上的链接过程,我们require实际上是载入代码的实现/定义;而对于C编译器来说,include只不过是告诉编译器代码长啥样,这使得编译器能够生成"调用代码",而"实现代码"则是在链接阶段予以提供的。
require的实现
按照官方解释,require将会在Ruby的LOAD_PATH中查找对应文件并将其载入。好奇心促使我跟踪了require的执行过程,却发觉require并没有调用系统默认的Kernel#require,而是调用到了位于custom_require.rb中的Kernel#require函数之中。
而恰巧的是,这个文件是属于RubyGem的一部分。到目前为止,我们还能够理解发生了什么:RubyGem用自己的require替代了系统默认的版本,并藉此实现了它自己的逻辑。
可是这样理解后的问题接踵而来,首当其冲的问题便是,明明没有人引用RubyGem,那么这个文件是谁通过怎样的方式载入的呢?再则,我们开启irb,这时候理当没有任何Gem被载入,可是发觉Gem这个模块已经被定义了是怎么回事呢?
啊,一定有谁在我们的代码执行前就载入了RubyGem!我在RubyGem的代码中添加了打印函数调用栈的逻辑,然后运行一个空的Ruby脚本,看到了如下的现象:
david@david-K40IN:~/Desktop/root$ ruby -e '' /home/david/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/site_ruby/1.9.1/rubygems.rb:1282:in `require' /home/david/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/site_ruby/1.9.1/rubygems.rb:1282:in `<top (required)>' <internal:gem_prelude>:1:in `require' <internal:gem_prelude>:1:in `<compiled>' 可以观察到是一个叫做gem_prelude的文件载入了RubyGem。这个文件是什么?前面的internal似乎显示了它不一样的地位。我搜遍Ruby的目录,也没有找到这么一个文件,却只是在Ruby的源码目录中找到了它的身影。 原来,这个文件是编译Ruby时自动生成的(这里讨论只是Ruby较新的版本(1.9.x),实现代码见此https://github.com/ruby/ruby/blob/trunk/tool/compile_prelude.rb),它的内容只有一句话,那便是 require 'RubyGem' if defined?(Gem) 。其中Gem符号是在ruby.c里直接定义的(Hardcode),如果你要取消该特性,编译Ruby的时候需要指明--disable-gems选项。
现在,问题的答案很明朗了。由于RubyGem使用地十分广泛,以至于Ruby开发团队决定予以其直接支持,这便是为什么我们总是发觉RubyGem被载入的原因了。这也同时更好地解释了,明明也是一个Gem,为什么RubyGem没有和其他Gem放到一块儿,并遵循Gem名加上版本号的命名方式。
RubyGem - 将宝石打包
咱们再来谈谈Ruby的包管理机制。这里的基本思路十分简单,Ruby本身载入某个代码只会在LOAD_PATH里寻找,如果我们定义"使用某个Gem"为将Gem所在路径添加到Ruby的LOAD_PATH里,这样当我们使用了某个Gem后,我们便能够载入这个Gem的代码了。其次,我们在包的根目录下放上某个包含诸如作者、主页、依赖的库等等信息的文件,这便有了Gem的元数据信息。最后,我们把Gem的根目录命名为Gem名加版本号,这样多版本的管理机制也就有了。于是乎,整个Gem的工作机制便呼之欲出了。
按照惯例,我们一般是用require 'arel'的方式来载入Gem代码。可是,根据require函数定义,我们实际上需要使用类似'gems/arel-3.0.2/arel'的参数传给require才能达到我们的目的。为什么简单的require 'arel'能行呢?因为我们在此之前使用了gem 'arel'语句,是它按照之前提到的规律找到了arel库某个版本的位置,并将它加入到LOAD_PATH里,这才使我们能够简单地require一个Gem库。
不过,正如上一节指出的,在新版本的Ruby里,Kernel#require早已自动被RubyGem里的同名函数覆盖了。因此,在新版本的Ruby里,我们连gem语句都不需要,可以直接require了(老版本则需要我们显式调用require 'rubygem'才行)。不过,若是你需要明确的指定使用某一版本的Gem(Gem 'arel', '>=3.0.0'),还是需要显示地调用gem方法。
RubyGem这个库具有两面性,上面的讨论仅是从Gem的使用者角度展开的。而RubyGem同时也给予了Gem库开发者以大量支持,但是我在这里不会讨论。
Bundler
好的,终于谈到它了,它是我最喜欢的一个工具。我在Linux下开发时间虽然不长,但是痛苦程度应该比起经验丰富的开发者也不遑多让。原因在于传统的Linux开发相当复杂,除了软件系统本身的复杂性外,还得受错综复杂的各种依赖关系所累。常常是一个程序还没开始编译,就得先安装个一天的各种依赖库再说。
但是,这个令我十分头痛的问题却被Bundler解决了,而且解决地十分漂亮。你的软件需要什么依赖库,具体依赖啥版本,你写成一个Gemfile清单来看。我check out你的代码后,啥也不管,简单地bundle install,开发环境就搭建好了,各种依赖库也到位了,好不痛快!
bundle install指令致力于确保Gem所有依赖库均被安装到本机,但它并不保证列在Gemfile里的依赖库在运行时被载入。为了让我们的程序使用上这些库,我们需要在运行时调用Bundler.setup,该方法将列举在Gemfile里的所有Gem被添加到LOAD_PATH中去。因此,Bundler.setup的行为类似于gem方法,用于帮助我们将特定版本的Gem载入到LOAD_PATH。只不过Bundler提供了更为高级的机制,使得我们能够在Gemfile里集中地管理所有依赖,并且省去了一一添加依赖的繁琐过程。
Bundler还提供了一个Bundler.require方法,该方法提供了比Bundler.setup更方便的特性,它将直接将Gemfile列举的依赖全部载入内存。关于使用Bundler.setup还是Bundler.require的讨论已经存在已久,无非就是Bundler.setup提供了一个妥协,使得程序可以滞后载入(Lazy Loading),从而减少不必要的加载,加快程序启动速度。而Bundler.require则主要是基于方便开发者(Programmer Friendly)的考量,它使开发者省去了大量的精力去显式地加载代码。
另外一个问题是有关Gemfile.lock文件的。我们是否需要check in这个文件到代码库里?这里的答案要度时而定。首先,我们知道Gemfile一般指明了一个依赖版本范围(或者没有),当我们运行bundle install的之后,生成的Gemfile.lock实际上是指明了每个依赖Gem的一个固定版本(在满足Gemfile指明的版本范围前提下)。
然后我们需要考虑这么一个convention,即我们开发Gem库的时候,我们总是希望我们的库能够和尽可能多版本的依赖Gem一同工作,而当我们开发应用的时候,我们往往希望我们依赖的Gem版本维持不变(因为此时的测试十分严格,将精确到Gem库的具体行为上),以保证我们的应用发布后十分稳定。
综合以上我们得出了结论,在开发Gem的时候,我们不添加Gemfile.lock到代码库,因为我们希望其他开发者通过bundle install绑定到依赖库尽可能多的版本,借此保证我们的Gem能够和更多的依赖库协同工作。而当我们开发应用之时,我们希望所有的开发者以及用户,严格的使用和我一样的依赖库版本,这使的每个人使用的依赖库行为严格一致,从而保证了应用的健壮性。
当Bundler遇见RubyGem - Gem开发者需要知道的
第一次使用bundler的时候,在为其精妙的设计而感叹的之际,一个疑问始终萦绕在我的心中:.gemspec和Gemfile这两个设计是不是过于冗余了?我们在开发Gem的时候,明明已经有.gemspec(RubyGem的一部分)指出依赖关系了,为什么此时Bundler还要鸡肋地设计一个Gemfile呢?
为了说明其原因,我们必须先回答一个基本问题:.gemspec和Gemfile分别是干嘛的?我们知道,.gemspec主要是用来描述Gem的元数据信息的,我们除了可以在此包含Gem的基本信息之外,还能够在此指出本Gem具体依赖于哪些其他Gem。不过,值得注意的是,这里仅仅是指出依赖关系,.gemspec并没有提供任何机制告诉我们,到哪里才能下载并部署这些被依赖的Gem。
.gemspec之所以缺少运行时的支持,那是因为下载、部署、以及载入并不是其设计之初的职责所在。这些问题是被后来者Bundler解决的。那么,既然搞清了其用途上的差异,我们又当如何解决其内容的冗余这个问题呢?答案很简单,在Gemfile文件中调用gemspec方法,它会自动告诉Bundler到同目录下查找.gemspec文件并载入其中指明的Gem依赖。
Rails的代码载入机制
Rails开发者倾向于不使用显式的代码载入机制,为了实现这个目的,Rails使用了大量的自动载入机制。其一便是autoload,关于它的原理,以后我会撰文剖析。autoload主要用于载入Rails自己的组件,而对于依赖Gem的载入,Rails使用了Bundler.require机制。在Rails项目的文件config/application.rb负责实现此特性:
# Assets should be precompiled for production (so we don't need the gems loaded then) Bundler.require(*Rails.groups(assets: %w(development test)))
写在最后 代码载入看似很简单,只不过是将代码读入内存并且编译。可是,将这个需求放到真正的工程世界之后,情况便大不相同了。我们需要同时管理多个版本的组件,我们需要载入特定版本的组件,我们还需要解析某个组件的依赖……诸如此类的问题将代码载入这个话题无限扩大了,以至于Ruby后来才有了RubyGem、Bundler等一系列的工具、程序库来解决这些问题。我们要了解这个话题,不仅仅是一个技术人热爱技术的本性使然,更是为了在现实世界复杂的开发、运行环境里,更好的实现我们的目的(DO Things Right)。愿与诸君共勉! |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论