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

Martijn Faassen faassen at startifact.com
Wed May 13 13:22:14 EDT 2009


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

I think we should've gone for an approach where we slowly peeled off 
independent packages from a big ball in iterative fashion, instead of 
the giant explosion we ended up with. (assuming the tools allow us to do so)

Whether changing it back now would be a bug fix: I don't know, for two 

* we have the ability now to do fine-grained bugfix and feature releases 
of individual packages without having to coordinate all code. This of 
course is also a minus, sometimes.

* more nebulous: I do find that the explosion, for all its flaws, helped 
us with identifying bad dependencies. Peeling off packages would allow 
us to do this too, however.

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

meta: I don't like how you say that this is an article of faith, because 
you seem to imply that we're superstitious with this.

Concretely I have quite a few codebases around that depend on the 
current package list being present. They'd stop working if we suddenly 
withdrew these packages from PyPI. I think there are quite a few others 
in the same position.

> Maybe when setuptools grows "provides" and "obsoletes" setup parameters (ala 
> RPM), this particular problem can be solved better technically.

Yes, something like that would probably help.

>> 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'll start putting up a few of these notifications today.



More information about the Zope-Dev mailing list