Results for: "Pathname"

Generates a index files for use as a gem server.

See ‘gem help generate_index`

Raised when a bad requirement is encountered

Specifies a Specification object that should be activated. Also contains a dependency that was used to introduce this activation.

Represents a specification retrieved via the rubygems.org API.

This is used to avoid loading the full Specification object when all we need is the name, version, and dependencies.

A GitSpecification represents a gem that is sourced from a git repository and is being loaded through a gem dependencies file through the git: option.

Represents a possible Specification object returned from IndexSet. Used to delay needed to download full Specification objects when only the name and version are needed.

An InstalledSpecification represents a gem that is already installed locally.

A LocalSpecification comes from a .gem file on the local filesystem.

The LockSpecification comes from a lockfile (Gem::RequestSet::Lockfile).

A LockSpecification’s dependency information is pre-filled from the lockfile.

The RequirementList is used to hold the requirements being considered while resolving a set of gems.

The RequirementList acts like a queue where the oldest items are removed first.

The Resolver::SpecSpecification contains common functionality for Resolver specifications that are backed by a Gem::Specification.

A Resolver::Specification contains a subset of the information contained in a Gem::Specification. Only the information necessary for dependency resolution in the resolver is included.

A VendorSpecification represents a gem that has been unpacked into a project and is being loaded through a gem dependencies file through the path: option.

A progress reporter that behaves nicely with threaded downloading.

An object representation of a stack frame, initialized by Kernel#caller_locations.

For example:

# caller_locations.rb
def a(skip)
  caller_locations(skip)
end
def b(skip)
  a(skip)
end
def c(skip)
  b(skip)
end

c(0..2).map do |call|
  puts call.to_s
end

Running ruby caller_locations.rb will produce:

caller_locations.rb:2:in `a'
caller_locations.rb:5:in `b'
caller_locations.rb:8:in `c'

Here’s another example with a slightly different result:

# foo.rb
class Foo
  attr_accessor :locations
  def initialize(skip)
    @locations = caller_locations(skip)
  end
end

Foo.new(0..2).locations.map do |call|
  puts call.to_s
end

Now run ruby foo.rb and you should see:

init.rb:4:in `initialize'
init.rb:8:in `new'
init.rb:8:in `<main>'