On Thu, Nov 13, 2008 at 2:52 PM, Phil Hagelberg <[EMAIL PROTECTED]> wrote: > "Luis Lavena" <[EMAIL PROTECTED]> writes: > >> There is already a big nightmare (not to say gem hell) related to >> preview/rc gems laying in github or rubyforge that complicate the >> environment of many users (I get several reports about that). As >> example I can mention rspec gem depending on a patched version of rcov >> that only exist in github and has no binaries for it. > > Right now a lot of people keep prerelease gems on github only. This is > because there's no good way to handle them in Rubyforge. Currently if > someone installs a stable release of a gem (on github, or any source > that's been added) and then issues a "gem update" after a prerelease has > been pushed out, they will pull it in even if they want to stick with > the stable release. This problem will be alleviated if rubygems has a > way of distinguishing between stable releases and prereleases. >
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. >> I believe pushing RC or preview versions to rubyforge will make "gem >> update" for several users a nightmare. > > This is exactly what I'm working on right now. It's not like we're just > tossing prerelease gems into a big pile and calling it done; we're > taking special care to make sure that they only get pulled in when > they're explicitly requested. > Hmn, I haven't looked in the commits and the added new test to find a serious reference of pre-release, only the handling of letter for versioning (which doesn't mean prerelease or release at all). I can decide version my gem "1.2.abc" and and doesn't make it pre-release, just a silly versioning schema. >> Previously, no RC or preview gem was published to rubyforge. > > That's not true; see Ryan's earlier post. Previously there's been no > sane way to handle prereleases, so everyone does it differently. Merb > has one way, Rails has another, other people make up their own. I've run > the idea by Rick Olson of Rails core, and he is in favour of > it. Everyone I mentioned it to at RubyConf was eager to see it > implemented. Sorry my english, I wanted to say "publishing of preview/rc gems to rubyforge was not encouraged". >> Previews and RC where available through private gem servers to avoid >> this situation letting the developers control how and when these gems >> will hit the mirrors and made into the public. > > But this also means that nobody can offer prerelease gems unless they're > willing to run their own gem servers (or willing to seriously confound > the users of their gems.) If Rubyforge can offer this service, it will > level the playing field for smaller projects. > >> I don't see big OS distros like Ubuntu or even debian opening the room >> for RC and preview packages to their official distribution >> repositories. > > Oh, don't they? (http://p.hagelb.org/prerelease.png) > > Even if that weren't the case, there are a lot of things apt-get doesn't > do that we do, like allowing multiple versions of a gem to be installed > at the same time. If we were to blindly follow their lead, we would lose > a lot of really useful functionality. Gems have a *much* more rapid pace > of change than debs do; it's only natural that the infrastructure should > reflect this. > Is not the same case, is not enabled by default, which contrary to rubygems that depends on gems.rubyforge.org (and is the default one) I agree that gems evolve in a faster way than deb packages, and because of that, gem update can become more problematic. >> Anyway, just my PoV, this will also render useless patterns like "~>" >> and even worse dumb developers that do not check or maintain their >> dependency list properly. > > Actually, the whole point of this is to *fix* the usage of ~> for > prereleases. Right now if you want to depend on version 0.9 of Merb, you > will pull in their 1.0 RC, because its version is 0.9.99 or some such. A > lot of projects use this versioning scheme, and it renders > major-version-only matching useless. I concede you a point on that, been bitten by ~> as gem developer but also as user of these gems too. > If you read carefully over the proposed solution and can come up with a > real flaw in it, then *please* bring it up. If you've found some edge > case that I haven't thought of, I'm all ears. But vague fears and doubts > really do very little to help the situation. > I accept that the proposal is great (btw, a reference blog port will be great), and I thank the work done by you and contributions by Josh and Alex, but don't ignore the fact that developers will not use it properly and will not keep using >= to indicate a gem dependency. My comments came from the experience not only as gem developer but dealing with reports of people that installed gems, done gem updates with rubyforge as unique source and also those that added github too as "best practice" indicated in several forums. I often prefer expose my doubts about something that rant later about something that could have been done properly. If you scan the mailing list can find references to these things, as example the release of rubygems 0.9.5. > That said, I'm willing to defer to Eric's judgment if he can find merit > in any of the objections that have been raised. > > -Phil -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
