Ruby/Introduction

From ALT Linux Wiki
< Ruby
Revision as of 13:51, 12 December 2023 by Majioa (talk | contribs) (Created page with "== Introduction == === Ruby and modularity === NOTE: To simplify link usage, they will be treated as for 2.6.1 ruby version. The ruby language have the modularity feature begginging with the day-spring of its invention in 1993th, so if we have [http://ruby-doc.org/core-2.6.1/all the core functions of ruby] are placed into the ''libruby.so'', are built-in part of the language, then [http://ruby-doc.org/stdlib-2.6.1/ ruby's standard library] is modularized, and its modu...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

Ruby and modularity

NOTE: To simplify link usage, they will be treated as for 2.6.1 ruby version.

The ruby language have the modularity feature begginging with the day-spring of its invention in 1993th, so if we have the core functions of ruby are placed into the libruby.so, are built-in part of the language, then ruby's standard library is modularized, and its modules are resided in the /usr/lib/ruby/ folder that has the interpreted modules inside the consequently named folders. For example: parser module is placed in the racc module:

   /usr/lib/ruby/racc/parser.rb

Inside the folder named as <arch>-<os>, there are some compiled parts for the respective modules, so 'cparse modules is placed in racc module:

   /usr/lib/ruby/x86_64-linux/racc/cparse.so

Therefore the when a side library (module) ought to be be used in ordinal ruby applications, then its library modules must be placed into the respective folders in /usr/lib/ruby/site_ruby/, and the last is the only place to reside libraries not from the ruby standard set.

The the modern context, which is valid for 2019, in order to deploy additional modules, the rubygems and bundler modules are used, which kind of the modules is called as gem, and the first of them previously treated as usual ruby side module. The rubygems has begun in 2009 Apr., bundler in four months last than rubygems in Aug the same year. In present, the pair of the gems is de-facto an de-jure the only dynamically working system of dependencies of ruby modules system.

In modern projects the ruby gem dependencies can be provided with two ways:

  • via <gem>.gemspec;
  • via Gemfile.

The .gemspec is the only file to declare dependencies for rubygems between the gems themselves. The dependencies in the file can be joined into two groups separately: runtime, and development, and the least can be used also to test the gem project.

The Gemfile is the file to define local dependencies (additionally to .gemspec) from the other gems. The project containing the Gemfile counkl not be exactly the gem, but it can be one of the modern ruby application type as: rails or sinatra application, ruby script application. The dependencies can be joined into various kinds of groups along the default one like production, development, test, assets etc. Based on the current environment and written in the Gemfile scheme, the bundler makes a decision itself, which the gems shall be loaded, and which must be hidden that leads to situation when explicit declaration to call a module from a gem will be avoided. For example it can be observed in rails application like chef or foreman, or script application opennebula.

Typical Gemfile can be found here.

Dependencies to ruby also can be defined in Gemfile or .gemspec.

Versioning

In the ruby and its packaging subsystem the semantic versioning approach is applied, in which the first number responds to the major modification in the module, saying when the API is changed. The second number - minor modification, for example when a new feature is added to the module, and the third number means the patch change.