On Tue, Jul 13, 2010 at 14:46, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Jul 13, 2010 at 7:05 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
And I'm not disagreeing with the policy, but it can be argued that depending on the location of *data* files inside the Zope2 package is not necessarily relying on "guarantees on internals".
I'd call anything that relies on a specific file system layout to be internals. We only make guarantees on the semantics of the Python import system, not how packages and modules are stitched together in distributions and end up on the file system.
Considering that the Zope source code has a dozen examples of App.ImageFile.ImageFile being used without a prefix (ex. "OFS.misc_"), I think third party developers should be excused to think they could follow the lead and expect their packages not to break during a stable series. I still think we should give them at least the 2.12 series to stop using ImageFile "incorrectly" without breaking their code, but I won't belabor the point any longer.
Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs that do rely on software_home) should give a clear warning when software_home is assumed, since it is the one assuming it. The exception raised by the ImageFile call now gives no clue on what actually went wrong and what a developer should do about it.
I agree with that. I thought the call to software home was being made inside ZMySQLDA and not in Zope 2 code.
The attached patch adds such a warning, and also reveals where Zope2 commits the same sins. If there are no objections I'll commit it to 2.12 and trunk. Finally, I'd like to ask that, when major changes land in a stable series (like the spinning off of a whole package), that we allow at least a week or two to pass before making a release, so people who have test runners for their apps running against a stable repository branch have time to adapt to the changes Cheers, Leo