Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #143 - Childprocess v1.0.0 failing to install. #144

Merged
merged 1 commit into from Feb 3, 2019

Conversation

farkasmate
Copy link
Contributor

No description provided.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 94.688% when pulling d84a702 on farkasmate:rake_runtime_dependency into f006e08 on enkessler:master.

@sds
Copy link
Collaborator

sds commented Jan 31, 2019

Thanks for the fix, @farkasmate. Given your comment in the issue this seems like the correct way forward.

One additional clarification (not specifically directed at you): any reason we need to limit rake to < 12?

@enkessler
Copy link
Owner

The limit is there so that we don't get bitten by a major version bump from rake and 11.x is what was released at the time that the limit was added. We can probably knock it up to < 13.0 and see if CI is still happy.

s.add_development_dependency 'coveralls', '< 1.0'

s.add_runtime_dependency 'rake', '< 12.0'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this eliminates the situation where installation is broken when rake is missing.

But it also propagates rake as a runtime dependency of any app that includes childprocess and returns any app that uses childprocess on any platform to a state where rake is always available at runtime. For users who are concerned about the surface area of their applications for security or performance reasons, this is less than desirable.

Since we have a known workaround (pin to 0.9.x), I advocate for taking the time to find a solution that doesn't add runtime dependencies that aren't actually necessary at runtime, or at least reduces the effect to platforms on which they are needed for the installation.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change came from a desire to not have ffi be a dependency. So...it's kind of a 'pick your poison' situation. Between the two, I'd guess that more places are fine having rake installed than ffi. If there is yet another solution that doesn't require either gem as a mandatory dependency, then that would be even better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@enkessler If a conditional dependency (ffi on Windows) is all you want, you can remove ext/mkrf_conf.rb and do a conditional instead in childprocess.gemspec:

-  s.extensions = 'ext/mkrf_conf.rb'
+  s.add_runtime_dependency 'ffi', '~> 1.0', '>= 1.0.11' if Gem.win_platform?

With this you don't need rake at runtime. As you pointed out, that generated Rakefile has no use at the moment.

What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@farkasmate conditionals in the gemspec don't quite work in this case, because they are evaluated at gem build, before the gem is uploaded to rubygems.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, OK.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've looked at alternative extensions we could implement, but the introduction of rake as a dependency is the only way to do this in a platform-agnostic way. Other extensions require the existence of make or other tools, which may not be installed on some systems.

For this reason, and given the fact that rake is usually (but not always) installed by default on Ruby systems, it seems reasonable to add a dependency on rake for sake of removing the ffi dependency for all non-Windows systems.

@sds sds changed the base branch from master to dev February 3, 2019 05:39
@sds sds merged commit 37e6c0a into enkessler:dev Feb 3, 2019
@sds
Copy link
Collaborator

sds commented Feb 3, 2019

Followed up with a PR to relax the rake constraint in #147.

@sds
Copy link
Collaborator

sds commented Sep 20, 2019

Following up here to say we've removed the magic ffi install logic in #160, allowing us to remove the runtime dependency on rake. This dependency removal will ship in ChildProcess 3.0.0.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Mar 24, 2020
Update ruby-childprocessto 3.0.0.


### Version 3.0.0 / 2019-09-20

* [#156](enkessler/childprocess#156 unused `rubyforge_project` from gemspec
* [#160](enkessler/childprocess#160): Remove extension to conditionally install `ffi` gem on Windows platforms
* [#160](enkessler/childprocess#160): Remove runtime dependency on `rake` gem

### Version 2.0.0 / 2019-07-11

* [#148](enkessler/childprocess#148): Drop support for Ruby 2.0, 2.1, and 2.2
* [#149](enkessler/childprocess#149): Fix Unix fork reopen to be compatible with Ruby 2.6
* [#152](enkessler/childprocess#152): Fix hangs and permission errors introduced in Ruby 2.6 for leader processes of process groups

### Version 1.0.1 / 2019-02-03

* [#143](enkessler/childprocess#144): Fix installs by adding `rake` gem as runtime dependency
* [#147](enkessler/childprocess#147): Relax `rake` gem constraint from `< 12` to `< 13`

### Version 1.0.0 / 2019-01-28

* [#134](enkessler/childprocess#134): Add support for non-ASCII characters on Windows
* [#132](enkessler/childprocess#132): Install `ffi` gem requirement on Windows only
* [#128](enkessler/childprocess#128): Convert environment variable values to strings when `posix_spawn` enabled
* [#141](enkessler/childprocess#141): Support JRuby on Java >= 9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants