I'm converting LocalFS 1.12 from Thimo Kraemer to Zope 4 and currently it can browse the local file system. However, when I try to view a file in the ZMI (or GET it), I get the error: The object at ... has an empty or missing docstring. Objects must have a docstring to be published.
However, I don't get any traceback from Zope (using bin/runwsgi -vd etc/zope.ini).
I can springle some prints to see where it dies, but really it would be much better to get the traceback. Any ideas?
The check is made in the main traversal code ZPublisher.BaseRequest.BaseRequest.publishTraverse. On failure, it raises a Forbidden exception. You could try to reconfigure your error_log object, to ensure that it does not ignore those exceptions.
Thanks, I'll go for the breakpoint in publishTraverse. There is no "Forbidden" exception to filter in the error_log. I also had a quick look at the SiteErrorLog.py but it is not obvious how it works to get exceptions. The error header says "Debugging notice. Zope has encountered a problem publishing your object."
This is correct although the under underlaying implemenation is pretty much Zope specific...but yes, not a replacement but solving addressing similar usecases.
so, it was not really a missing docstring. Rather, in BaseRequest.py(84):
subobject = object.bobo_traverse(request, name)
subobject becomes None and the code does not check for this scenario. The error message is misleading.
bobo_traverse (LocalFS) had a several low-level py3 incompatibilities and one ZODB incompatibilty (repr(TimeStamp) is not an 8-byte array).
Another issue, maybe Zope related, is that while building a wrapper, LocalFS takes a method (e.g., Image.File.manage_edit) and plugs it into the file wrapper. However, LocalFS was expecting a method, naturally, and in fact it gets a function. This smells like a Zope issue, if someone wants to research it. I can file an issue but I don't want to create noise.
Anyway, now, non-zope files in the local file system can be served.
I didn't try other functionalities and I guess there are plenty of issues in LocalFS (e.g., it provides bobobase_modification which is not used anymore). Interestingly, most issues so far have been py3 related and I really sympathise with folks facing migrations involving low level stuff.
This is Python 3 related: accessing a method directly on a class (rather than a class instance) gives a function in Python 3 (and no longer an "unbound method" object). The function will behave almost identical to an "unbound method" (it just lacks the isinstance/issubclass check).
For information, the wrapped method manageEdit breaks when editing a text file which generates further exceptions in Zope. I'll try to look into it later but currently I don't need edit functionality.
@zfm I am very happy that somebody works on porting LocalFS as Thimo told me a couple of months ago that he does not plan to do any more work on it.
One of my applications, currently on Zope 2 /Python 3, also relies on this package. There is already good progress moving it to Zope 4 - Python 3 will follow quite some time later.
Do you have any plans to release this package on PyPi? Would be great!
I cannot test your current state against my app, but if there is anything else I could do to help the migration, please do not hesitate to contact me.
P.S.: Encouraging the friendly Plone folk to create a Zope subforum already pays off
in the meanwhile manageEdit is working for text files (not for big ones, no idea why) and I fixed several py3 problems. I have no idea how to publish in pypi and no time now to learn. If you can help with that, fine. Feel free to put any feedback or request on the repository. no promises, of course
