[Distutils] Python people want CPAN and how the latter came about

Antonio Cavallo a.cavallo at cavallinux.eu
Sat Dec 26 22:45:10 CET 2009


> The PyPI discussions seem to be tending toward mixing the window dressing with the framing, to use a building analogy, and what that will result in is a weak frame and ugly windows.  A building that slowly (or quickly) falls down under its own weight, and looks bad doing it.
> 
> I think that splitting 
> 
> 	> package storage and pointers to off-repository storage (for those who don't upload to PyPI)
> 	> metadata about the stored packages
> 	> tools for creating stored packages
> 	> tools for retrieving stored packages
> 	> tools for installing packages
> 
> would go a long way towards unobfuscating this whole discussion

Is not what sourceforge already provide? Susebuild server could provide support to complete the loop:

> 	> package storage and pointers to off-repository storage (for those who don't upload to PyPI)

> 	> metadata about the stored packages

1 sorce/project management/metadata (sourceforge)

> 	> tools for creating stored packages
> 	> tools for retrieving stored packages

2 continuous build binary (susebuild)
3 package repositpry download (with programmatic api) on susebuild

> 	> tools for installing packages
yum/yast/apt etc tools are already there for linux o and supported on opensuse build server


Regards,
Antonio

If you can forgive my self promotion I've used this approach in a project of mine (pyvm.sf.net): is not completely automated, but it fits the bill point by point: moreover it has support for unitesting too.


> 
> Yes, I'm sure someone will disagree with some fine-point of that division but isn't that what  woodshedding is all about?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20091226/1d27a6eb/attachment.htm>


More information about the Distutils-SIG mailing list