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 -