Skip to content
  • Steven Danna's avatar
    Refactor manifest handling · 7c82b529
    Steven Danna authored
    This changeset attempts to reduce the number of places that behavior
    substantively changes based on the presence of an external manifest or
    not.  Key changes include
    
    - Fetchers now take a manifest entry in their constructor.  The
      manifest has no knowledge of how the entry was created and doesn't
      care.
    
    - Fetchers expect a fully resolved version in the manifest entry.
      Users can construct such a version using the
      #resolve_version(source, version) functions
    
    - Omnibus::Project only interacts with the manifest in 2 ways: (1)
      passes it to the Software when constructing software objects, and
      (2) polling the software collection for their manifest entries to
      present it to the user.
    
    - Omnibus::Software contains the main interaction with the manifest.
      When constructing a Fetcher, it passes its own manifest entry.
      Omnibus::Software#manifest_entry is now the only substantive place
      in the code where we do something different based on whether the
      user provided a manifest entry or not.
    7c82b529