Litany Against Fear: litany against fear ¤ by nick quaranto ¤ On Gem Forking
Jeremy McAnally
· 2 months ago
You're right it's false that gemcutter can't support forking of gems. I'll be sure to claim qrush-gemcutter or something on Gemcutter. :P Being able to claim things like that is problematic for what you describe simply because you never verify that a claimed fork is from the original user, and until people settle into gemcutter and wean themselves off of Github's gem stuff, it's going to be annoying to manage that if you encourage people to do it (i.e., just move their named forks over to gemcutter).
As it is, the service isn't that old and we're already hitting a lot of name collisions that aren't forks. I've seen like 2-3 tweets just from people I know who are finding people who have claimed their gem names for different gems. I know it's just growing/change pains, but still, it's an annoyance. :)
Github gave us a good stop gap while you guys figured out what you want to do. You chose subdomains, something I don't care for just because it's annoying to have to add sources (unless there's something super smart and clever I'm missing?), but I really do think it'll work pretty well since it will make it simple to do forking.
I don't mean to make a mountain out of a mole hill, but to be honest, we often use more forks than we do non-forks in our projects. A lot of the libs we use have quirks or bugs we hit, so either we hit them and fix them or someone else has found them and fixed them. Ideally these improvements and feature additions would make it upstream (and let's be honest here, Github makes it stupid simple to pull things in), but that's not the case usually. We used a fork of Curb for a long time because it fixed bugs and had multipart support before the main gem did. I think the Github rage comes from people like us who either (a) have a lot of users using their Github gems or (b) now have to figure out how to maintain the forks we are using, keep them updated, etc. The annoyance is small, but it is irritating nonetheless. :)
Anyhow, that's my ramble on forking. I'm hacking on something to offer Github gems-like gem forking. I don't think Gemcutter needs to try to replicate that behavior but it is useful (at least for me). It will require something kind of specific, but I like the direction you guys are going as a general gem host.
You guys need to keep focusing on being a super sexy Rubyforge gem replacement. :)
And keep it up! The service itself is looking great for a new de facto gem source. I think the API is awesome, the gem is awesome, and hosting it in the cloud is really cool. Looking forward to seeing where it goes. :) Don't let the whining of myself and others let you think we aren't excited about it.
qrush
· 2 months ago
Thanks for the kind words! :)
As for subdomains, I think actually adding a subdomain gem source to your gem sources list should happen rarely. It should only happen if it's your own or your company's (why I like the private gem subdomain idea) You've got to trust those gems, especially since it'll be a totally blank index and it's meant to be a little playground/sandbox for that user/group.
Jamie Macey
· 2 months ago
Jeremy,
Would it be convenient enough if you were to set up your own subdomain, check out the forked gem from github or wherever, and then just build the gem and push it into your subdomain? That saves you from adding tons of subdomains to your gem env, and also is a bit of a prod to keep you on the ball about what code you're putting into your apps.
bryanl
· 2 months ago
I think what it comes down to is people don't like change. Keep up the good work Nick.
zimpenfish
· 2 months ago
People don't like enforced change without warning onto a new scheme that makes their lives a little more difficult whilst being told they were doing things the wrong way before and this is The Right Way Even Though It Chafes.
Mat Brown
· 2 months ago
I really like this idea - echoing Jeremy, the biggest need we have for gem forking is getting changes/enhancements/bugfixes in sooner than the maintainer of the canonical gem is able. With that in mind, it makes a lot of sense that we'd add *our* subdomain repo as a source; then all we're getting are our downstream gem forks, and the canonical versions - exactly what we need, and I think a nicer solution than dealing with the namespace soup of github gems.
Jeremy
· 2 months ago
I thought that github's method made it so easy - the gems were automatically built when you pushed up, and all the gems were prefixed by username. I'll miss that greatly. It wasn't even all about forking the gems, github made it easier to manage.
zimpenfish
· 2 months ago
I use github because it's zero friction. Adding gemcutter into the mix increases that friction to the point where using github and getting gems out of the end is a positive chore.
#1 how do I get my gh-pages onto there as the documentation? #2 I couldn't care less about gem forking, github building the gems for me is zero-friction. #3 Until gemcutter breaks/goes under/pulls a similar dick move
I've nothing against gemcutter -- indeed I'd never even heard of them until this github row (which isn't a great sign) and the domain is only registered for one year. Confidence is not inspired...
banister
· 2 months ago
`rake gem && gem push mygem.gem` may not be 'zero' friction but it can't be more than about 2% friction
;)
zimpenfish
· 2 months ago
> rake gem rake aborted! No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb) /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2377:in `raw_load_rakefile' (See full trace by running task with --trace)
Now I have to make a Rakefile as well. And add the gem (plus any other autogenerated files) to the 'git ignore'. And remember to run all that every time I want a new gem.
It's not a huge amount of friction, no, but it's enough to make things enough of a chore that the fun starts to leak out.
David Dollar
· 2 months ago
Yes, it's going to be a little more work in order for you to build gems now and get them out. The problem is that pushing that work over to Github means their servers are responsible for executing arbitrary Ruby code that you push to them in order to build your gems. While I agree with you that it sucks that they didn't give notice that the feature would be going away before it stopped working, there are alternatives that you can use.
If you don't want a Rakefile, you can simply "gem build my.gemspec" on the gemspec that you were pushing up to Github. This will give you your finished .gem that you can then push to Rubyforge or Gemcutter. If you have the "gemcutter" gem installed, pushing to Gemcutter is a simple "gem push my.gem" on the gem you just built.
If you are interested in a rake-based approach to managing your gemspec (which I find to personally eliminate much of the tedium from packaging gems) you can check out Jeweler. Dropping it into your application is as simple as pasting a few lines into your Rakefile from the README found at http://github.com/technicalpickles/jeweler
Thanks for taking the time to release your code as gems to help enrich the community, and I sincerely hope that you continue to do so. If you have any questions/comments/concerns getting up and running with a new workflow, feel free to get in touch with me at ddollar@gmail.com or hop onto #gemcutter on Freenode.
All Comments
As it is, the service isn't that old and we're already hitting a lot of name collisions that aren't forks. I've seen like 2-3 tweets just from people I know who are finding people who have claimed their gem names for different gems. I know it's just growing/change pains, but still, it's an annoyance. :)
Github gave us a good stop gap while you guys figured out what you want to do. You chose subdomains, something I don't care for just because it's annoying to have to add sources (unless there's something super smart and clever I'm missing?), but I really do think it'll work pretty well since it will make it simple to do forking.
I don't mean to make a mountain out of a mole hill, but to be honest, we often use more forks than we do non-forks in our projects. A lot of the libs we use have quirks or bugs we hit, so either we hit them and fix them or someone else has found them and fixed them. Ideally these improvements and feature additions would make it upstream (and let's be honest here, Github makes it stupid simple to pull things in), but that's not the case usually. We used a fork of Curb for a long time because it fixed bugs and had multipart support before the main gem did. I think the Github rage comes from people like us who either (a) have a lot of users using their Github gems or (b) now have to figure out how to maintain the forks we are using, keep them updated, etc. The annoyance is small, but it is irritating nonetheless. :)
Anyhow, that's my ramble on forking. I'm hacking on something to offer Github gems-like gem forking. I don't think Gemcutter needs to try to replicate that behavior but it is useful (at least for me). It will require something kind of specific, but I like the direction you guys are going as a general gem host.
You guys need to keep focusing on being a super sexy Rubyforge gem replacement. :)
And keep it up! The service itself is looking great for a new de facto gem source. I think the API is awesome, the gem is awesome, and hosting it in the cloud is really cool. Looking forward to seeing where it goes. :) Don't let the whining of myself and others let you think we aren't excited about it.
As for subdomains, I think actually adding a subdomain gem source to your gem sources list should happen rarely. It should only happen if it's your own or your company's (why I like the private gem subdomain idea) You've got to trust those gems, especially since it'll be a totally blank index and it's meant to be a little playground/sandbox for that user/group.
Would it be convenient enough if you were to set up your own subdomain, check out the forked gem from github or wherever, and then just build the gem and push it into your subdomain? That saves you from adding tons of subdomains to your gem env, and also is a bit of a prod to keep you on the ball about what code you're putting into your apps.
#1 how do I get my gh-pages onto there as the documentation?
#2 I couldn't care less about gem forking, github building the gems for me is zero-friction.
#3 Until gemcutter breaks/goes under/pulls a similar dick move
I've nothing against gemcutter -- indeed I'd never even heard of them until this github row (which isn't a great sign) and the domain is only registered for one year. Confidence is not inspired...
;)
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
/usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2377:in `raw_load_rakefile'
(See full trace by running task with --trace)
Now I have to make a Rakefile as well. And add the gem (plus any other autogenerated files) to the 'git ignore'. And remember to run all that every time I want a new gem.
It's not a huge amount of friction, no, but it's enough to make things enough of a chore that the fun starts to leak out.
If you don't want a Rakefile, you can simply "gem build my.gemspec" on the gemspec that you were pushing up to Github. This will give you your finished .gem that you can then push to Rubyforge or Gemcutter. If you have the "gemcutter" gem installed, pushing to Gemcutter is a simple "gem push my.gem" on the gem you just built.
If you are interested in a rake-based approach to managing your gemspec (which I find to personally eliminate much of the tedium from packaging gems) you can check out Jeweler. Dropping it into your application is as simple as pasting a few lines into your Rakefile from the README found at http://github.com/technicalpickles/jeweler
Thanks for taking the time to release your code as gems to help enrich the community, and I sincerely hope that you continue to do so. If you have any questions/comments/concerns getting up and running with a new workflow, feel free to get in touch with me at ddollar@gmail.com or hop onto #gemcutter on Freenode.