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).

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 

"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.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to