On Fri, Dec 25, 2009 at 05:39, Sridhar Ratnakumar <sridh...@activestate.com> wrote: > Is it because of this benefit to package authors that we are withholding the > implementation of a simple archive that would: 1) simplify the tools to no > rely on adhoc web scrapping
There are better ways to do that. > 2) reduce the downtime for users by rsync/ftp mirroring This is true, but the idea to upload them by robots is preferable in my opinion. Again it's a difference between trying to force other people to behave to your expectations vs trying to make it easier for others to behave to your expectations. > 3) have package sources mirrored so project owners do not have to > worry about downtime of their servers. That's *their* problem. If they don't want to upload, then they don't want to upload. > 4) enable proliferation of third-party tools like CPAN? That won't help. On Fri, Dec 25, 2009 at 05:48, Sridhar Ratnakumar <sridh...@activestate.com> wrote: > On 12/23/2009 10:42 PM, Lennart Regebro wrote: >> >> On Wed, Dec 23, 2009 at 23:28, Sridhar Ratnakumar >> <sridh...@activestate.com> wrote: >>> >>> I suggested PyPI to disallow mere project listings (without sources) and >>> require sources to be stored in the server. One way to achieve this is >>> requiring package authors to use the `sdist upload` toolchain >> >> Which only means the packages who now is not uploaded wouldn't even be >> listed on PyPI, which is not an improvement. > > We can do this only for the new projects/uploads. Existing data can be left > as it is for backwards compatibility. Which only means the packages who in the future will not be uploaded will not even be listed on PyPI, which is not an improvement. > Nope, it matters not whether the metadata can be retrived via a simple HTTP > GET or XmlRpc. OK. Then you have two proposals: 1. Require uploading, which is a bad idea and 2. Making it easier to mirror the metadata, which seems reasonable, assuming it's currently hard. :) > Metadata is definitely needed. Otherwise, I'd have to extract the tarball of > each and every release of a pacticular package, in order to even find their > version number (it is unreliable to parse the filename to get version > number). Yes, but it's not particularly unreliable to compare the filename to see if it had been handled before. You don't even need to parse the version number for most services that work on the tarballs. > As for the sdists, the following tools would need it: testing service, > quality ratings, thirdparty package managers (enstaller, PyPM) .. and not to > mention the various mirror sites. Yes, but since thay have the source package, and will have to unpack it and build the packages anyway, they also have the metadata. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
