Closed mauritsvanrees closed 1 year ago
@davisagli This might be related to the plone.app.discussion
robot test problem.
It could also be something totally different.
IIRC, I ran into this problem too... I didn't dig this deep and didn't identify the getToolByName being the cause of that, but I started to correct old and deprecated imports. Now, I've created some PRs for that:
https://github.com/plone/Products.ATContentTypes/pull/42
... currently testing ...
Only, these fixes didn't solve the problem :/
I close the issue, because it addresses a Plone version that is no longer supported. If you think this is wrong please reopen the issue and assign a matching milestone.
I tried for good measure in Plone 5.2 Py 2.7, and bin/test -s plone.app.portlets
passes just fine. Solved.
In coredev 5.1 this fails:
bin/test -s plone.app.portlets
:This is when
plone.app.blob.markings
imports fromProducts.ATContentTypes.interface
. Whatmarkings.py
does, seems strange, and it looks like it expects old Zope2 interfaces in places where there are currently Zope 3 interfaces. That may be a different issue. If I temporarily makemarkings.py
almost empty, leaving only stubs for the two methods in there, then it goes wrong a bit further on.When I go in with a
pdb
, after I while I end up here:Near the beginning and at the end there is this line:
This means there is a circular import, which leads to an import error.
My eye fell on the line with the
earlypatches
module andexec code in utils.getToolByName.func_globals
, which imports fromATContentTypes
, which might be a hint of danger, given the failure I found earlier.. This used to be in thepatches
module, but a while ago I had to move it to be loaded earlier.I don't think the
getToolByName
security code really needs to be loaded this early. When I move that part back to the latepatches
, I can successfully run theplone.app.portlets
tests again. I then can also undo my temporary change inplone.app.blob.markings
.I will make a pull request.