mark/shard

A lightweight snippet sharing & loading system, built on top of Gists.

shard's Issues

missing gemspec from the repo

missing the gemspec for the project

missing octokit dependency

Missing octokit dependency in gemspec.

Blocked by #1

○ shard list jhsu
/Users/josephhsu/.rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- octokit (LoadError)
    from /Users/josephhsu/.rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/josephhsu/.gem/ruby/2.0.0/gems/shard-0.1.0/lib/shard/lister.rb:1:in `<top (required)>'
    from /Users/josephhsu/.rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/josephhsu/.rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/josephhsu/.gem/ruby/2.0.0/gems/shard-0.1.0/lib/shard.rb:10:in `<top (required)>'
    from /Users/josephhsu/.rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/josephhsu/.rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
    from /Users/josephhsu/.gem/ruby/2.0.0/gems/shard-0.1.0/bin/shard:6:in `<top (required)>'
    from /Users/josephhsu/.gem/ruby/2.0.0/bin/shard:23:in `load'
    from /Users/josephhsu/.gem/ruby/2.0.0/bin/shard:23:in `<main>'

[Discussion] bundler-shard

Wanted to lead with giving you major props for shard. It perfectly fills a void in the GitHub ecosystem!

It also would be a major component for filling a void I've felt in the gem ecosystem: patch management.

Semantic Versioning, Gems, and Bundler enable Rubyists to construct 3rd-party dependency stacks beyond the wildest dreams of other languages. However, even with the best practices in place, stacks can grow sufficiently complicated that patching is necessary. Ruby makes this trivial, so in a way everything balances out. But at the end of the day a lot of developers end up maintaining the same patches individually, since there's no tool for managing their development, distribution, or deprecation.

A great example would be my patch for ActiveRecord and Kaminari, which I need for Rails 4 with RailsAdmin. Kaminari doesn't work with ActiveRecord in certain contexts, which is fine and inevitable. There's an open issue for it, the resolution of which is tied to an open issue in ActiveRecord. I had to build this monkey patch out of the discussion threads on both issues, which is also reasonable.

The problem is that now I have to check in and remember to monitor this patch, potentially for forever. The reason why my patch is so extensively documented, and located in my source code under config/initializers/DANGER_ZONE/ is to encourage me to regularly check in on the issues (rails/rails#10658 and amatsuda/kaminari#421) in progress and search for resolution, alternatives, or even discovery of major problems that these patches have been discovered to introduce. And I can only hope every other person who's had to apply them as well makes the same attempts at vigilance.

I'd like to consolidate this burden of patch maintenance through an extension to Bundler, adding a shard method to their DSL, that allows you to pull in and apply patches in much the same way the gem method works. This would allow the community to collaborate on the daunting but necessary task of patch management instead of going code cowboy on it the way we have now.

Originally I had a patch DSL method in mind that would hook into Gists, but the complexities of this problem paired with the lack of a good formalized mechanism for pulling code down from Gists similar to gem kept me from wanting to address it.

With shard, though, I'm feeling bolder. I think tackling this challenge is more in reach and I was hoping to gauge your interest and get your input on such an undertaking, as well as start a discussion anywhere in public that might help bend the minds of the Ruby community to implement such a tool.