A [test] extra?

[gforcada]

While testing the new pip version that came out today, I noticed that when it installs new packages it explains why, e.g:

Collecting WebOb>=1.2 (from WebTest>=2.0.30->zope.testbrowser->Zope>=5.5->plone.app.upgrade->Plone)

a pip install Plone pulls plone.app.upgrade, which in turn pulls Zope and then zope.testbrowser, etc ...

And that's the topic of this issue: I see that on setup.py in install_requires there is at least zope.testbrowser and zope.testing which I assume to be distributions meant only for testing.

Given that there's at least a docs and a wsgi extras, would it make sense to move at least these two distributions mentioned above to it, possibly(?) others as well? 🤔

Or is there some historical reason not to do so?

[d-maurer]

Gil Forcada Codinachs wrote at 2023-4-15 14:50 -0700:

While testing the new `pip` version that came out today, I noticed that when it installs new packages it explains why, e.g: ... And that's the topic of this issue: I see that on `setup.py` in `install_requires` there is at least `zope.testbrowser` and `zope.testing` which I assume to be distributions meant only for testing.

Part of `Zope` is the package `Testing`. It contains utilities to create test suites for Zope applications. And it uses `zope.testbrowser`. Thus, `Zope` really depends on `zope.testbrowser`. `zope.testbrowser` is not only used to test `Zope` itself. IT is part of the application support provided by Zope (more precisely, to create test suites for those application).

[mauritsvanrees]

For me it would make sense to create a test extra though. That would be for Zope 6 then. We could create an empty one in Zope 5 as preparation. Or have these dependencies duplicate for now.

[d-maurer]

Maurits van Rees wrote at 2023-4-17 02:40 -0700:

For me it would make sense to create a test extra though.

Why? `Zope` would have have the subpackage `Testing` which could only be used when `Zope` had been installed with the `test` extra. The introduction of the `test` extra would make things more complex without a significant advantage.

[mauritsvanrees]

The advantage would be to get rid of packages like zope.testbrowser and WebTest which should not be needed on a production system.

[gforcada]

This Testing subpackage might get moved outside of Zope then, thus reducing also the amount of code is being shipped with Zope.

Not sure how much tangled is Testing with the other parts of Zope, or rather how much Testing is being called from within other parts of Zope. Hopefully not so much 🤞🏾

[dataflake]

"Patches welcome"?

[mauritsvanrees]

I searched for import Testing and from Testing in all the code that Plone 6 pulls in. It is used a lot in tests, naturally. I saw only one production use:
https://github.com/zopefoundation/Zope/blob/5.8.1/src/Zope2/utilities/zconsole.py#L7

from Testing.makerequest import makerequest

Ah, and that same import is used in plone.recipe.zope2instance as well in some circumstances:
https://github.com/plone/plone.recipe.zope2instance/blob/6.12.0/src/plone/recipe/zope2instance/ctl.py#L673

makerequest.py is small and only needs ZPublisher:
https://github.com/zopefoundation/Zope/blob/5.8.1/src/Testing/makerequest.py
So maybe that could be moved to ZPublisher, with backwards compatibility import staying behind in Testing.

@dataflake wrote:

"Patches welcome"?

That seems the main question here: would a patch to split off Testing and add it in a test extra in Zope be accepted? Sounds like that is the case.

I don't know who will work on this, and when. There is a Beethoven sprint in May in Bonn, that could be a good time, but no promises. But how about the following plan?

In Zope 5:

• Copy makerequest.py to ZPublisher.
• Let Testing.makerequest import it from there, keeping it for backwards compatibility.
• Move Testing to a separate repo.
• Add Testing in Zope/setup.py both to the install_requires and a new test extra. Then add-ons or core Zope packages can continue to work without change.
• Change other core Zope packages to either use the Zope[test] extra or explicitly add Testing to their own test extra, so they are ready for the next step.

In Zope 6:

• Remove Testing from the install_requires list.

These are the affected namespaces:

App/tests
OFS/tests
Products/CMFCore
Products/CMFPlone
Products/CMFUid
Products/DCWorkflow
Products/Five
Products/GenericSetup
Products/MailHost
Products/PageTemplates
Products/PluggableAuthService
Products/PluginIndexes
Products/PythonScripts
Products/Sessions
Products/SiteAccess
Products/SiteErrorLog
Products/Transience
Products/ZCatalog
Products/ZopeVersionControl
ZPublisher/tests
Zope2/App
Zope2/utilities
five/customerize
five/intid
five/localsitemanager
plone/app/content
plone/app/z3cform
plone/app/testing
plone/app/contenttypes
plone/schemaeditor
webdav
zmi

[d-maurer]

Maurits van Rees wrote at 2023-4-19 01:35 -0700:

... These are the affected namespaces: ... large list ...

A lot of changes -- for a small benefit.

[dataflake]

Dieter is right, that is a lot of work just so loading Zope doesn't pull zope.testbrowser and its dependencies. IMHO not worth it.

[icemac]

I see a benefit from not installing test dependencies (and their dependencies) on a production system, so I support this change request even though it requires changes in many places.
As we can implement it using BBB imports and deprecation warnings there is no need to do most of the changes right now. So I am open to further steps.

[dataflake]

I'm open to this as well, but don't want to do the work. So my earlier remark, "patches welcome", still stands.

The package name "Testing" is so generic that if it were to be moved outside of Zope I'd either rename it or merge it into another package like zope.testing?

[icemac]

I'm open to this as well, but don't want to do the work.

Same here.

So my earlier remark, "patches welcome", still stands.
The package name "Testing" is so generic that if it were to be moved outside of Zope I'd either rename it or merge it into another package like zope.testing?

I think we need a new package, as Testing is too specific for Zope 5 and zope.testing should not depend on it. So the first challenge would be to find a good name. Suggestions are welcome.