(re)moving browser subpackage from zc.catalog?
Hi, Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a permission name that has been removed from zope.dublincore). This made me realize that zc.catalog contains ZMI code in the browser subpackage. Are people still using this ZMI code from zc.catalog? Would it be an idea to move the ZMI code out of the package (a bit similar to how various zope.app.* package have been refactored)? It would make maintaining this package in respect to the ZTK easier. Kind regards, jw
I would like the ZMI views and zope.app dependencies be removed as well. I think I remember even some tests fail with ztk1.0? 2010/10/5, Jan-Wijbrand Kolman <janwijbrand@gmail.com>:
Hi,
Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a permission name that has been removed from zope.dublincore). This made me realize that zc.catalog contains ZMI code in the browser subpackage.
Are people still using this ZMI code from zc.catalog? Would it be an idea to move the ZMI code out of the package (a bit similar to how various zope.app.* package have been refactored)? It would make maintaining this package in respect to the ZTK easier.
Kind regards, jw
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
2010/10/5, Jan-Wijbrand Kolman <janwijbrand@gmail.com>:
Hi,
Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a permission name that has been removed from zope.dublincore). This made me realize that zc.catalog contains ZMI code in the browser subpackage.
Are people still using this ZMI code from zc.catalog? Would it be an idea to move the ZMI code out of the package (a bit similar to how various zope.app.* package have been refactored)? It would make maintaining this package in respect to the ZTK easier.
Kind regards, jw
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
Hi,
Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a permission name that has been removed from zope.dublincore).
Actually the permission has been renamed (from zope.app.dublincore to zope.dublincore) to get rid of the "app" part in its name.
This made me realize that zc.catalog contains ZMI code in the browser subpackage.
Are people still using this ZMI code from zc.catalog? Would it be an idea to move the ZMI code out of the package (a bit similar to how various zope.app.* package have been refactored)? It would make maintaining this package in respect to the ZTK easier.
zc.catalog has only test dependencies on zope.app.* packages. So you do not install these dependencies when using zc.calalog as a library. The zope.app.* dependencies might need a bit polishing. But I do not see a big win moving the browser part into a separate package. Especially as zc.catalog should depend on this new package for backward compatibility reasons (at least for a while). Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 10/6/10 08:08 , Michael Howitz wrote:
Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a permission name that has been removed from zope.dublincore).
Actually the permission has been renamed (from zope.app.dublincore to zope.dublincore) to get rid of the "app" part in its name.
If I would be pedantic here I'd say there is no such thing as renaming a permission. When the old name is gone, it is gone. There's no mechanism similar to the BBB imports for the permission ids.
This made me realize that zc.catalog contains ZMI code in the browser subpackage.
Are people still using this ZMI code from zc.catalog? Would it be an idea to move the ZMI code out of the package (a bit similar to how various zope.app.* package have been refactored)? It would make maintaining this package in respect to the ZTK easier.
zc.catalog has only test dependencies on zope.app.* packages. So you do not install these dependencies when using zc.calalog as a library. The zope.app.* dependencies might need a bit polishing. But I do not see a big win moving the browser part into a separate package. Especially as zc.catalog should depend on this new package for backward compatibility reasons (at least for a while).
Actually, it is more than just a test dependency. The toplevel configure.zcml conditionally configures the browser subpackage whenever zope.app.form is available. This zope.app.form conditional is not even "enough", as sometimes you can still have zope.app.form on your path, but zcml directives like addMenuItem and editForm used in zc.catalog.browser's configure.zcml might not have been configured. I could imagine we change zc.catalog so that the toplevel configure.zcml never includes the browser subpackage's configure.zcml and people that need the ZMI code, need to include the zc.catalog.browser subpackage themselves. This would still leave the test dependency (which is annoying but alas), but at least make the zc.catalog easier to reuse. regards, jw
Am 13.10.2010 um 10:02 schrieb Jan-Wijbrand Kolman:
On 10/6/10 08:08 , Michael Howitz wrote:
Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a permission name that has been removed from zope.dublincore).
Actually the permission has been renamed (from zope.app.dublincore to zope.dublincore) to get rid of the "app" part in its name.
If I would be pedantic here I'd say there is no such thing as renaming a permission. When the old name is gone, it is gone. There's no mechanism similar to the BBB imports for the permission ids.
Not pedantic enough as there is a mechanism to rename a permission, see http://pypi.python.org/pypi/zope.dublincore/3.8.0#id3 In version 3.7.0 the backward compatible renaming was removed.
This made me realize that zc.catalog contains ZMI code in the browser subpackage.
Are people still using this ZMI code from zc.catalog? Would it be an idea to move the ZMI code out of the package (a bit similar to how various zope.app.* package have been refactored)? It would make maintaining this package in respect to the ZTK easier.
zc.catalog has only test dependencies on zope.app.* packages. So you do not install these dependencies when using zc.calalog as a library. The zope.app.* dependencies might need a bit polishing. But I do not see a big win moving the browser part into a separate package. Especially as zc.catalog should depend on this new package for backward compatibility reasons (at least for a while).
Actually, it is more than just a test dependency. The toplevel configure.zcml conditionally configures the browser subpackage whenever zope.app.form is available. This zope.app.form conditional is not even "enough", as sometimes you can still have zope.app.form on your path, but zcml directives like addMenuItem and editForm used in zc.catalog.browser's configure.zcml might not have been configured.
I could imagine we change zc.catalog so that the toplevel configure.zcml never includes the browser subpackage's configure.zcml and people that need the ZMI code, need to include the zc.catalog.browser subpackage themselves. This would still leave the test dependency (which is annoying but alas), but at least make the zc.catalog easier to reuse.
I'm fine with these suggestions but I'd suggest a new additional "browser" extra, which declares the dependencies of the browser subpackage. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 10/13/10 13:16 , Michael Howitz wrote:
Am 13.10.2010 um 10:02 schrieb Jan-Wijbrand Kolman:
If I would be pedantic here I'd say there is no such thing as renaming a permission. When the old name is gone, it is gone. There's no mechanism similar to the BBB imports for the permission ids.
Not pedantic enough as there is a mechanism to rename a permission, see http://pypi.python.org/pypi/zope.dublincore/3.8.0#id3
Ah! Never to late to learn something - I didn't know that!
I could imagine we change zc.catalog so that the toplevel configure.zcml never includes the browser subpackage's configure.zcml and people that need the ZMI code, need to include the zc.catalog.browser subpackage themselves. This would still leave the test dependency (which is annoying but alas), but at least make the zc.catalog easier to reuse.
I'm fine with these suggestions but I'd suggest a new additional "browser" extra, which declares the dependencies of the browser subpackage.
Good idea. This would improve the testing situation. That would definitely help the Grok Toolkit, as it could then run the "normal" tests in the context of the toolkit, without pulling in the dependencies of the browser tests. kind regards, jw
On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
Good idea. This would improve the testing situation. That would definitely help the Grok Toolkit, as it could then run the "normal" tests in the context of the toolkit, without pulling in the dependencies of the browser tests.
Ah, no it wouldn't help there, as the testrunner would find the tests in the browser subpackage and it would try to run them regardless. Then there's no real need for a browser extra, as the browser subpackage does not really have any code (only registrations). Or maybe you meant something different? regards, jw
On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote:
On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
Good idea. This would improve the testing situation. That would definitely help the Grok Toolkit, as it could then run the "normal" tests in the context of the toolkit, without pulling in the dependencies of the browser tests.
Ah, no it wouldn't help there, as the testrunner would find the tests in the browser subpackage and it would try to run them regardless.
You could always conditionally disable them: in each test*.py file have def test_suite(): suite = unittest.TestSuite() if some condition: suite.addTest(unittest.makeSuite(...)) suite.addTest(doctest.DocTestSuite(...)) suite.addTest(doctest.DocFileSuite(...)) return suite Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
Good idea. This would improve the testing situation. That would definitely help the Grok Toolkit, as it could then run the "normal" tests in the context of the toolkit, without pulling in the dependencies of the browser tests.
Ah, no it wouldn't help there, as the testrunner would find the tests in the browser subpackage and it would try to run them regardless.
Then there's no real need for a browser extra, as the browser subpackage does not really have any code (only registrations). Or maybe you meant something different?
When someone wants to use the browser package he could use the "browser" extra to get all the packages needed for the ZCML registrations successfully load. Otherwise he has to find out himself where the ZCML directives are declared. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Michael and Marius, Thanks for the feedback and suggestions! This is what I did: On 10/13/10 15:37 , Michael Howitz wrote:
Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
Then there's no real need for a browser extra, as the browser subpackage does not really have any code (only registrations). Or maybe you meant something different?
When someone wants to use the browser package he could use the "browser" extra to get all the packages needed for the ZCML registrations successfully load. Otherwise he has to find out himself where the ZCML directives are declared.
I created two extra_requires: a browser and a test_browser. The first lists the dependencies for the browser subpackage to work. The second for the corresponding tests to run. On 10/13/10 14:42 , Marius Gedminas wrote:
On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote:
Ah, no it wouldn't help there, as the testrunner would find the tests in the browser subpackage and it would try to run them regardless. You could always conditionally disable them: in each test*.py file have
def test_suite(): suite = unittest.TestSuite() if some condition: suite.addTest(unittest.makeSuite(...)) suite.addTest(doctest.DocTestSuite(...)) suite.addTest(doctest.DocFileSuite(...)) return suite
I also made the tests.py in the browser subpackage only add tests to the test suite whenever the test_browser dependencies indeed are available. This fixes the situation where a test runner (in my case the test runner of the grok toolkit) finds these tests and would try to run them. The CHANGES.txt contains instructions on how to enable the ZMI views for your project in case you need them. I propose to release this as 1.5.0, which would be a major version release that would indicate: "Watch out, potentially backwards incompatible changes ahead!". Right? Thanks again for your feedback! kind regards, jw
Am 18.10.2010 um 11:02 schrieb Jan-Wijbrand Kolman:
Hi Michael and Marius,
Thanks for the feedback and suggestions! This is what I did:
On 10/13/10 15:37 , Michael Howitz wrote:
Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
Then there's no real need for a browser extra, as the browser subpackage does not really have any code (only registrations). Or maybe you meant something different?
When someone wants to use the browser package he could use the "browser" extra to get all the packages needed for the ZCML registrations successfully load. Otherwise he has to find out himself where the ZCML directives are declared.
I created two extra_requires: a browser and a test_browser. The first lists the dependencies for the browser subpackage to work. The second for the corresponding tests to run.
On 10/13/10 14:42 , Marius Gedminas wrote:
On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote:
Ah, no it wouldn't help there, as the testrunner would find the tests in the browser subpackage and it would try to run them regardless. You could always conditionally disable them: in each test*.py file have
def test_suite(): suite = unittest.TestSuite() if some condition: suite.addTest(unittest.makeSuite(...)) suite.addTest(doctest.DocTestSuite(...)) suite.addTest(doctest.DocFileSuite(...)) return suite
I also made the tests.py in the browser subpackage only add tests to the test suite whenever the test_browser dependencies indeed are available. This fixes the situation where a test runner (in my case the test runner of the grok toolkit) finds these tests and would try to run them.
The CHANGES.txt contains instructions on how to enable the ZMI views for your project in case you need them.
I propose to release this as 1.5.0, which would be a major version release that would indicate: "Watch out, potentially backwards incompatible changes ahead!".
Right?
+1 looks nice. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 10/18/10 21:16 PM, Michael Howitz wrote:
Am 18.10.2010 um 11:02 schrieb Jan-Wijbrand Kolman:
I propose to release this as 1.5.0, which would be a major version release that would indicate: "Watch out, potentially backwards incompatible changes ahead!".
Right?
+1 looks nice.
Done. Thanks. regards, jw
participants (4)
-
Gediminas Paulauskas -
Jan-Wijbrand Kolman -
Marius Gedminas -
Michael Howitz