[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