On Thu, Nov 13, 2008 at 12:07 PM, Luis Lavena <[EMAIL PROTECTED]> wrote:
> The problem I faced with github gems is that people started to rely on > that, and other gem developers started to push projects to rubyforge > with dependencies on gems that only exist on github. > > Some users didn't add github source and faced mysterious errors while > installing or doing gem update. > Seems like there are two separate problems here. First is the fact that rubyforge.org is still the only default repo in rubygems, but people are pushing gems there that have dependencies on other repos (github). They do this unknowingly, because they have github set up as a source in their ~/.gemrc, and it works for them. This is already solveable with the --source parameter (even though it is clunky and could be improved) The second problem is the basic problem of verson management for prerelease versions, and allowing people to not get prereleases when they don't want them. This second problem is also already solvable with the current rubygems approach, if people (1) properly use pessimistic version constraints, and (2) use versions properly (a prerelease version should have a significant version bump so people can avoid pulling it with a pessimistic constraint), and (3) use a controlled dependency management approach in their apps (standard rubygems gem method with explicit version, rails config.gems, geminstaller, etc). Now, I'm not saying these are optimal solutions, because they depend on gem authors and users to know what they are doing, which isn't always likely or sustainable. However, any alternative we come up with should make the problem SIMPLER for the majority of people and not break other stuff majorly/unexpectedly, or else we might be better off sticking with the status quo. -- Chad
_______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
