Issue #478 invalid

gem server?

McClain Looney
created an issue

pleeeeese? i know you're pythonistas, but c'mon. do eggs and gems and do it better.

Comments (6)

  1. McClain Looney reporter

    that article makes very valid points, all of them true.

    the obvious answer is to do it better than github. create a gemserver a-la github, but then integrate a release process to rubyforge. rubyforge releases are quite trivial to make via the rubyforge gem and library "rubyforge release project packagename" is pretty much all there is to it.

    github has snatched up a huge part of the ruby dev world simply b/c of their simple gemserver hacks, and being pretty.

    the reason nobody uses rubyforge anymore is that it's ugly, and user-hostile. that's unlikely to change, so let's just build a pretty interface to it.

  2. James Crasta

    McClain Looney

    The problem I see is that building a gem is a non-trivial task. You have to actually run "gem build" on the source and have compatible (and up to date) versions of gem with the gemspec to build the proper archive. a gem is a tar archive containing a gzipped tar archive and a gzipped metadata file; but making that metadata file requires parsing the gemspec. I don't even want to think about the fact that the gemspec is a ruby file, and thus could cause arbitrary code to run, and this is certainly a security risk.

    Building the Ruby Gem "server" requires building a bunch of gems, putting them in a directory, and then generating listings (using "gem generate_index") on those files.

    Meanwhile in the python world, easy_install and pip don't require an egg to install. They can simply be pointed at tip.tar.gz from a mercurial repository. pip/easy_install then extract the tarball and run setup.py within, on the local system.

    So comparatively, building a gem index requires significantly more CPU time to continuously clone the repos, parse the gemspecs, rebuild the gem index, as well as the storage space of keeping the gems, not to mention the security risk implied building gems. Meanwhile hosting an easy_install package is done via simply making a tarball of a repo revision (something mercurial does natively,) and linking to it from PyPI. On bitbucket's part, it doesn't need to execute any python code from the repo. I'm not saying it's a bad idea and it'd be certainly cool if bitbucket did implement a gem server, but it's a significant investment to do so.

    (btw, I'm not a bitbucket developer, so I have no official say on this, these are just my thoughts)

  3. Log in to comment