-
-
Notifications
You must be signed in to change notification settings - Fork 271
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
Remove non-essential files from the distribution #562
Conversation
I'm okay with removing |
@gettalong are you saying you don't want to remove the
|
The difference in the gem size is 51KB, 135.680 bytes with |
@gettalong How are you finding those numbers? In terms of the gem package container, I'm seeing:
Then unpacked, I am seeing something a little different than what I'd posted before:
|
Okay, I had some additional changes. By removing the paths mentioned by me earlier I get 138.752 bytes with the Unpacked it will be more but if you care about the space for your specific use case I would recommend installing everything and then running a command like |
That does work well. But what I'm attempting now is something more like a public service. I'm going to try on an argument here and see if I can convince you about the test folder. One thing I've noticed recently is how large docker images for Ruby apps can be. And I think it reflects poorly on Ruby when folks are setting up a few dozen microservices and the Ruby images are all 20x the size of the Golang services. It is simple enough to remove the files we don't need when building images, but I think this should be the default scenario rather than an opt-in scenario. I've come to understand the gem as something we build from the original source code repository, but not necessarily the same as the source code repository. It seems analogous to the difference between installing prepackaged binaries and installing from source. Plus, it is simple enough to grab the full source code corresponding to the gem version you currently have. If that's what is needed, bundler can do it from git, or we could write a script to grab the corresponding archive from: https://github.com/gettalong/kramdown/releases without relying on git or bundler. If you're still not convinced, that's ok. I can update the PR as you've already requested. Let me know what you think. One other option that I've considered is to package two different gems, one with all the original source files and one without. So there could be a kramdown and kramdown-full or something like that. |
Thanks for taking your time to write down your thoughts! For me, Rubygems is a distribution mechanism for kramdown, another one would be the repo contents from a certain git tag. In all cases, the tests should be distributed with the source because than you can verify that the library works on your machine as expected. If you want to create a docker image and want to make it minimal, you will have to do manual steps anyway. For example, if you would use Debian as base, you would need to delete the It boils down to the priorities one has, in your case, total size of dependencies. To achieve that goal you have to delete everything which is considered unnecessary for your goal, e.g. you would also delete My conclusio is: Since you have to do manual steps anyway, an additional |
Since you mentioned Debian, let me see if it would change your mind if you consider an image that's an order of magnitude smaller. Here are two Dockerfile that both are descended from ruby:2.6-alpine After building them:
Aside from deleting the bundle cache, there are no manual steps needed for me other than to trim the gem itself. Still, I can see where you're coming from and you may simply have a different idea than I do of how you want to use rubygems.org. For now, I'm going to assume that's the case and update this PR. |
06c6a08
to
b75c96f
Compare
@stevecrozz Your commit b75c96f is confusing now. |
b75c96f
to
651db44
Compare
Thanks @ashmaroli. That was a mistake of course. I've pushed a new commit with the correct change. This one removes only parts requested by @gettalong from the gem rather than from the whole git repo. |
Thanks! I have merged your commit. |
Just as I've done with nokogiri recently (sparklemotion/nokogiri#1719), I'd like to trim the size of this package (the one published to rubygems) so that installations are faster and the gem takes up less space on disk. So what I've attempted to do here is include only the files that are essential to kramdown's functionality, plus the software license which seems like it should be included in all distributions.