[Catalog-sig] A 90% Solution

PJ Eby pje at telecommunity.com
Tue Mar 12 01:12:09 CET 2013


On Mon, Mar 11, 2013 at 7:39 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On Mar 11, 2013, at 7:04 PM, PJ Eby <pje at telecommunity.com> wrote:
>
>> Just a thought, but...
>>
>> If 90% of PyPI projects do not have any external files to download,
>> then, wouldn't it make sense to:
>
> To be accurate it's 90% don't have any files/release available *only* externally. Most have external  files to download because it's very rare that a project doesn't include an home_page or a download_url, especially since distutils complains if you don't.

So what is the % of projects for whom the option can be disabled
automatically, *without* disabling automated downloadability of a
project's externally hosted files?

Your statement is confusing to me, because the having of a home page
or download URL doesn't have anything to do with whether that page has
any files to download from it.

I am saying that if a project has no *downloadable* files (not web
pages) whose links can only be found by spidering, then we can turn
off the rel attribute.

How many projects do not have any download links listed on their
rel=""-linked pages?


>> 1. Add a project-level option to enable or disable the adding of the
>> rel="" attribute to /simple links (but not affecting the links in any
>> other way)
>> 2. Default it to disabled for new projects, and
>> 3. Set it to disabled *now* for the 90% of projects that *don't have
>> external files*?
>
> +1 except 1. should be to remove the links entirely from the /simple/
> index, not to just remove the rel attribute.

-1, since sometimes download links are in fact *download links*.  So
this design choice would unncessarily limit the number of projects for
whom the option could be applied automatically and immediately.

That is, a project with a download link of "foobar.com/foobar-1.2.tgz"
would no longer be usable if you removed the download link from the
/simple index, but would remain usable if the rel attribute were
removed.


More information about the Catalog-SIG mailing list