[Zope-dev] "ZTK" futures: one big package?

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris McDonough wrote:
> 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.

I think we need to clarify terms / triage the sets of packages we are
talking about:

Truly reusable
- --------------

Things like the "bicycle seat toolkit" group (zope.interface,
zope.component, etc.).  These things ideally already have in-package
narrative docs, excellent test coverage, and minimal dependencies.  In
particular, they *cannot* depend on anything in one of the other sets.

Wannabe reusable
- ----------------

Candidates for promotion to the "truly reusable" set, but which aren't
yet ready.  E.g., they might be missing docs, or have a few remaining
dependencies which need breaking, or their testing is incomplete.  The
first pass for identifying this set should be the dependecies of the
trunks of Zope2 and Grok.  A package *cannot* be in this set if it
depends on any package the "never" set.

Never-gonna-be reusable
- -----------------------

One (or maybe more?) sets of packages which exist only to support a
given application (e.g., the Zope3 ZMI).  Each set should ideally be
released as a "mudball" distribution:  I will note that the eggified
Zope2 is one of these.  For the first cut, anything in zope.app would be
in this pile.


The goal would be for the ZTK to consist only of reusable packages, and
for Zope2 and Grok to depend only on pacakges in the ZTK.  By this set
of criteria, the urgent priority for Zope2 would be to break the expliti
dependency on the following packages:

 - zope.app.appsetup (Zope2.Startup, Zope.App.Startup)
 - zope.app.component (?)
 - zope.app.container (Products.Five.browser.adding)
 - zope.app.form (Products.Five.form.*)
 - zope.app.pagetemplate (Products.PageTemplates.Expressions,
                          Products.Five.browser.pagetemplatefile,
                          Products.Five.browser.metaconfigure)
 - zope.app.publication (ZPublisher.BaseRequest,
                         Products.Five.component)
 - zope.app.publisher (ZPublisher.BaseRequest, Products.Five.browser.*,
                       Products.Five.viewlet.metaconfigure,
                       Products.Five.form.metaconfigure,
                       Products.Five.fivedirectives)
 - zope.app.schema (Products.Five)

And the transitive dependencies on these packages (some of :

 - zope.app.applicationcontrol (zope.traversing, zope.app.publication)
 - zope.app.basicskin (zope.app.form)
 - zope.app.debug (zope.app.testing)
 - zope.app.dependable (zope.container, zope.app.testing)
 - zope.app.exception (zope.app.publication)
 - zope.app.http (zope.app.publication)
 - zope.app.interface (zope.app.component)
 - zope.app.localpermission (zope.app.security)
 - zope.app.security (zope.viewlet, zope.traversing, zope.testbrowser,
                      zope.app.*)
 - zope.app.testing (zope.viewlet, zope.container, zope.copypastemve,
                     zope.error, zope.dublincore, zope.formlib,
                     zope.traversing, zope.testbrowser, zope.site,
                     zope.app.*)

I'm not enough up on Grok to do a similar analysis there.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKCxDa+gerLs4ltQ4RAiIlAJ9o6ZYOiIxoLug25Rd+0OOch04nBQCeLVNm
stlvpyUMz+OXGXQbsfPFjGQ=
=ujuf
-----END PGP SIGNATURE-----