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