zope.session 3.4.1 and zope.i18nmessageid 3.4.0a1 incompatibility

The incompatibility arises because zope.session requires zope.i18nmessageid >= 3.4.3 (it won't work with an older one) but completely fails to declare so in its setup.py (there, it says it required zope.i18nmessageid, but without any lower version constraint). So there's actually a bug in zope.session here, which is why I added 'Zope 3' to the affected projects.

I shall add that I believe importing ZopeMessageFactory from anywhere is stupid, for two reasons:

1. It's dead-easy to recreate:

from zope.i18nmessageid import MessageFactory
_ = MessageFactory('zope')

Importing this is like importing an integer or a string.

2. With the independent projects now, we should really split up the translation domains as well.

On 18.04.2008, at 12:36, Philipp von Weitershausen wrote:
> I shall add that I believe importing ZopeMessageFactory from
> anywhere is
> stupid, for two reasons:
>
> 1. It's dead-easy to recreate:
>
> from zope.i18nmessageid import MessageFactory
> _ = MessageFactory('zope')
>
> Importing this is like importing an integer or a string.

I think exactly the other way round. It is a constant so bind it to
something you can track and import it. This is a very common pattern I
think. For instance docutils declars constants like REPORT_NDIFF. I
suppose you're not writing down those integers but import?

>
>
> 2. With the independent projects now, we should really split up the
> translation domains as well.

Ack. I think over the time this will happen naturally when new
translations are required.

--
Christian Zagrodnick

gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

On 21 Apr 2008, at 09:23 , Christian Zagrodnick wrote:
> On 18.04.2008, at 12:36, Philipp von Weitershausen wrote:
>> I shall add that I believe importing ZopeMessageFactory from
>> anywhere is
>> stupid, for two reasons:
>>
>> 1. It's dead-easy to recreate:
>>
>> from zope.i18nmessageid import MessageFactory
>> _ = MessageFactory('zope')
>>
>> Importing this is like importing an integer or a string.
>
> I think exactly the other way round. It is a constant so bind it to
> something you can track and import it. This is a very common pattern I
> think. For instance docutils declars constants like REPORT_NDIFF. I
> suppose you're not writing down those integers but import?

No, but there the integer has a meaning that's hidden from me.
Recreating the message factory in individual packages was also common
practice in split-ups before (it's even documented in proposals).
Either way, in the light of splitting up projects, the dependency
shouldn't have been introduced in the first place (nor should the
ZopeMessageFactory thing have moved to zope.i18n). And it wasn't
covered by a proposal...

But let's bury the past. I just hope we can learn from this, we need
to be pragmatic in some places if we want to reduce the
interdependencies of packages. It's a mess, and stuff like this
doesn't make it better.

>> 2. With the independent projects now, we should really split up the
>> translation domains as well.
>
> Ack. I think over the time this will happen naturally when new
> translations are required.

I disagree. If so, whoever did the package refactoring that led to
this very bug would've realized the same thing and done it. But they
didn't. This would actually be a nice sprint task, I think.

Oh, actually what I was suggesting was to seperate the i18n domains so that each package has its own. You'd only import the MessageFactory in your own package then.

I've reassigned the issue to Philipp. Philipp, is this still a valid issue for Grok 1.0? If so, what are our next steps? If not, what do we do then?

In terms of Grok, this issue has been fixed a long time ago by moving to newer versions of the relevant packages. The general problem of Zope 3's i18n domain(s) still exists.

I have added minimum version to zope.session's setup.py
But this does not matter as much newer versions are used anyway.