inventory 1.5.2 → 1.5.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 65855cbefc445a1caa407505c0b105c02861f069
-  data.tar.gz: 07f5979d22d090655597189243fab92d37e6d759
+  metadata.gz: 75fad515b8fa98b3b72f1da68b76810c1edb2948
+  data.tar.gz: 02f9ab6cf322c11c73c91b2c906b6cd1cd793ae5
 SHA512:
-  metadata.gz: 9d17eaac3626704ba91262e8f4eabadce50a640ea3f48ba3012c7c5fb3a434e461f8816a6842c457a1e53c8b8d6ef4dcefa96b517ecb4a68e86c5aa9fe9c9955
-  data.tar.gz: 7a3623a3a5215f22f164b6a6c9cef0208174b2c28bdc522e82bff48aabe18203f1c3e1e2c3baa9fde30c1bfb5ede325acce07aae66b9939f74c3a3ccb32def57
+  metadata.gz: 198a24f73497b6a3eb452802532dcc171b3d397aec0ece265283bd414713562a2b6c28a31c95fa30bb3f96b2baeaaa0d88d2f41483f7d545d12a19a78d247eb3
+  data.tar.gz: 7618e645686cd37ebcf46d164ff22b2fb2f1e192fb4504000e89d6d62cebb9155b882b038cbff39128262a29e42544a8fa6b13cec70af805d5c136ed4b97c99d

data/README

@@ -187,16 +187,16 @@
 
 ¹ Ruby project structure: http://guides.rubygems.org/make-your-own-gem/
 ² Semantic versioning: http://semver.org/
-³ Inventory-Rake: http://disu.se/software/inventory-rake/
+³ Inventory-Rake: http://disu.se/software/inventory-rake-1.0/
 ⁴ Travis: http://travis-ci.org/
-⁵ Lookout-Rake: http://disu.se/software/lookout-rake/
+⁵ Lookout-Rake: http://disu.se/software/lookout-rake-3.0/
 
 § API
 
     If the guide above doesn’t provide you with all the answers you seek, you
     may refer to the API¹ for more answers.
 
-¹ See http://disu.se/software/inventory/api/Inventory/
+¹ See http://disu.se/software/inventory-1.0/api/Inventory/
 
 § Financing
 

data/lib/inventory-1.0.rb

@@ -3,8 +3,8 @@
 # An Inventory keeps track of your Ruby project’s {Inventory#to_s version} and
 # its {Inventory#to_a content}.  It also allows you to {#load} your project’s
 # source files in a simple manner and track its {#dependencies}.  Add-ons, such
-# as [Inventory-Rake](http://disu.se/software/inventory-rake/) and
-# [Inventory-Rake-Tasks-YARD](http://disu.se/software/inventory-rake-tasks-yard),
+# as [Inventory-Rake](http://disu.se/software/inventory-rake-1.0/) and
+# [Inventory-Rake-Tasks-YARD](http://disu.se/software/inventory-rake-tasks-yard-1.0/),
 # can also use this information to great effect.
 #
 # The basic usage pattern is to set your project’s Version constant to an
@@ -121,7 +121,8 @@ class Inventory
   # @raise [RuntimeError] If no block has been given and no authors have previously been set
   def authors
     @authors = Authors.new(&Proc.new) if block_given?
-    raise 'no authors defined in inventory of %s' % self if not defined? @authors or @authors.count == 0
+    raise 'no authors defined in inventory of %s %s' % [package, self] if
+      not defined? @authors or @authors.count == 0
     @authors
   end
 
@@ -133,7 +134,8 @@ class Inventory
   #   set
   def homepage(value = nil)
     return @homepage = value if value
-    raise 'no homepage set in inventory of %s' % self if not defined? @homepage
+    raise 'no homepage set in inventory of %s %s' % [package, self] if
+      not defined? @homepage
     @homepage
   end
 
@@ -147,7 +149,8 @@ class Inventory
   #   previously been set
   def licenses
     @licenses = Licenses.new(&Proc.new) if block_given?
-    raise 'no licenses defined in inventory of %s' % self if not defined? @licenses or @licenses.count == 0
+    raise 'no licenses defined in inventory of %s %s' % [package, self] if
+      not defined? @licenses or @licenses.count == 0
     @licenses
   end
 

data/lib/inventory-1.0/author.rb

@@ -10,8 +10,8 @@ class Inventory::Author
     @name, @email = name, email
   end
 
-  # @return [String] The {#name} and {#email} of the author on the “name
-  #   <email>” format
+  # @return [String] The {#name} and {#email} of the author on the
+  #   “`name <email>`” format
   def to_s
     '%s <%s>' % [name, email]
   end

data/lib/inventory-1.0/extension.rb

@@ -7,7 +7,7 @@
 #
 # For an inventory, an extension is a set of files that should be included in
 # the project and can contain multiple extensions.
-# [Inventory-Rake](http://disu.se/software/inventory-rake/) uses information
+# [Inventory-Rake](http://disu.se/software/inventory-rake-1.0/) uses information
 # found in these extensions to compile them for use from Ruby code.
 class Inventory::Extension
   # Creates an extension named NAME.  A block may be given that’ll be

data/lib/inventory-1.0/version.rb

@@ -1,7 +1,7 @@
 # -*- coding: utf-8 -*-
 
 class Inventory
-  Version = Inventory.new(1, 5, 2){
+  Version = Inventory.new(1, 5, 3){
     def authors
       Authors.new{
         author 'Nikolai Weibull', 'now@disu.se'
@@ -9,7 +9,7 @@ class Inventory
     end
 
     def homepage
-      'http://disu.se/software/inventory/'
+      'http://disu.se/software/inventory-1.0/'
     end
 
     def licenses

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: inventory
 version: !ruby/object:Gem::Version
-  version: 1.5.2
+  version: 1.5.3
 platform: ruby
 authors:
 - Nikolai Weibull
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-09-09 00:00:00.000000000 Z
+date: 2015-10-31 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: inventory-rake
@@ -97,45 +97,45 @@ dependencies:
 description: |2
                                      Inventory
 
-    Inventory keeps track of the contents of your Ruby┬╣ projects.  Such an
+    Inventory keeps track of the contents of your Ruby¹ projects.  Such an
     inventory can be used to load the project, create gem specifications and
-    gems, run unit tests, compile extensions, and verify that the projectΓÇÖs
+    gems, run unit tests, compile extensions, and verify that the project’s
     content is what you think it is.
 
-  ┬╣ See http://ruby-lang.org/
-
-  § Usage
-
-      LetΓÇÖs begin by discussing the project structure that Inventory expects you
-      to use.  ItΓÇÖs pretty much exactly the same as the standard Ruby project
-      structure┬╣:
-
-        Γö£ΓöÇΓöÇ README
-        Γö£ΓöÇΓöÇ Rakefile
-        Γö£ΓöÇΓöÇ lib
-        Γöé   Γö£ΓöÇΓöÇ foo-1.0
-        Γöé   Γöé   Γö£ΓöÇΓöÇ bar.rb
-        Γöé   Γöé   ΓööΓöÇΓöÇ version.rb
-        Γöé   ΓööΓöÇΓöÇ foo-1.0.rb
-        ΓööΓöÇΓöÇ test
-            ΓööΓöÇΓöÇ unit
-                Γö£ΓöÇΓöÇ foo-1.0
-                Γöé   Γö£ΓöÇΓöÇ bar.rb
-                Γöé   ΓööΓöÇΓöÇ version.rb
-                ΓööΓöÇΓöÇ foo-1.0.rb
-
-      Here you see a simplified version of a project called ΓÇ£FooΓÇ¥ΓÇÖs project
+  ¹ See http://ruby-lang.org/
+
+  § Usage
+
+      Let’s begin by discussing the project structure that Inventory expects you
+      to use.  It’s pretty much exactly the same as the standard Ruby project
+      structure¹:
+
+        ├── README
+        ├── Rakefile
+        ├── lib
+        │   ├── foo-1.0
+        │   │   ├── bar.rb
+        │   │   └── version.rb
+        │   └── foo-1.0.rb
+        └── test
+            └── unit
+                ├── foo-1.0
+                │   ├── bar.rb
+                │   └── version.rb
+                └── foo-1.0.rb
+
+      Here you see a simplified version of a project called “Foo”’s project
       structure.  The only real difference from the standard is that the main
-      entry point into the library is named ΓÇ£foo-1.0.rbΓÇ¥ instead of ΓÇ£foo.rbΓÇ¥ and
-      that the root sub-directory of ΓÇ£libΓÇ¥ is similarly named ΓÇ£foo-1.0ΓÇ¥ instead
-      of ΓÇ£fooΓÇ¥.  The difference is the inclusion of the API version.  This must
-      be the major version of the project followed by a constant ΓÇ£.0ΓÇ¥.  The
+      entry point into the library is named “foo-1.0.rb” instead of “foo.rb” and
+      that the root sub-directory of “lib” is similarly named “foo-1.0” instead
+      of “foo”.  The difference is the inclusion of the API version.  This must
+      be the major version of the project followed by a constant “.0”.  The
       reason for this is that it allows concurrent installations of different
       major versions of the project and means that the wrong version will never
       accidentally be loaded with require.
 
-      ThereΓÇÖs a bigger difference in the content of the files.
-      ‹Lib/foo-1.0/version.rb› will contain our inventory instead of a String:
+      There’s a bigger difference in the content of the files.
+      ‹Lib/foo-1.0/version.rb› will contain our inventory instead of a String:
 
         require 'inventory-1.0'
 
@@ -167,33 +167,33 @@ description: |2
           }
         end
 
-      WeΓÇÖre introducing quite a few concepts at once, and weΓÇÖll look into each in
-      greater detail, but we begin by setting the ‹Version› constant to a new
+      We’re introducing quite a few concepts at once, and we’ll look into each in
+      greater detail, but we begin by setting the ‹Version› constant to a new
       instance of an Inventory with major, minor, and patch version atoms 1, 4,
       and 0.  Then we add a couple of dependencies and list the library files
       that are included in this project.
 
-      The version numbers shouldnΓÇÖt come as a surprise.  These track the version
-      of the API that weΓÇÖre shipping using {semantic versioning}┬▓.  They also
-      allow the Inventory#to_s method to act as if youΓÇÖd defined Version as
-      ‹'1.4.0'›.
+      The version numbers shouldn’t come as a surprise.  These track the version
+      of the API that we’re shipping using {semantic versioning}².  They also
+      allow the Inventory#to_s method to act as if you’d defined Version as
+      ‹'1.4.0'›.
 
-      Next follows information about the authors of the project, the projectΓÇÖs
-      homepage, and the projectΓÇÖs licenses.  Each author has a name and an email
+      Next follows information about the authors of the project, the project’s
+      homepage, and the project’s licenses.  Each author has a name and an email
       address.  The homepage is simply a string URL.  Licenses have an
       abbreviation, a name, and a URL where the license text can be found.
 
-      We then extend the definition of ‹dependencies› by adding another set of
-      dependencies to ‹super›.  ‹Super› includes a dependency on the version of
-      the inventory project thatΓÇÖs being used with this project, so youΓÇÖll never
+      We then extend the definition of ‹dependencies› by adding another set of
+      dependencies to ‹super›.  ‹Super› includes a dependency on the version of
+      the inventory project that’s being used with this project, so you’ll never
       have to list that yourself.  The other three dependencies are all of
       different kinds: development, runtime, and optional.  A development
-      dependency is one thatΓÇÖs required while developing the project, for
+      dependency is one that’s required while developing the project, for
       example, a unit-testing framework, a documentation generator, and so on.
       Runtime dependencies are requirements of the project to be able to run,
       both during development and when installed.  Finally, optional dependencies
       are runtime dependencies that may or may not be required during execution.
-      The difference between runtime and optional is that the inventory wonΓÇÖt try
+      The difference between runtime and optional is that the inventory won’t try
       to automatically load an optional dependency, instead leaving that up to
       you to do when and if it becomes necessary.  By that logic, runtime
       dependencies will be automatically loaded, which is a good reason for
@@ -205,38 +205,38 @@ description: |2
 
       As mentioned, runtime dependencies will be automatically loaded and the
       feature they try to load is based on the name of the dependency with a
-      ΓÇ£-X.0ΓÇ¥ tacked on the end, where ΓÇÿXΓÇÖ is the major version of the dependency.
-      Sometimes, this isnΓÇÖt correct, in which case the :feature option may be
+      “-X.0” tacked on the end, where ‘X’ is the major version of the dependency.
+      Sometimes, this isn’t correct, in which case the :feature option may be
       given to specify the name of the feature.
 
       You may also override other parts of a dependency by passing in a block to
-      the dependency, much like weΓÇÖre doing for inventories.
+      the dependency, much like we’re doing for inventories.
 
       The rest of an inventory will list the various files included in the
       project.  This project only consists of one additional file to those that
       an inventory automatically include (Rakefile, README, the main entry point,
       and the version.rb file that defines the inventory itself), namely the
-      library file ‹bar.rb›.  Library files will be loaded automatically when the
-      main entry point file loads the inventory.  Library files that shouldnΓÇÖt be
-      loaded may be listed under a different heading, namely ΓÇ£additional_libsΓÇ¥.
+      library file ‹bar.rb›.  Library files will be loaded automatically when the
+      main entry point file loads the inventory.  Library files that shouldn’t be
+      loaded may be listed under a different heading, namely “additional_libs”.
       Both these sets of files will be used to generate a list of unit test files
       automatically, so each library file will have a corresponding unit test
-      file in the inventory.  WeΓÇÖll discuss the different headings of an
+      file in the inventory.  We’ll discuss the different headings of an
       inventory in more detail later on.
 
-      Now that weΓÇÖve written our inventory, letΓÇÖs set it up so that itΓÇÖs content
+      Now that we’ve written our inventory, let’s set it up so that it’s content
       gets loaded when our main entry point gets loaded.  We add the following
-      piece of code to ‹lib/foo-1.0.rb›:
+      piece of code to ‹lib/foo-1.0.rb›:
 
         module Foo
           load File.expand_path('../foo-1.0/version.rb', __FILE__)
           Version.load
         end
 
-      ThatΓÇÖs all thereΓÇÖs to it.
+      That’s all there’s to it.
 
       The inventory can also be used to great effect from a Rakefile using a
-      separate project called Inventory-Rake┬│.  Using itΓÇÖll give us tasks for
+      separate project called Inventory-Rake³.  Using it’ll give us tasks for
       cleaning up our project, compiling extensions, installing dependencies,
       installing and uninstalling the project itself, and creating and pushing
       distribution files to distribution points.
@@ -252,16 +252,16 @@ description: |2
           Lookout::Rake::Tasks::Test.new
         end
 
-      It’s ‹Inventory::Rake::Tasks.define› that does the heavy lifting.  It takes
+      It’s ‹Inventory::Rake::Tasks.define› that does the heavy lifting.  It takes
       our inventory and sets up the tasks mentioned above.
 
       As we want to be able to use our Rakefile to install our dependencies for
       us, the rest of the Rakefile is inside the conditional
       #unless_installing_dependencies, which, as the name certainly implies,
       executes its block unless the task being run is the one that installs our
-      dependencies.  This becomes relevant when we set up Travis⁴ integration
+      dependencies.  This becomes relevant when we set up Travis⁴ integration
       next.  The only conditional set-up we do in our Rakefile is creating our
-      test task via Lookout-Rake⁵, which also uses our inventory to find the unit
+      test task via Lookout-Rake⁵, which also uses our inventory to find the unit
       tests to run when executed.
 
       Travis integration is straightforward.  Simply put
@@ -270,9 +270,9 @@ description: |2
           - gem install inventory-rake -v '~> VERSION' --no-rdoc --no-ri
           - rake gem:deps:install
 
-      in the project’s ‹.travis.yml› file, replacing ‹VERSION› with the version
-      of Inventory-Rake that you require.  ThisΓÇÖll make sure that Travis installs
-      all development, runtime, and optional dependencies that youΓÇÖve listed in
+      in the project’s ‹.travis.yml› file, replacing ‹VERSION› with the version
+      of Inventory-Rake that you require.  This’ll make sure that Travis installs
+      all development, runtime, and optional dependencies that you’ve listed in
       your inventory before running any tests.
 
       You might also need to put
@@ -280,22 +280,22 @@ description: |2
         env:
           - RUBYOPT=rubygems
 
-      in your ‹.travis.yml› file, depending on how things are set up.
+      in your ‹.travis.yml› file, depending on how things are set up.
 
-  ┬╣ Ruby project structure: http://guides.rubygems.org/make-your-own-gem/
-  ┬▓ Semantic versioning: http://semver.org/
-  ┬│ Inventory-Rake: http://disu.se/software/inventory-rake/
-  ⁴ Travis: http://travis-ci.org/
-  ⁵ Lookout-Rake: http://disu.se/software/lookout-rake/
+  ¹ Ruby project structure: http://guides.rubygems.org/make-your-own-gem/
+  ² Semantic versioning: http://semver.org/
+  ³ Inventory-Rake: http://disu.se/software/inventory-rake-1.0/
+  ⁴ Travis: http://travis-ci.org/
+  ⁵ Lookout-Rake: http://disu.se/software/lookout-rake-3.0/
 
-  § API
+  § API
 
-      If the guide above doesnΓÇÖt provide you with all the answers you seek, you
-      may refer to the API┬╣ for more answers.
+      If the guide above doesn’t provide you with all the answers you seek, you
+      may refer to the API¹ for more answers.
 
-  ┬╣ See http://disu.se/software/inventory/api/Inventory/
+  ¹ See http://disu.se/software/inventory-1.0/api/Inventory/
 
-  § Financing
+  § Financing
 
       Currently, most of my time is spent at my day job and in my rather busy
       private life.  Please motivate me to spend time on this piece of software
@@ -305,31 +305,31 @@ description: |2
       to have other people give me the things that I need to continue living
       under the rules of said society.  So, if you feel that this piece of
       software has helped you out enough to warrant a reward, please PayPal a
-      donation to now@disu.se┬╣.  Thanks!  Your support wonΓÇÖt go unnoticed!
+      donation to now@disu.se¹.  Thanks!  Your support won’t go unnoticed!
 
-  ┬╣ Send a donation:
+  ¹ Send a donation:
     https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=Inventory
 
-  § Reporting Bugs
+  § Reporting Bugs
 
-      Please report any bugs that you encounter to the {issue tracker}┬╣.
+      Please report any bugs that you encounter to the {issue tracker}¹.
 
-    ┬╣ See https://github.com/now/inventory/issues
+    ¹ See https://github.com/now/inventory/issues
 
-  § Authors
+  § Authors
 
       Nikolai Weibull wrote the code, the tests, the documentation, and this
       README.
 
-  § Licensing
+  § Licensing
 
       Inventory is free software: you may redistribute it and/or modify it under
-      the terms of the {GNU Lesser General Public License, version 3}┬╣ or later┬▓,
-      as published by the {Free Software Foundation}┬│.
+      the terms of the {GNU Lesser General Public License, version 3}¹ or later²,
+      as published by the {Free Software Foundation}³.
 
-  ┬╣ See http://disu.se/licenses/lgpl-3.0/
-  ┬▓ See http://gnu.org/licenses/
-  ┬│ See http://fsf.org/
+  ¹ See http://disu.se/licenses/lgpl-3.0/
+  ² See http://gnu.org/licenses/
+  ³ See http://fsf.org/
 email:
 - now@disu.se
 executables: []
@@ -362,7 +362,7 @@ files:
 - test/unit/inventory-1.0/version.rb
 - README
 - Rakefile
-homepage: http://disu.se/software/inventory/
+homepage: http://disu.se/software/inventory-1.0/
 licenses:
 - LGPLv3+
 metadata: {}
@@ -382,8 +382,8 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.0.2
+rubygems_version: 2.0.14
 signing_key: 
 specification_version: 4
-summary: Inventory keeps track of the contents of your Ruby┬╣ projects.
+summary: Inventory keeps track of the contents of your Ruby¹ projects.
 test_files: []