> 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?
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
