[Zope-dev] "ZTK" futures: one big package?
Martijn Faassen
faassen at startifact.com
Wed May 13 13:22:14 EDT 2009
Hey,
Chris McDonough wrote:
[snip]
> 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
reasons:
* 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.
[snip]
>> 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.
Regards,
Martijn
More information about the Zope-Dev
mailing list