On 5/13/09 10:34 AM, Martijn Faassen wrote: > Hey Chris, > > What about the following alternative suggestion to alleviate some of the > underlying issues you point out. > > I agree we are signaling badly which packages are interesting to > newcomers and outsiders and which packages aren't. > > In part we've already done the damage with the packages in the "zope.*" > namespace. I think we shouldn't try to put humpty-dumpty back together > again marketing-wise by removing those packages a few years after their > release, and whether this is worth the effort (and I see negative > drawbacks to doing so).
I'd hope you'd agree that given a perfect world where packaging structure backwards compatibility was not a concern: - The original distribution structure was a mistake. - Changing it would be a bugfix. That said, given your other arguments in prior mails today, I'll give up agitating for any packaging changes on this maillist, because it's pretty much impossible to argue against the article of faith that there is some presumed majority of thousands-of-people-who-depend-on-those-packages-as-distributed-now-and-whom-will-forever-want-to-do-so-and-whose-world-will-explode-if-we-take-them-away. Maybe when setuptools grows "provides" and "obsoletes" setup parameters (ala RPM), this particular problem can be solved better technically. > What we can do is start to clearly indicate on top of a package's > documentation whether it's intended to be independently reusable outside > of a Zope context or not. We should do this on pypi, but we should also > back this up by writing narrative documentation for those packages we > *do* think are independently reusable by a wide audience. I think this > should be done by starting 'doc' directories in those packages and > putting in sphinx-based documentation. > > The next step would be to go to our "non-reusable" packages and start > writing narrative docs for that, ideally with example projects. If we > pick a few likely candidates and do some more refactoring we may be able > to salvage them into reusable packages and we can declare them as such. > > As indications I propose: > > "This package is intended to be independently reusable in any Python > project. It is maintained by the Zope Toolkit project." > > (with hopefully appended: "For more documentation on this see<narrative > docs>.") > > "This package is at present not reusable without depending on a large > chunk of the Zope Toolkit and its assumptions. It is maintained by the > Zope Toolkit project." > > We can also add 'reusable' to the metadata tags in PyPI in addition to this. I think this is a reasonable workaround if the packaging structure does not change. Thanks for the responses, - C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )