Locate SO_TARGET_DIR with gem rather than system#43
Locate SO_TARGET_DIR with gem rather than system#43andrewhamon wants to merge 1 commit intomasamitsu-murase:masterfrom
Conversation
6380fe6 to
af0e3bf
Compare
af0e3bf to
180f9bd
Compare
|
I've deployed an app with your branch's seven_zip_ruby twice in Heroku. The first time purging the bundler cache and the second one without purging and it works. To complete this PR it would be good to update the gem version and update the Release notes: https://github.com/masamitsu-murase/seven_zip_ruby#releases @andrewhamon |
|
I wouldn't want to presume that @masamitsu-murase wants to cut a new release with just this commit |
|
It would be great to have a patch version so that apps in Heroku can be easily fixed. As a temporal alternative merging this PR to master (I think it's stable), this will also ease the use of this gem. |
|
I am not sure if this issue is related but I can't require |
|
Hi, I thank you very for this gem and the fix, I am currently facing the same issue while installing a project using this gem. |
|
@masamitsu-murase We have been using this branch for a year without any issue. |
Previously,
SO_TARGET_DIRwas hardcoded to install the built 7z.so intoRbConfig::CONFIG["sitearchdir"], which is typically located wherever ruby is installed.This is seems like an unusual thing for a gem to do, and breaks if ruby is installed in a read only location. It also breaks caching assumptions for some PaaS rails hosts, like Heroku.
This PR tweaks
SO_TARGET_DIRso that 7z.so is instead installed in the gem directory with the rest of theseven_zib_ruby, i.e.$GEM_HOME/gems/seven_zip_ruby-1.3.0/libwhich I think falls back to~/.gem/ruby/2.7.0/gems/seven_zip_ruby-1.3.0/libThis change allows seven_zip_ruby to build on my system, and I can also
require "seven_zip_ruby"successfully. I also believe that this will not impact other users.Fixes #41 and fixes #42