Resources2

[trans]

I might fit the Einsteinian definition of insane for this, given the previous engagement, but I deemed it rather wasteful to throw away the constructive aspects of the dialog on this feature, despite all the nonconstructive garbage. Since I had already endeavored at it once, no doubt its an easier matter for me to try again then for most others to come at it anew.

This rendition simplifies to whole matter to a simple Hash attribute in the gemspec itself. Resources can be assigned directly, e.g. resources = { :type => uri, ... } or individually via the helper method add_resource(type, uri). For convenience of writing gemspecs, a few short terms for common resource types are translated to longer canonical names. This is simply for writing, not for reading. Validation of URIs is handled in the validate method.

The hardest part of this was mapping the old homepage attribute to the resource hash so as to maintain backward compatibility. This patch is close (and appears functional) but is not yet perfect in this regard. I left homepage as an attribute and rerouted the accessors to resources. I think this is probably the right way to do it and it seems to work fine. But to_ruby will still add both the homepage = ... and resources = entries (functional albeit redundant). For _dump, I put nil in the homepage slot and for _load I skipped the homepage assignment (which I simply commented out at this point). Someone with a little more experience with this code can make the final decision on how best to handle this particular issue.

With this patch I have taken the constructive parts of the critiques I received in my previous attempt and sought to address them while still providing some of convenience and greater functionality I originally had in mind to help improve the Gem::Specification.

As mentioned above, I do not consider this patch complete and ready to commit to master, but I think a few more tweaks should be enough to make it so (assuming of course that the overall approach is acceptable.)

[SIDE NOTE] I would like to make a personal request that Ryan Davis not critique this code (unless he wishes to apologize for past behavior). I don't find his comments very helpful and I believe he purposely attempts to insight me to anger (which he's pretty good at! ;-) I don't think it's an unreasonable request considering. Of course, feel free to ignore this push request altogether too, but I at least wanted to try make amends for my part in previous tensions and to produce something actually constructive out of it all.

[zenspider]

[SIDE NOTE] I would like to make a personal request that Ryan Davis not critique this code (unless he wishes to apologize for past behavior).

I didn't actually see this until after I went through your commit. I reject the notion regardless.

I don't find his comments very helpful and I believe he purposely attempts to insight me to anger

OMG... Don't flatter yourself. I reviewed the code, not you. Your last submission was written in a vacuum and needed a thorough code review to fully shake it out. There was a design or code issue in nearly every paragraph of code. Who that submission came from was only a side-note that affected the tone of a couple comments. Had I known the commit came from a GSoC student, for example, I would have toned those down. You, however, should know better.

This submission is much much better. If I had to guess, I'd say it was roughly 1/3rd the size of the previous (now vaporized) submission, which would be pretty close to my estimate that the last submission was 300% of what it should have been. I think there are some areas that still need to be fleshed out and discussed, like whether we should allow arrays of urls in the values of the hash, or whether we should expose general access to the hash or only allow insertion via api... but all in all this is much more in tune with how rubygems works.

[erikh]

As someone who likes to follow these tickets, and doesn't get the emails, holy crap it is next to impossible to follow these with certain members of the conversation deleting all their posts.

If I may be so bold, trans, if you're going to go to the trouble of deleting all your posts, just delete the damned pull request.

[trans]

@ryan Fair enough. Let's let bygones be bygones, and move on from here.

I made an update to the branch, that I think resolves the redundancy issue. I simply substituted resources for homepage. Then wrote special accessors for each to look at @resources. If it is a String then it is the homepage; if it is a Hash then resources. Have a look and let me know if it does (or doesn't) do the trick.

I also converted to symbols as you suggested. The other details you mention are probably best hammered out by you and the rest of the RubyGems team.

Note that I thought about a urls array too, but I think it might prove too problematic for effective utilization, eg. on the rubygems.org profiles.

[trans]

@erikh I tried to do exactly that, but could not find a way to delete the pull request. In a late night stupor of dismay I deleted my comments. I should not have done that. Sorry. I've since made a support request to remove the pull requests that have now been made redundant by new submissions.

[zenspider]

Looks like this is dead.