clamp 1.3.0 default_XXX method behavior breaking fpm

[mrtazz]

It seems like clamp's new behavior for default methods (introduced in mdub/clamp@ec192bf and released with version 1.3.0) breaks fpm with the following error:

/usr/local/lib/ruby/gems/2.4/gems/fpm-1.10.2/lib/fpm/command.rb:397:in `block in execute': undefined method `default_architecture' for #<FPM::Command:0x000000080462f870> (NoMethodError)
        from /usr/local/lib/ruby/gems/2.4/gems/fpm-1.10.2/lib/fpm/command.rb:403:in `execute'
        from /usr/local/lib/ruby/gems/2.4/gems/clamp-1.3.0/lib/clamp/command.rb:66:in `run'
        from /usr/local/lib/ruby/gems/2.4/gems/fpm-1.10.2/lib/fpm/command.rb:575:in `run'
        from /usr/local/lib/ruby/gems/2.4/gems/clamp-1.3.0/lib/clamp/command.rb:140:in `run'
        from /usr/local/lib/ruby/gems/2.4/gems/fpm-1.10.2/bin/fpm:7:in `<top (required)>'
        from /usr/local/bin/fpm:23:in `load'
        from /usr/local/bin/fpm:23:in `<main>'

[jordansissel]

Can you show me how to reproduce this error?

If I test ruby 2.5.1p57 with rubygems 2.7.6, gem install fpm installs clamp 1.0.1:

% gem install fpm
Fetching: clamp-1.0.1.gem (100%)
Successfully installed clamp-1.0.1
Fetching: fpm-1.10.2.gem (100%)
Successfully installed fpm-1.10.2
2 gems installed

Did rubygems behavior of ~> change recently to cause 1.3.0 to selected instead?

[mrtazz]

I'll try to see how I got to this error. Now that I think about it again there is a decent chance that this is more a bug with the FreeBSD port as it doesn't specify this tight of a dependency and has the newer clamp gem in the tree.

[kovetskiy]

@mrtazz @jordansissel I have different project that uses clamp and it requires clamp > 1.3.0, since fpm doesn't require version to be less than <1.3.0 ruby just uses newest version available in /usr/lib/ruby/gems/.

[jordansissel]

@kovetskiy good enough for me. I'll try to figure out why clamp 1.3.0 is giving fpm issues.

[jordansissel]

I am able to reproduce an error with clamp 1.3.0:

% bundle exec bin/fpm  -s gem -t deb rails
bundler: failed to load command: bin/fpm (bin/fpm)
NoMethodError: undefined method `default_architecture' for #<FPM::Command:0x005579fa0ff3b0>
Did you mean?  default_attrs
  /home/jls/projects/fpm/lib/fpm/command.rb:397:in `block in execute'
  /home/jls/projects/fpm/lib/fpm/command.rb:402:in `execute'
  /home/jls/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/clamp-1.3.0/lib/clamp/command.rb:66:in `run'
  /home/jls/projects/fpm/lib/fpm/command.rb:574:in `run'
  /home/jls/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/clamp-1.3.0/lib/clamp/command.rb:140:in `run'
  bin/fpm:7:in `<top (required)>'

I'll see about fixing this.

[jordansissel]

I think I have a fix for this and thankfully it's just one line (so far). I'll do some testing on clamp 1.3.0 and <1.3.0 and push a PR shortly.

[jordansissel]

#1561 should fix this. Can someone help test?

I tested with clamp 1.3.0 and clamp 1.0.1 on ruby 2.4.1 with a simple example bin/fpm -s gem -t deb rails and it fails without this PR, and succeeds with this PR.

[rorysavage77]

This issue still persists, can we get the PR accepted?

[rorysavage77]

See

~/dvn-personal/dvn-kubernetes/rpm/rpmpackageroot (dev/engineering ✘)✖✭ ᐅ fpm --rpm-os linux -a native -s dir -t rpm -n "kubelet" -v 1.12.2 -C . --iteration dvn
/Library/Ruby/Gems/2.3.0/gems/fpm-1.10.2/lib/fpm/command.rb:397:in `block in execute': undefined method `default_architecture' for #<FPM::Command:0x00007fb8df187eb0> (NoMethodError)
Did you mean?  default_attrs
	from /Library/Ruby/Gems/2.3.0/gems/fpm-1.10.2/lib/fpm/command.rb:402:in `execute'
	from /Library/Ruby/Gems/2.3.0/gems/clamp-1.3.0/lib/clamp/command.rb:66:in `run'
	from /Library/Ruby/Gems/2.3.0/gems/fpm-1.10.2/lib/fpm/command.rb:574:in `run'
	from /Library/Ruby/Gems/2.3.0/gems/clamp-1.3.0/lib/clamp/command.rb:140:in `run'
	from /Library/Ruby/Gems/2.3.0/gems/fpm-1.10.2/bin/fpm:7:in `<top (required)>'
	from /usr/local/bin/fpm:22:in `load'
	from /usr/local/bin/fpm:22:in `<main>'
~/dvn-personal/dvn-kubernetes/rpm/rpmpackageroot (dev/engineering ✘)✖✭ ᐅ sudo vim /Library/Ruby/Gems/2.3.0/gems/fpm-1.10.2/lib/fpm/command.rb
~/dvn-personal/dvn-kubernetes/rpm/rpmpackageroot (dev/engineering ✘)✖✭ ᐅ sudo gem uninstall clamp --version 1.3.0
Successfully uninstalled clamp-1.3.0
~/dvn-personal/dvn-kubernetes/rpm/rpmpackageroot (dev/engineering ✘)✖✭ ᐅ fpm --rpm-os linux -a all -s dir -t rpm -n "kubelet" -v 1.12.2 -C . --iteration dvn
Created package {:path=>"kubelet-1.12.2-dvn.noarch.rpm"}

[chnrxn]

It's getting close to a year since this issue was found. It definitely is a blocker for me. Any chance this can get fixed soon?

[kovetskiy]

@chnrxn yes, here is the fix but it was rejected: #1548

[jordansissel]

#1561 should fix this, but one report says it Broke things... can someone else help test it?

…

On Wed, Aug 28, 2019 at 1:55 AM Egor Kovetskiy ***@***.***> wrote: @chnrxn <https://github.com/chnrxn> yes, here is the fix but it was rejected: #1548 <#1548> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1543?email_source=notifications&email_token=AABAF2XLIWGDBCQFP33DJMDQGY4PJA5CNFSM4FQIME52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5KMOTI#issuecomment-525649741>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABAF2WPC3UHHT6GQOAKFQTQGY4PJANCNFSM4FQIME5Q> .

[jkugler]

Just FYI, I was able to use FPM by applying this patch to the gemspec:

--- fpm.gemspec.original	2019-11-07 18:32:32.051393000 -0800
+++ fpm.gemspec	2019-11-07 18:33:00.941454000 -0800
@@ -39,7 +39,7 @@

   # For command-line flag support
   # https://github.com/mdub/clamp/blob/master/README.markdown
-  spec.add_dependency("clamp", "~> 1.0.0") # license: MIT
+  spec.add_dependency("clamp", "~> 1.2.0") # license: MIT

It produced a valid package, and the package passed my tests. This of course restricted it to clamp < 1.3.

This is on FreeBSD 10 and 11 creating txz files.

[jcbollinger]

#1561 fixed the issue for me in FPM 1.11.0, with Clamp 1.3.1. I did not see any adverse effects (that I recognized) with a dir source and an rpm target.

[jordansissel]

#1561 was merged and this fix will be available in the next release of fpm.

[tylarb]

@jordansissel any ETA on a new release? it looks like the most recent one is over a year old now, and this bug still exists...