style: require long urls for pypi and pythonhosted urls

[Rylan12]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

See #8029 for the discussion behind this change

Require urls like https://files.pythonhosted.org/packages/a0/b1/a01b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f/foo-0.1.tar.gz instead of https://files.pythonhosted.org/packages/source/f/foo/foo-0.1.tar.gz or https://pypi.python.org/packages/source/foo/foo-0.1.tar.gz

Homebrew/core PR: Homebrew/homebrew-core#58181

Tagging @SeekingMeaning, @dtrodrigues and @SMillerDev

[Rylan12]

I'm open to feedback on the rubocop problem messages. Currently they are:

use the `files.pythonhosted.org` url found on the pypi downloads page for pypi.python.org urls

and

use the longer version of the url found on the pypi downloads page for short files.pythonhosted.org urls

[SeekingMeaning]

I would take out "longer version of the" and go with "use the url found on the pypi downloads page"

[dtrodrigues]

Looks good

Before Homebrew/homebrew-core#58181:

$ brew audit --strict stormssh
stormssh:
  * C: 33: col 5: use the longer version of the url found on the pypi downloads page
  * C: 48: col 5: use the longer version of the url found on the pypi downloads page
Error: 2 problems in 1 formula detected

After:

$ brew audit --strict stormssh
$

I'd say something like use the Source url found on the PyPI "Download files" page.

It might be overachieving, but if you extract the PyPI project name from the original url, you could also suggest they go directly to https://pypi.org/project/#{pypi_name}/#files and use the Source url.

[Rylan12]

I'd say something like use the Source url found on the PyPI "Download files" page.

I like this. It's clearer about which url to use which is good. Ideally, the style check can suggest the correct url but I'm not sure how to have it figure out what the correct url is.

It might be overachieving, but if you extract the PyPI project name from the original url, you could also suggest they go directly to https://pypi.org/project/#{pypi_name}/#files and use the Source url.

I like this but I worry that users will be confused and put https://pypi.org/project/#{pypi_name}/#files as the url instead of finding the correct one at that page, if you know what I mean. I'll take a look, though, and see how it looks

[Rylan12]

@dtrodrigues how about this:

❯ brew style stormssh
== stormssh.rb ==
C: 33:  5: use the Source url found on PyPI downloads page (https://pypi.org/project/pycrypto/#files)
C: 48:  5: use the Source url found on PyPI downloads page (https://pypi.org/project/termcolor/#files)

1 file inspected, 2 offenses detected

Looks like this on my terminal:

[dtrodrigues]

Looks good @Rylan12

You can use automate it via the PyPI API to provide the exact url by looking at https://pypi.org/#{pypi_package}/json and getting the url in the urls array with the sdist packagetype, but I think the current message is clear.

[Rylan12]

Thanks for the tip. I'll take a look. I'm not sure exactly how to implement that in ruby so if you have any tips let me know 😄

[dtrodrigues]

I think it's good for now as-is, especially because getting the exact url would need to be gated behind an --online flag since it requires an internet connection to function. We might want both versions of the message available depending on if they're able to connect to PyPI or not.

If you want to roll that into this PR as well, I can take a look tomorrow or somebody else may be able to help today.

[Rylan12]

As pointed out in #8032 (comment), implementing an autocorrect feature would require an audit rather than a rubocop.

Personally, I think what's already here is enough. All URLs currently being used are already in the long-form, so I don't see a huge benefit to having it autocorrect. Plus, it already directs the user to the correct page, so it feels like an unnecessary optimization (at least at this point).

^ That's just my opinion, though, so I'd be happy to work on or take a look at something like that if it's desired.

[jonchang]

Looks good, let's

[Rylan12]

Thanks to everyone for the comments and suggestions!

[jonchang]

Thanks for your hard work on this @dtrodrigues @Rylan12 @SeekingMeaning!

[MikeMcQuaid]

Nice work @Rylan12!