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

Dropping bin/* files for development in the gem? #673

Closed
junaruga opened this issue Apr 28, 2021 · 3 comments · Fixed by #675
Closed

Dropping bin/* files for development in the gem? #673

junaruga opened this issue Apr 28, 2021 · 3 comments · Fixed by #675

Comments

@junaruga
Copy link
Member

junaruga commented Apr 28, 2021

It's similar with ruby/power_assert#35 and ruby/rake#385 .

I find there are some files such as run_in_md.rb, test_runner.rb, console and setup included under the bin/ directory in the rbs gem file. And these files might be only used for the development. Is that right? What do you think about not including the files for development in the rbs gem file?

$ gem fetch rbs
Fetching rbs-1.2.0.gem
Downloaded rbs-1.2.0

$ gem unpack rbs-1.2.0.gem

$ ls rbs-1.2.0/bin/
annotate-with-rdoc*  query-rdoc*  run_in_md.rb  sort*   test_runner.rb*
console*             rbs-prof*    setup*        steep*

Seeing the current rbs.gemspec excluding specific files by Array#reject, perhaps a way to include only necessary files might be a way not to include the bin/* files.
ex. https://github.com/puma/puma/blob/e870ab69f03e44a80c60df8b3ac1b42b1374f907/puma.gemspec#L16-L17

I found this issue when running a lint program for Ruby's RPM package in the Fedora project. I think the messages E: non-executable-script themselves are not related to this rbs project. It might be an issue related to Ruby RPM or ruby/ruby.

rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/annotate-with-rdoc 644 /usr/bin/env ruby
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/console 644 /usr/bin/env ruby
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/query-rdoc 644 /usr/bin/env ruby
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/rbs-prof 644 /usr/bin/env ruby
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/setup 644 /usr/bin/env bash
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/sort 644 /usr/bin/env ruby
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/steep 644 /bin/sh
rubygem-rbs.noarch: E: non-executable-script /usr/share/gems/gems/rbs-1.0.0/bin/test_runner.rb 644 /usr/bin/env ruby

Thanks!

@pocke
Copy link
Member

pocke commented May 3, 2021

Thank you for reporting the issue!

And these files might be only used for the development. Is that right?

It's true. These scripts are necessary only for developing RBS.
So I think removing them from the released package is a good idea.

But I'm not sure the lint is appropriate. The files under bin/ are not marked as "executables".

spec.executables = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }

The files are unnecessary for end-users, but they don't affect to the end-users. So I think the lint rule is a bit misleading.

By the way, perhaps bundle gem's boilerplate should remove bin/ directory from released files by default.

@junaruga
Copy link
Member Author

junaruga commented May 3, 2021

Thank you for considering this!

But I'm not sure the lint is appropriate. The files under bin/ are not marked as "executables".

The lint program was checking the rbs installed as a bundled gem by Ruby's make install not the rbs installed by gem install. We found the Ruby's make install overrides the bundled gem's file permissions with 644 removing executable bits. Here is the ticket I opened: https://bugs.ruby-lang.org/issues/17840 .

@soutaro
Copy link
Member

soutaro commented May 4, 2021

@junaruga Thanks! Yes, we don't want to include the bin/ files in the package. 💦

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants