add "packages" resource #1458

jtimberman · 2017-02-03T20:52:17Z

This pull request adds a packages resource so that we can check for pattern matches against all the packages on a system. This initially implements only dpkg support for debian-based platforms so we can cover this use case:

describe packages(/^xserver-xorg.*/) do
  its("list") { should be_empty }
end

This uses FilterTable so we can supply additional queries, too.

describe packages(/vi.+/).where { status != 'installed' } do
  its('statuses') { should be_empty }
end

Users can specify the name as a string or a regular expression. If it is a string, we will escape it and convert it to a regular expression to use in matching against the full returned list of packages. If it is a regular expression, we take that as is and use it to filter the results.

While some package management systems such as dpkg can take a shell glob argument to filter their results, we eschew this and require a regular expression to match multiple package names because we will need this to work across other platforms in the future. This means that the following:

packages("vim")

Will return all the "vim" packages on the system. The packages resource will take "vim", turn it into /vim/, and greedily match anything with "vim" in the name. To match only a single package named vim, it needs to be an anchored regular expression.

packages(/^vim$/)

alexpop · 2017-02-06T15:03:44Z

I added a few commits to use the more standard entries, add a few more tests, fix lint.

list as an attribute only works on the main resource(i.e. packages("xserver-xorg*").list) where entries works on the main resource + on where filter(i.e. packages("xserver-xorg*").where { status == 'installed' }.entries)

alexpop · 2017-02-06T15:40:41Z

lib/resources/packages.rb

+    # a regular expression. let's make sure that the pattern gets
+    # converted to a regular expression
+    def pattern_regexp(p)
+      shmap = { '*'=>'.*', '?' => '.', '[' => '[', ']' => ']' }


What's the deal with the "[" and "]" replaces? They don't seem to do much:

[9] pry(main)> "vim][".gsub(/(.)/) { |w| shmap[w] || w } => "vim]["

alexpop · 2017-02-06T16:18:02Z

lib/resources/packages.rb

+      return [] if all.nil?
+      all.map do |m|
+        a = m.split
+        a[0] = 'installed' if a[0] =~ /^ii/


So only installed status is expanded, what about these combinations?

Desired action: u = Unknown i = Install h = Hold r = Remove p = Purge Package status: n = Not-installed c = Config-files H = Half-installed U = Unpacked F = Half-configured W = Triggers-awaiting t = Triggers-pending i = Installed

I've added in the output two packages what have the two status characters rc

Ignore the desired action for now. Let's focus on the actual state of the package. We will keep them separate in the future. I.e.:

match(/^([uihrp])([ncHUFWti])\s/) => res[1] we will ignore for now, it is part of a future field for desired state => res[2] is the status, we support installed right now

We will establish installed as a shared status across all OS. The others are ok to be os-specific for now. imho implement as lowercase with spaces, e.g. not installed. Do not export the other status types for now, just stick to installed + open the others in a RFC. Sync with the package resource.

arlimus

Awesome work thank you so much!! 😄 Just 2 tiny comments

arlimus · 2017-02-06T16:56:34Z

lib/resources/packages.rb

+      return [] if all.nil?
+      all.map do |m|
+        a = m.split
+        a[0] = 'installed' if a[0] =~ /^ii/


Ignore the desired action for now. Let's focus on the actual state of the package. We will keep them separate in the future. I.e.:

match(/^([uihrp])([ncHUFWti])\s/) => res[1] we will ignore for now, it is part of a future field for desired state => res[2] is the status, we support installed right now

We will establish installed as a shared status across all OS. The others are ok to be os-specific for now. imho implement as lowercase with spaces, e.g. not installed. Do not export the other status types for now, just stick to installed + open the others in a RFC. Sync with the package resource.

arlimus · 2017-02-06T16:56:55Z

test/unit/mock/cmd/dpkg-query-W

+ii  xz-utils 5.1.1alpha+20120614-2ubuntu2
+ii  zerofree 1.0.3-1
+ii  zlib1g 1:1.2.8.dfsg-2ubuntu4
+ii  zlib1g-dev 1:1.2.8.dfsg-2ubuntu4


Let's shorten this just to the necessary lines

arlimus · 2017-02-06T17:09:27Z

Just one more thing: I think we should keep the string as a non-regex only check. i.e. no glob expression. Keep regex'y behavior to real regex input for the packages initialization. Kudos again!

jtimberman · 2017-02-06T19:47:13Z

Don't merge yet - I'm going to rebase and rewrite the original commit message to match reality.

jtimberman · 2017-02-06T20:00:59Z

This is ready for review/merge.

This pull request adds a packages resource so that we can check for pattern matches against all the packages on a system. This initially implements only dpkg support for debian-based platforms so we can cover this use case: ```ruby describe packages(/^xserver-xorg.*/) do its("list") { should be_empty } end ``` This uses FilterTable so we can supply additional queries, too. ```ruby describe packages(/vi.+/).where { status != 'installed' } do its('statuses') { should be_empty } end ``` Users can specify the name as a string or a regular expression. If it is a string, we will escape it and convert it to a regular expression to use in matching against the full returned list of packages. If it is a regular expression, we take that as is and use it to filter the results. While some package management systems such as `dpkg` can take a shell glob argument to filter their results, we eschew this and require a regular expression to match multiple package names because we will need this to work across other platforms in the future. This means that the following: ```ruby packages("vim") ``` Will return *all* the "vim" packages on the system. The `packages` resource will take `"vim"`, turn it into `/vim/`, and greedily match anything with "vim" in the name. To match only a single package named `vim`, it needs to be an anchored regular expression. ```ruby packages(/^vim$/) ``` Signed-off-by: Joshua Timberman <joshua@chef.io> Use entries instead of list Added a few more tests and non installed package in output Signed-off-by: Alex Pop <apop@chef.io> fix lint Signed-off-by: Alex Pop <apop@chef.io> Signed-off-by: Joshua Timberman <joshua@chef.io>

alexpop · 2017-02-07T10:31:26Z

👍 for the current version. Thanks for the great work Joshua!

arlimus · 2017-02-07T12:59:06Z

Awesome work and huge kudos for adding it Joshua!!
👍

adamhjk added the in progress label Feb 3, 2017

alexpop force-pushed the jtimberman/packages-resource branch from 427e7f6 to f40c5a4 Compare February 6, 2017 15:03

alexpop reviewed Feb 6, 2017

View reviewed changes

arlimus reviewed Feb 6, 2017

View reviewed changes

jtimberman self-assigned this Feb 6, 2017

jtimberman force-pushed the jtimberman/packages-resource branch from ae153a2 to 3c3d637 Compare February 6, 2017 19:54

alexpop force-pushed the jtimberman/packages-resource branch from 707dc18 to d7fad68 Compare February 7, 2017 10:29

arlimus merged commit e41ec1f into master Feb 7, 2017

arlimus deleted the jtimberman/packages-resource branch February 7, 2017 12:59

arlimus added Type: Enhancement Improves an existing feature and removed in progress labels Feb 7, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add "packages" resource #1458

add "packages" resource #1458

jtimberman commented Feb 3, 2017 •

edited

Loading

alexpop commented Feb 6, 2017 •

edited

Loading

alexpop Feb 6, 2017

alexpop Feb 6, 2017

arlimus Feb 6, 2017 •

edited

Loading

arlimus left a comment

arlimus Feb 6, 2017 •

edited

Loading

arlimus Feb 6, 2017

arlimus commented Feb 6, 2017

jtimberman commented Feb 6, 2017

jtimberman commented Feb 6, 2017

alexpop commented Feb 7, 2017

arlimus commented Feb 7, 2017

add "packages" resource #1458

add "packages" resource #1458

Conversation

jtimberman commented Feb 3, 2017 • edited Loading

alexpop commented Feb 6, 2017 • edited Loading

alexpop Feb 6, 2017

Choose a reason for hiding this comment

alexpop Feb 6, 2017

Choose a reason for hiding this comment

arlimus Feb 6, 2017 • edited Loading

Choose a reason for hiding this comment

arlimus left a comment

Choose a reason for hiding this comment

arlimus Feb 6, 2017 • edited Loading

Choose a reason for hiding this comment

arlimus Feb 6, 2017

Choose a reason for hiding this comment

arlimus commented Feb 6, 2017

jtimberman commented Feb 6, 2017

jtimberman commented Feb 6, 2017

alexpop commented Feb 7, 2017

arlimus commented Feb 7, 2017

jtimberman commented Feb 3, 2017 •

edited

Loading

alexpop commented Feb 6, 2017 •

edited

Loading

arlimus Feb 6, 2017 •

edited

Loading

arlimus Feb 6, 2017 •

edited

Loading