Wow, so, this thread is getting silly. It's just going to take some time for patches to get approved unless they're clearly ready. Anyway, there's some more feedback to come on comments here.
Tying to snip where possible. On Dec 11, 2010, at 1:07 PM, Trans wrote: > On Dec 10, 1:55 am, Eric Hodel <drbr...@segment7.net> wrote: >> To begin with I would like to point out that you have deleted several of >> your comments forcing me to respond from memory and leaving their contents >> at the risk of "he-said, she-said". > > I did. I actually attempted to delete the all the commits altogether, > but it turns out that is not possible. It gets to a point were I would > rather delete them and forget the whole affair. You know there's fights that just aren't worth having, but that doesn't mean you should destroy work. > That request came only after I may a snarky remark about no one > commenting on the patch. From my perspective it appeared that when I > did something acceptable, it was being ignored. If it's not been merged in just a week or so, that's not ignored. A lot of the team are busy. > When I did something that wasn't it was an opportunity to "attack" (of course > that > perception almost entirely has to do with Ryan). Something which pertains to one person seems to be off topic for the issues you raised here and on ruby-talk. >>> https://github.com/rubygems/rubygems/pull/12 > Of course there is always maintenance, but in the scheme of things, > this one is pretty small. What was it about 20-30 lines of code? Wrong. Sorry, but when it comes to specs, it's not the code, but the /format/ that requires maintenance. Once there's live dependencies or gems out there in particular formats, we have to support them forever. That really means forever. We still have to deal with old formats from way back when and it's in the way of other "innovation" already. Very careful design choices are the only way we can avoid this. It is this understanding that separates those who are judging your code from your "it's just 20-30 lines" line of thought. >> I asked if there were any non-ruby tools that used a YAML gemspec. If such >> a tool existed it might be a reason to consider this feature. >> >> You did not name any non-ruby tools that used a YAML gemspec, but you came >> up with some hypothetical ruby tools that could use this feature. You >> claimed that this feature was important because either RubyGems consumed too >> many resources or that it would not be available. > > You are asking for something that can't exist b/c there is no such > thing as a plain YAML gemspec. I was trying to create such a thing so > such tools could exist. > > I gave you three use cases, two where it could be helpful if loading > Rubygems were unnecessary (a web search app gathering info about > projects and a web-app to edit the YAML gemspec), and a case where it > can't be loaded (Setup.rb is an alternative installer, it does not > make any sense for it to load rubygems, but it could utilize a pure > YAML gemspec). rubygems master loads tons of less code. In fact, loading yaml is probably about the same speed once we disable the plugin lookup. Of course, what you're saying is that rubygems is too slow for this usage, but I don't see what webservice you're likely to write without rubygems. We can all imagine cases where people will do lots of different things. Coming up with cases that are provably useful is different. The issue here is that no one involved can see how your suggestion is provably useful. Furthermore, you could, in such a hypothetical service, just remove or implement the type hint in whatever bald yak environment you need to save a few hundred kb. Seems I'm having trouble with my tone too, I just can't see any sense in this. If you can't make it make sense then it's argument for the sake of argument. >> In brief, I responded that if it's a ruby tool it can use RubyGems and that >> RubyGems resource burden is not too large. As of Ruby 1.9 RubyGems is >> always available. (Adding a feature to RubyGems specifically for Ruby 1.8 >> requires an overwhelming need.) I believe this is where I closed the ticket >> as you could not come up with a satisfactory reason for including plain-YAML >> gemspecs. > > The thing is that you dismissed those use cases so quickly and so > summarily, that it seemed to me that you weren't really giving it that > much thought. I also made it very clear that good bit of the > motivation for this patch came from the fact that the Bundler folks > have been pushing people to move to hand-edited gemspecs. I was > actually surprised to learn that I was mistaken in thinking that was > also the stance of the Rubygems team. This has nothing to do with YAML or the use cases you described. If you feel your use cases are dismissed, explain them clearly, explain how it's new and relevant and useful, otherwise it's just a "what-if" and I can "what-if" like you have no idea. >> You persisted, however and I continued to respond. > >> You argued that it could be made "safer" and I referenced the past history >> of junk data in gemspecs and Jeremy Hindegardener's talk at RubyConf 2010 as >> a demonstration that it probably can't be made safer. > > Actually, I argued that it wasn't any less safe then it was already. I > only made a passing parenthetical comment that if type safety is a > concern that improvement could be made --but that applied to the > current design in general, not this particular feature. Actually, the real issue is that we cannot override parameters during a YAML load as that's down to the YAML library. This would mean adding stages to recomposition in order to remain backward compatible in future versions. In a ruby environment we already have a hook to take control of those things. Type safety is probably the wrong term. See the marshal load overrides for more information. >> You said it would be "more convenient" and I responded that I could not find >> a gem that used YAML in its .gemspec file in a few minutes of searching. I >> pointed out that the community has decided that the de-facto format for >> gemspec files is Ruby. >> >> I thought you would take my lack of discovery of YAML .gemspec files as an >> opportunity to show me a single project that used YAML in its gemspecs. >> This would demonstrate there was even a handful of RubyGems users who would >> benefit from this feature but you did not (or could not?). > > Again, I did show you and you simply dismissed those cases as people > "refusing to conform to best practices". Ore was the most obvious > example --it was so important for that developer that they went out of > their way to create a whole project devoted to doing it. That appears to be a single user that is doing this, in the entire ecosystem. Last industry statistics put our user count at supposedly close to 1 million users. That's less than 0.1%. I don't see any innovation or improvement over other methods. In fact, most of the project yaml files appear to be Gem::Specification yaml files, just with the type header removed. And you can't tell me that your resource argument is relevant: https://github.com/ruby-ore/ore-core/tree/master/lib/ore https://github.com/ruby-ore/ore-core/blob/master/lib/ore/project.rb this also seems to have missed the point of object serialization entirely. I could go on, but that's not why we're here. >> You pointed out ore which uses plain-YAML to create gemspecs and gems and >> used it as an argument in your favor. >> >> I responded that if ore supports this you should use ore as it does what you >> want already and requires no changes to RubyGems. Since you did not >> demonstrate that there was another RubyGems user who desires plain-YAML >> gemspecs I responded that there is only one person that wants this feature >> and that was not enough users to include it. I reiterated that the >> community has decided they prefer ruby. > >> If you look at the download counts, people overwhelmingly prefer to use ruby >> to build gems. Hoe has 690,000 and Jeweler has 56,000. Ore has 453. > > This is unreasonable argument. I can't provide examples of something > that CAN'T exist. Both Ore and my own tools took many man-hours to > make it possible --so that's not something one can reasonably expect > of the common community. Clearly most people are not going to do that. > The community is not getting much of an option. Ore is brand new. So > it's not really a fair indication. Ore really needs a lot of work, and by work I mean a lot of code deprecation. The same effect can be gathered using far less code. I appreciate people putting time into things they're passionate about, but that doesn't make those passions good ideas for us to support. There are people on crypto mailinglists putting far more time than either of you into new crypto ideas, but you don't expect us to support those signing algorithms. You say that this can't exist, but you also say that Ore does it. It's easy to make a gem specification from a yaml file, either typed or untyped: >> YAML.load_file('metadata').class => Hash >> spec = Gem::Specification.new => #<Gem::Specification:0x101faea40 @licenses=[], @summary=nil, @post_install_message=nil, @description=nil, @dependencies=[], @bindir="bin", @require_paths=["lib"], @version=nil, @date=Tue Dec 14 00:00:00 -0800 2010, @new_platform="ruby", @loaded=false, @extensions=[], @authors=[], @cert_chain=[], @required_rubygems_version=#<Gem::Requirement:0x101fae8d8 @none=false, @requirements=[[">=", #<Gem::Version "0">]]>, @loaded_from=nil, @has_rdoc=true, @specification_version=3, @original_platform=nil, @extra_rdoc_files=[], @files=[], @signing_key=nil, @default_executable=nil, @email=nil, @test_files=[], @required_ruby_version=#<Gem::Requirement:0x101fae950 @none=false, @requirements=[[">=", #<Gem::Version "0">]]>, @requirements=[], @rdoc_options=[], @rubygems_version="1.3.7", @homepage=nil, @name=nil, @executables=[], @platform="ruby", @autorequire=nil, @rubyforge_project=nil> >> YAML.load_file('metadata').each { |k,v| spec.send(k + '=', v) }; spec => #<Gem::Specification:0x101faea40 @licenses=[], @summary="Web-application framework with template engine, control-flow layer, and ORM.", @post_install_message=nil, @description="Rails is a framework for building web-... I don't really get what all the fuss (or many man hours) is about? >> I now have a full page and over 1.5k of summary in this email of our >> conversation past the point where I closed the issue. We had a long and >> thorough discussion of the issue but you could not bring up any reason for >> inclusion of plain-YAML gemspecs. I believe that my conduct in our >> conversation was fair and reasonable and that any unbiased reader would find >> it so. > > I mostly agree. My only complaint with our conversation is what I > mentioned above. You seemed very short with me, as if you were annoyed > to have to discuss this, along with a rush to judgment --actually more > than that, the judgment seemed predetermined, so your end of > conversation always seemed stilted --it didn't feel like an earnest > conversation/debate. Some things may be obvious to use that aren't so to you. If you feel your case hasn't been understood then try to make it more clear. All I can suggest given your past issues is that instead of getting into an argument, maintain your clarity and state a clear case that something needs to go a particular way. As per my responses in this mail, I can't see any other reasons. Indeed after further explanation from Eric you seem to agree with the decision too. Maybe that means you need to take the feedback under more consideration before "feeling dismissed"? <snip> I'm out of steam and time. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
