[Catalog-sig] Deprecate External Links

[Donald Stufft]

On Wednesday, February 27, 2013 at 4:31 PM, PJ Eby wrote:
> So far, I don't think anybody's talking to the right "we" for stopping
> it. It's the tools that control this, not PyPI. (PyPI can't actually
> stop the tools from using this information without also making itself
> a lot less useful to *humans* at the same time.)

I have issues out for pip and buildout, didn't have time to find
and make issues for setuptools and distribute but I plan on doing that
as well. However PyPI _can_ stop publish that info on the simple index.
If tooling wants to go out of their way to scrape the human pages that's
their problem and would be unsupported. By not publishing that
content we make a clear line of what is and isn't supported for the
tooling to use.
> 
> As far as my personal position on the matter, I think that it's
> reasonable to deprecate the scraping of home page and download links.
> As somebody pointed out, expired domains are a potentially nasty
> problem there.
> 
> OTOH, I currently make development snapshots of setuptools and other
> projects available by dumping them in a directory that's used as an
> external download URL. Replacing that would be a PITA because PyPI
> only lets you upload and register new releases from distutils' command
> line. Basically, I'd need to use a download link that pointed to a
> "latest" URL that redirected to the final download.

Development snapshots are a use case that i'm not sure makes sense
for PyPI, but if they do should require specific opt-in to install them. Does
easy_install have a command line flag that adds extra links? pip has --find-links
can your instructions simply state to do the equivalent of
`pip install --find-links=http://setuptools.com/dev-snapshopts/`?

Alternatively I would like to get the tooling smarter about not installing
pre-release versions unless asked as well. So with that the answer
could simply be to make dev releases to PyPI, (PyPI will probably
need some sort of prefer stable option for it's web ui), and have
the tooling prefer stable releases.
> 
> Anyway, I'm not seeing much discussion here about how to help authors
> make changes to their release processes. Note that many popular and
> long-lived projects (pywin32, PIL, etc.) have similar issues. (Not to
> mention the newer projects that host directly from revision control.)

Most of these projects are already running python setup.py register,
so for the vast bulk of them they'll just need to add a sdst upload to that.
> 
> Given that easy_install was deliberately designed so that those guys
> would *not* need to change their hosting strategies to get automated
> downloads, I'd like to see more talk about how we're going to help
> people change their releasing and hosting strategies.

Someone has made a comment about making a script to make it easy
to make old versions available on PyPI for authors. I believe for
most people the change should be fairly easy since they are already
registering their releases. However if someone has an odd release
process I'd be willing to try and help them fit the new requirement
into it. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130227/e5f7f3d1/attachment.html>