On 16 May 2014 22:12, Stefan Krah <[email protected]> wrote: > Paul Moore <[email protected]> wrote: >> [1] I'm assuming that we don't have any cases where authors of >> maintained packages hosted outside of PyPI refuse to set up an index >> page. There's no technical reason why they should do so, but there >> remains the possibility of non-technical issues that need to be >> thrashed out, and consensus reached with the conclusions documented in >> the PEP. > > I think there are quite some cases, for example: > > https://pypi.python.org/pypi/bzr/2.6.0 > > > I *suspect*, but I may be entirely wrong, that they are using PyPI as a > catalog > and don't particularly care about automatic downloads. > > Reasons could include that on Linux distros one would use the package manager > to install bzr, and for Windows and OS X they have installers. > > Also, some companies do not like deep links to download material on their > pages and get litigious about it. > > > I think these pages should be left untouched. Under no circumstances should > direct links be created automatically for ethical and maybe even legal > reasons. > > > My view is that the respective maintainers should just be informed that > download tools will abandon crawling support. They should be able to keep > the pages, but pip should just comment that the package needs to be installed > manually and users should contact the package maintainer and not the pip team > in order to change the situation.
I think we're talking about different things. PEP 470 is talking about changing the content of https://pypi.python.org/simple/bzr/ (the simple index). You are talking about https://pypi.python.org/pypi/bzr/2.6.0 (the project index page in the web UI). As far as I know, https://pypi.python.org/pypi/bzr/2.6.0 will be unchanged by the PEP, whereas https://pypi.python.org/simple/bzr/ will become empty (as there are no direct download links on there). So users looking at the PyPI web UI will see no change. But pip will find no links to download for "pip install bzr" - which is actually *precisely* the same behaviour as now, unless the user adds ```--allow-unverifiable bzr``` (because there are no links with hashes on that page). So, as far as I can see, for bzr, the change would be that the project can: 1. Switch to hosting on PyPI and give their users the ability to use "pip install bzr" with no flags (I don't see why they would do this when they haven't already, but it's an option). 2. Create an index page that can be supplied to pip and register that on PyPI, to allow their users to continue to use "pip install bzr" with a flag that says they are happy with bzr's hosting arrangements (the precise flag will change but the implication is the same). 3. Accept that their users will no longer be able to use "pip install bzr" (although "pip install https://launchpad.net/bzr/2.6/2.6.0/+download/bzr-2.6.0.tar.gz"; remains available). If none of those options are acceptable to the bzr project, they should probably get involved in this discussion. But it's hard to see how we can specifically invite the maintainers of each of the 2000+ projects affected into this discussion - we *have* to rely on a level of interest in what's going on from the project. Publishing a PEP, discussing on distutils-sig, is a good start. If you think they should be involved, it would be very much appreciated if you contact them and invite them to join in. Equally, publicising this discussion would be great - post on python-dev, on reddit, or blog about it. Let's get people involved - please. We cannot do anything more based solely on speculation about what projects might think - we need them to tell us their reasons for what they are doing, and we can then start to work out how to address them. Paul _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
