On 9/28/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Jeff Shell wrote:
> One blow-up instance was on something that was marked deprecated (a
> vocabulary that used `zope.app.utility.vocabulary.UtilityVocabulary`
> as its factory).
How? can you provide a traceback? Like Jim said, we tried having 3.3 be
It's a reference that was marked as deprecated, and that it would go
away in 3.3. Now it's 3.3, and it's gone! It's just something that I
wish I had caught sooner, but it was an easy fix.
> Strangely, I never saw that deprecation warning, or I
> would have fixed it a long time ago. It looks like deprecated items
> referenced in ZCML wouldn't trigger the warnings in Zope 3.2, whereas
> Python based importing/referencing would.
Hmmm. Weird. Can you reproduce this? If so, please file a bug.
I'll submit one if I can make an easily re-producable case. I'm a bit
swamped right now.
> That said, I still don't really know much about what's new and
Ugh, that's bad. I'm sorry if we've been unclear. Does
Yes. Why isn't that linked off of any sensible page or place in the
Zope 3 wiki? Releas page? I was pretty sure someone had been working
on such a document. But I couldn't find it at all, which is why I
> I see a lot of things in the Wiki in proposals, but the
> proposals don't always mirror final implementations, so sometimes it's
> a bit of a guessing game if one even has that to go on. Only a few of
> the proposed ZCML reductions went into play, correct?
I just checked and the "Implementation status" section is correct
regarding Zope 3 ("trunk" refers to 3.3 though).
I admit, though, I coudl've done a better job updating the proposals
after having implemented them. Without moving the blame elsewhere, I
think we should consider a more formal proposal process again, like I
suggested once. Python PEPs and Plone PLIPs seem to work very well.
I agree. The Wiki is perhaps a good place to collaborate or brainstorm
initially. But there's just not enough data ever available to maintain
pages like this:
without a lot of human intervention (manually creating the tables,
status information, owner information, etc, in multiple places).
> It would be nice if there was at least a small document that went
> through deprecated items and covered how to migrate away from them -
> separate from the change log or proposals.
I've tried to emit helpful deprecation warnigns that dont' just say
"this is deprecated" but also say "use XYZ instead". The proposals
should also document this. What is it that you're particularly
I saw those messages! Those made me happy. And that kpug.zwiki.org
page looks like it'd be very helpful too.
I'm struggling with the "migrate by hitting ./runzope over and over
again until the thing starts up...." Having some better information
before I even download a Zope release would help - including reminders
that certain features that had been marked for removal in 3.3 have
actually been removed. I have some old Zope 3.1 era code that I'm
trying to update right now. It was made to work comfortably with Zope
3.2, but we had one customer continue along with that installation and
we've just forgot about it and never got around to the "change this
when everything is running on Zope 3.2" comments we had lying around.
> Now, here's the strange one:
> What happened to Tools? `zope.app.component.browser.tools`? I'm not
> even sure what tools were,
We weren't either ;) so we got rid of them.
I was able to get rid of our references with no change in expected
behavior, so I think we're good. Like I said, I think we just used
those directives because we saw someone / something else doing it. We
certainly weren't getting any special behavior out of them that I know
of, I just wanted to be sure I could kill them off completely.
Zope3-users mailing list