Leverage metadata to populate gems urls v2

[kbrock]

High Level Goals

1. The app knows too much about the url generation process. Provide a decorator versioned_links to simplify this logic.
2. More importantly: All metadata for a gem comes from the gemspec file except for urls. Provide a mechanism to put urls into the gemspec.

goal 1 makes the process of fetching the urls out of gemspec trivial - 2 lines of change. If we are unsure about #2, then can we at least focus/agree on the first goal?

Commentary

This is an alternative to #724. It is in response to comment from @qrush [here] For implementing #1127 - take urls from rubygems.metadata and retire linkset.

@arthurnn I thought it would be simpler to keep this separate from #724. Let me know if you want me to add metadata (and/or add change log) support directly to this PR. I added in the metadata as the second commit

before:

Links on the pages are generated from Links and Version objects. This is needed because some urls have version.number.
This logic finds it's way into rss, views, helpers, and models. Mostly in rubygems.rb, rubygems_helper.rb, and links.rb.

after:

A decorator LinkedVersion is introduced to simplify the relationship between these objects. Since rss uses this as well, the decorator is kept in app/model/.

future:

Once rubygems.metadata is used by most (all?) gems, drop linkset. (many years from now)

Thanks,
Keenan

UPDATED: hope this is more readable

[kbrock]

fixed cops

[homu]

☔ The latest upstream changes (presumably #1294) made this pull request unmergeable. Please resolve the merge conflicts.

[kbrock]

@arthurnn / @dwradcliffe Any thoughts on this PR?

I separated this into 2 commits.

The first one is consolidating the version specific knowledge while the second one is moving forward on the meta-data route.

If you want me to pull out the first one for now (as it will not actually change any behavior) just let me know.

[djberg96]

@drbrain @qrush @dwradcliffe @bf4 @arthurnn @mpapis @segiddins Any objections?

[simi]

What about to move Links model under Rubygem namespace aka Rubygem::Links?

[djberg96]

@simi None of the other models do this.

[homu]

☔ The latest upstream changes (presumably #1433) made this pull request unmergeable. Please resolve the merge conflicts.

[homu]

☔ The latest upstream changes (presumably #1487) made this pull request unmergeable. Please resolve the merge conflicts.

[homu]

☔ The latest upstream changes (presumably #1506) made this pull request unmergeable. Please resolve the merge conflicts.

[kbrock]

updated to fix conflict. (had extracted a commit into the separate PR)
also added tests around indexed.

[kbrock]

@sonalkr132 / @dwradcliffe would you like me to introduce the Links set as a single pr

This PR is 2 commits:

1. Create a single model that has the data necessary to represent Links (linkset, version.number, and gemset.name).
2. Allow Links to also read from version.metadata.

I had thought just consolidating the 2 commits into a single PR would make things simpler for all. But after 10 months, I'm not so sure. And the original PR is even older.

Question: Since the first commit does not change any business logic, would you prefer I pull that out?

[homu]

☀️ Test successful - status

[simi]

🎊

[sonalkr132]

@kbrock Can you please explain your reasoning for using metadata specs named *_uri? I understand the need for a long method, however, I think using the shorter version (home, code etc) in metadata would be easier to use.

spec.metadata = {
    "home"      => "https://some.github.io",
    "code"      => "https://github.com/some/gem",
    "docs"      => "https://www.rubydoc.info/gems/some/0.0.1",
  }

vs:

spec.metadata = {
    "homepage_uri"       => "https://some.github.io",
    "source_code_uri"    => "https://github.com/some/gem",
    "documentation_uri"  => "https://www.rubydoc.info/gems/some/0.0.1"
  }

[mpapis]

@sonalkr132 the key names must be informative, there is more names https://github.com/rubygems/rubygems.org/pull/1234/files#diff-b77c80170c3a1963bb4915b58c139b43R3 and they could be confusing, long versions do not leave place for misinterpretation