Drop git ls-files in gemspec

[utkarsh2102]

Hi @mvz,

Thanks for working on this! ❤️
However, while maintaining this in Debian, we found that this library relies on git to list the files which could be done via pure Ruby alternative -- which is what this PR does.

As an addition, this PR makes sure that this gem only ships the required files to the end-users and not other things which are not needed by them! 🚀

Also, added rubocop-packaging as a development_dependency which will ensure the best practices.
Here's what it shows us:

➜  gir_ffi git:(master) rubocop --only Packaging

Inspecting 302 files
......C..............................................................................................
.....................................................................................................
.....................................................................................................

Offenses:

gir_ffi.gemspec:29:34: C: Packaging/GemspecGit: Avoid using git to produce lists of files. Downstreams
often need to build your package in an environment that does not have git (on purpose). Use some pure
Ruby alternative, like Dir or Dir.glob.
                "COPYING.LIB"] & `git ls-files -z`.split("\0")
                                 ^^^^^^^^^^^^^^^^^

302 files inspected, 1 offense detected

And this PR fixes the same, which helps us in shipping this in Debian! 🎉
Hope this would make sense and you'll be open to this change 💯

Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>

[mvz]

Hi @utkarsh2102, I agree that using git inside the gemspec is not very nice. However, one purpose of this is making sure no unwanted files (e.g., vim swap files) are shipped in the gem. Any thoughts on how alternative ways to handle this?

[mvz]

I'm now looking at using hoe to provide some manifest tools.

[utkarsh2102]

There, the CI goes green again! 🌮
Good to go now, I think! :D

[mvz]

Thanks, @utkarsh2102!

[utkarsh2102]

Thanks Matijs, you're the best! 🔥❤️
Also, I've been meaning to do this for the Cucumber project, too. Would you be willing to accept it as well!? 😄

[mvz]

I would support such a change for cucumber as well, but I'm not the only one to decide on it and the cucumber project has a rather complex repo set-up. Maybe opening an issue first to discuss this would be good.

[utkarsh2102]

That makes sense, thank you!
I shall do that today \o/