Home → Problems →

Hosting Fork of PDF::Toolkit

Admin Functions

• Remove

alharaka

03 Nov, 2010 08:26 AM

So, I am a very amateur Rubyist, if you can even call me that. I want to fork PDF::Toolkit as I mentioned on StackOverflow so I can do some things I need where the current implementation is inflexible. I just watched the tutorial on this site about creating new gems. So, my main question is:

Do I host a "personal" fork here? I do not have the programming skills or experience to take on maintaining this package. I just want to host a modified version for and others at work; nothing too fancy. The SO post mentions what I will do to start off with, but I have found other issues. So, is it ok to post a fork like alharaka-pdf-toolkit or username-orignalprojectprefork? I do not see many of those searching here.

If the answer is yes, what is the recommended process. I am going from what I have seen in the video:

1) Fork from old RubyForge git repo
2) Host my own fork on GitHub
3) Use GitHub repo properly configured to host gem here on RubyGems

I am getting the basic process? I am sorry, but I am a real newb. Also, the problem is that things have changed a lot and the community moved along with it, but I cannot find any definitive mention of how a newbie should host his on gem if a) not on GitHub or b) not an officialish gem (meaning my own original project). Thanks for the help.

1. Support Staff 2 Posted by Nick Quaranto on 04 Nov, 2010 05:11 PM

   

   Hi there,

   You could certainly host the gem here if you need to, however, you may not need to push out a new gem.

   If you're using Bundler, it supports bundling a gem from a git repo:

   http://gembundler.com/git.html

   I would probably reserve pushing out a gem fork if you really really need to. One of the Gemcutter contributors David Dollar puts it very eloquently:

   I think the general idea is that gem forks should be a huge special case. I’m somewhat of the mind personally that making gem forks too ‘easy’ causes a great deal of unnecessary fragmentation in the community. It seems reasonable to me, that if your project is going to depend on a gem fork, that the dependency resolution not be automatic, and your installation instructions can tell the user how to get the forked dependency. If a fork is going to be long-term, or a true alternative, it should probably be reregistered under a new name as a different project.

   I think the more elegant solution until you plan to maintain it for now is to just keep it on GitHub, if you absolutely need to push the gem.

   Admin Functions

   • Remove

2. 3 Posted by alharaka on 04 Nov, 2010 06:37 PM

   

   Nick, thanks so much for your reply. GemBundler seems super, super cool. I was envisioning moving over a lot of my support tasks with RoRPortable and use the underlying Ruby interpreter to get things done quickly on computers I support and also work on Ruby/RoR when I feel like it without worrying about moving to different environments. I am not sure if I can GemBundler to work with it (since RoRP needs a good deal of work, but I am treating all of it as a learning experience). Nonetheless, I think you did a great job answering my question: this closes the gap in my understanding how to work with gems in the context of personal forks and the new GitHub way. As someone who has relied on CPAN and various Linux distros, I totally sympathize with the need to enforce strong organization of package namespaces and avoid the confusion over which package is the "real" or "stable" one.

   You can mark this case closed.

   Admin Functions

   • Split
   • Remove

3. Support Staff 4 Posted by Nick Quaranto on 05 Nov, 2010 01:16 AM

   

   Bundler can go off any gem source...just run a gem server from the USB stick and point it at that port on localhost. :) The folks in #bundler on FreeNode can probably help you out more.

   Admin Functions

   • Remove

4. Nick Quaranto closed this discussion on 05 Nov, 2010 01:16 AM.

Comments are currently closed for this discussion. You can start a new one.