Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PLIP: Port Plone to Python 3 #2368

pbauer opened this issue Mar 30, 2018 · 31 comments

PLIP: Port Plone to Python 3 #2368

pbauer opened this issue Mar 30, 2018 · 31 comments


Copy link

@pbauer pbauer commented Mar 30, 2018

Proposer: Philip Bauer

Seconder: Alexander Loechel


Support Python 3 and 2.7.

Plone 5.2 should run on Python 2.7, 3.6 and 3.7

For Plone 6 Python 3 should be the default but it should still run on 2.7.


On 2020-01-01 support for Python 2.7 ends. Migrating to Python 3 is a requirement to ensure the continued success of Plone.


Most of the dependencies of Plone (Zope, ZODB, CMFCore, GenericSetup, DCWorkflow, RestrictedPython...) already run on Python 3 or are actively being ported.

Proposal & Implementation

Keep the functionality the same but allow it to run in Python 3 as well as in Python 2.7.

To achieve compatibility with both versions use six, e.g. for changed imports.

In most cases incompatible code can be replaced by code that works in both versions.

Whenever a change is needed the code should be changed in such a way that Python 3 is the default and 2.7 is the fallback that can be removed by deleting complete lines. This should make it easier to drop support for 2.7 in the future.

Approaches to porting Plone to Python 3

There are five strategies to porting Plone to Python 3. We need to follow all of them to make it in reasonable time:

  1. Migrate packages that have no dependency to CMFPlone and test them in Python 2 and 3. For most packages from the plone-ecosystem this is already done but some are not finished yet (e.g. GenericSetup, DCWorkflow, plone.rfc822).
  2. Prepare packages for Python 3 without being able to test them in Python 3. This is already done for all packages with the help of sixer or python-modernizer. See #2217 for a list of pull-requests that did this.
  3. Start Plone on Python 3 and fix whatever breaks. I started down that path at the Alpine City Sprint in January 2018 and by now (March 30th) Plone starts up with Python 3 and you can create a instance and play around with it. Many features still do not work, most noticeable static resources and add- and edit-forms. But a running instance allows parallelizing work (remote and at sprints). We can continue this work in parallel by manually testing features and fixing issues as they appear.
  4. Port plone.testing and to Python 3 and WSGIPublisher. Work on this was started at the Alpine City Sprint in 2018 but is not finished. When this task is done we can start with approach 5:
  5. Tests in Python 3 and fix all breaking tests.

All changes must result in pull-requests that are tested with Python 2.7 and eventually in Python 3.

Python versions

Plone will continue to support Python 2.7 until a PLIP to drop support for Python 2.7 is written and implemented. Continued support for Python 2.7 beyond 2020-01-01 will ensure that everyone can upgrade choosing their own speed but are not necessarily stuck on a old version of Plone.

Plone will support Python 3.7 and 3.6. Python 3.7 will be released on 2018-06-15 and will be supported until 2023. 3.6 is supported until 2021-12-23 and 3.5 is supported until 2020-09-13.

Python 3.4 has its end of life (EOL) on 2019-03-16 and it is not worth the effort to support it for the limited time it still has. Python 3.5 EOL is 2020-09-13.

See the Python release- and support-roadmap at

ZServer, WSGI, FTP and WebDAV

There are plans to reimplement ZServer for Python 3 on top of aiohttp at the Sauna Sprint in July 2018. ZServer is not yet ported to Python 3. Since ZServer holds support for FTP and WebDAV these features will need to also be implemented there or replaced.

Currently plone.recipe.zope2instance already supports waitress and uwsgi. The WSGIPublisher in Zope will probably be the default publisher.

When running in Python 2 the old ZServer will still work but is not available in Python 3.

(see discussion below)


The ZODB is compatible with Python 3 but a DB created in Python 2.7 cannot be used in Python 3 without being modified before.
There are currently two approaches to such a migration that need to be evaluated: and

Archetypes deprecation and removal

Plone running on Python 3 will not support Archetypes because it makes no sense to maintain two frameworks and probably nobody will invest the time to migrate AT to Python 3.

The following packages should be deprecated:

  • Products.Archetypes
  • Products.ATContentTypes

As far as I can see the only code from them we need to move is GopipIndex (the index for sorting against getObjPositionInParent) from

On Python 2 Archetypes will still work but needs to be added as a dependency (maybe as a extra).


The following is half-educated guesswork:

  1. Upgrade a existing instance to Plone 5.2 while still in Python 2.7
  2. Remove addons that are not compatible with Python 3.
  3. Run upgrade-steps to prepare the switch to Python 3.
  4. Migrate the ZODB Database with the help of or
  5. Build and start Plone 5.2 with Python 3
  6. Run additional upgarde-steps in Python 3 (optional)


The real timeline depends a lot on other PLIPs and the momentum that the community can muster. I nevertheless suggest to aspire to follow a timeline since 2020-01-01 is a hard deadline that is beyond our influence. Having no stable release on Python 3 some time before that will seriously impact Plone.

  • November 2018: Final release of Zope 4
  • November 2018: First alpha-release of Plone 5.2 (by the time of the conference).
  • January 2019: Final release of Plone 5.2

This will allow people to test and migrate some addons before 2020.

I do not think that waiting for Plone 6 with this PLIP is an viable option since Plone 6 will most likely depend on the state of pastanaga/plone-react and having two hard dependencies for a mayor release is a great recipe for delays.


  • Provide a buildout that allows to build Plone with Python 3:
  • Document best-practices for porting Plone to Python 3 while keeping support for 2.7 (#2184)
  • Document building and running Plone on Python 3 (#2041)
  • Document deploying Plone with WSGI
  • Port the testing-infrastructure (plone.testing and to Python 3
  • Port packages without dependecy on CMFPlone to Python 3
  • Get Plone to run on Python 3
  • Deprecate Archetypes and remove it from tests in Python 3 (#2390)
  • Port plone.testing and
  • Setup our test-infrastructure to test all pull-requests against Python 2.7 and 3
  • Fix all tests in Python 3
  • Document upgrading Plone to 5.2 with Python 3
  • Document and test migrations for existing Projects and the ZODB
  • Provide and document replacements or alternatives for FTP and WebDAV
  • Document best-practices for porting Addons (
  • Test performance in Python 3 (#2635)
  • Upgrade the Plone Trainings to mention and eventually use Python 3 (Mastering Plone works with Python 3)



  • If we do not pull this off our world will be coming to an end.
  • The upgrade-procedure is not as easy as clicking a button and waiting for upgrade-steps to finish.
  • Migrating a existing ZODB from Python 2 to 3 still experimental, can be tricky and could lead to data-loss.
  • So far there is no solution for FTP and WebDAV support. Simply dropping support for these might turn away users that rely on that.


  • Early-adopters of Plone on Python 3 will have a much smaller ecosystem of addons that already supports Python 3. Luckily porting addons is really easy unless they use Archetypes.


  • Compatability of addons will be more confusing since they not only need to state which Plone-Versions they support but also which Python-Versions.
  • Supporting two Python versions might lead to confusion as to which Python-Version is recommended.
  • Continuing support for running Plone on Python 2.7 might lead to the expectation that the Plone community will provide security support for Python 2. We need to be explicit that people who still use Python 2.7 after 2020-01-01 will do so at their own risk.


Leads: Philip Bauer (@pbauer), ...

We need separate leads for many of the deliverables (e.g. plone.testing, ZODB-Upgrades, FTP/WebDAV etc...). Please consider championing one of the deliverables and add your name here.

Current Status

As of now (March 30th) Plone already starts up with Python 3 and you can create a instance and play around with it. Many features still do not work, most noticeable static resources. But this foundations allows parallelizing work.

How can I help?

@pbauer pbauer added this to the Plone 5.2 milestone Mar 30, 2018
Copy link

@datakurre datakurre commented Mar 30, 2018

@pbauer Just FYI that we begin reimplementing ZServer for Python 3 on top of aiohttp (unless we find better base) at Sauna Sprint in July 2018. We are serious, because we rely heavily on current asyncore base of ZServer and async patches for wsgi don’t look interesting when asyncio could be an option.

Copy link

@fulv fulv commented Mar 30, 2018

Copy link
Member Author

@pbauer pbauer commented Mar 30, 2018

@datakurre Great to hear, I totally forgot about that. I updated the info in the PLIP. Is there already a ticket to track the progress and the discussion that I can link to?

Copy link
Member Author

@pbauer pbauer commented Mar 30, 2018

Also: I'm looking for a partner in crime for this. See

Copy link

@jaroel jaroel commented Mar 30, 2018

Awesome, the p2.7 support is a BIG plus IMHO!

Is there a specific reason to support 3.5, or does that just happen to come OOTB with six?
AFAICT 3.6+ should be good enough, maybe 3.7+ even; we probably won't finish this before 3.7 is stable.

Copy link

@datakurre datakurre commented Mar 30, 2018

@pbauer Not yet. We know better only in the summer once we have POC’d it.

Copy link
Member Author

@pbauer pbauer commented Mar 30, 2018

@jaroel Yes, there is nothing to be gained from supporting (and testing) 3.5. We should support the last two versions only. 3.6 is what I'm using now and I will switch to 3.7 when it is released.

@pbauer pbauer added this to In Progress in Python 3 Apr 1, 2018
Copy link

@gforcada gforcada commented Apr 1, 2018

IMHO as we are doing the porting now I would stick with 3.6 for now, there's no much gain to keep our CI matrix more complex for the sake of it... As we have a steady working version on 3.6, we can add the +3.6 python versions on the CI matrix.

I can try to work on the CI bits... one thing that I would like to work on would be on catching regressions, with all the six porting for example, if new pull requests are not tested for regressions, we can endlessly play hide and seek.

Copy link
Member Author

@pbauer pbauer commented Apr 4, 2018

@gforcada can you please create a PLIP-job for this in jenkins? The job should at first only follow the steps in #2041 (comment). Running tests is not yet possible. That would help us catch errors from merged or broken branches.
As a bonus it would be nice to have the job also start the instance and catch the output from the terminal but I don't know how to stop it again after the startup.

Copy link

@gforcada gforcada commented Apr 11, 2018

@pbauer there you go: it is already complaining about Products.statusmessages branch not being found 😄

Copy link

@ale-rt ale-rt commented Apr 12, 2018

It should be fixed by this PR plone/buildout.coredev#452: the Products.statusmessages branch has been merged to master

@pbauer pbauer mentioned this issue Apr 23, 2018
3 of 3 tasks complete
Copy link
Member Author

@pbauer pbauer commented May 1, 2018

@gforcada thanks for the jenkins-job. The buildout works fine now. But the test itself makes no sense: ./bin/instance run

The instance-script cannot work since it pulls in ZServer and other stuff that does not work in Python 3. Same goes for the test-script since AT is a test-dependency for most packages.
Can we have something that starts up Plone like this and stops after 10 seconds:

timeout 10 ./bin/ etc/waitress.ini

It should pass if the last line of output is something like Serving on

For me the output looks like this:

$ timeout 10 ./bin/ etc/waitress.ini
Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_historyCopy'
Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_beforeHistoryCopy'
Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_afterHistoryCopy'
Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_historyCopy'
Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_beforeHistoryCopy'
Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_afterHistoryCopy'
Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPstat'
Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPlist'
Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPstat'
Class Products.CMFCore.PortalContent.PortalContent has a security declaration for nonexistent method 'manage_FTPlist'
WARNING:Init:Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_historyCopy'
WARNING:Init:Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_beforeHistoryCopy'
WARNING:Init:Class Products.PythonScripts.PythonScript.PythonScript has a security declaration for nonexistent method 'manage_afterHistoryCopy'
Serving on

Once the testlayers in are ported to python3 we can start proper testing for real.

pbauer added a commit to plone/ that referenced this issue May 5, 2018
@jensens jensens added this to New (drafts) in PLIPs May 8, 2018
Copy link

@ebrehault ebrehault commented May 8, 2018

@pbauer the @plone/framework-team has approved this PLIP.

@jensens jensens moved this from New (drafts) to Submitted (info complete) in PLIPs May 9, 2018
Copy link
Member Author

@pbauer pbauer commented May 13, 2018

Here comes a quick status-update before the sprint in Halle next week: We've made great progress and most features of Plone work in python 3.

A couple of core-features still need some love (e.g. login in Plone, adding files and images, schema-editor etc.). I'm optimistic that we can make good progress on many of these during the sprint.

We even started testing in jenkins ( For now we only run the tests of but for those we already get: Total: 280 tests, 18 failures, 4 errors and 119 skipped in 1 minutes 4.915 seconds. The skipped tests are the migration-tests, they only run when Archetypes is installed.

There is still a lot of work to be done but thanks to everyone involved the progress is encouraging.

@jensens jensens moved this from Submitted (info complete) to In Process (approved) in PLIPs May 14, 2018
Copy link

@janjaapdriessen janjaapdriessen commented May 18, 2018

We have migrated our 120M Python2 objects Relstorage database to Python3 using mdtools.relstorage. We've made the repository public for other ZODB users to use as inspiration:

Copy link
Member Author

@pbauer pbauer commented May 23, 2018

At the sprint in Halle we made very good progress. Plone is running nicely on Python 3 but now we have to fix over 500 failing tests. I wrote a blogpost at with some more details.

Copy link
Member Author

@pbauer pbauer commented Jul 14, 2018

Status report

Here is report of the current state of Plone on Python 3. It covers what was done in the last couple of weeks since the Buschenschank Sprint ( and lists some things that still need to be done.

&tldr;~Things are looking good but we still need to do a lot of work to migrate some remaining packages, fix all tests and provide a solid database migration-story. If you can, please come to the sprint in Halle in October (!

On June 25-27 there was a Mini-Sprint in Munich where Jens Klein, David Glick and Philip Bauer worked mainly on fixing the tests with Python 3.

For that sprint we started out with 7459 Tests with 138 failures and 40 errors and ended with 8147 Tests with 113 failures and 56 errors.

We worked on a bunch of tasks:

Weird tests

There were a lot of tests failing where the issue was not obvious. We fixed all of the the following:

  • -s -t test_widget_base_notimplemented
  • -s plone.dexterity -t test_container_manage_delObjects
  • -s Products.CMFPlone -t safe_unicode
  • -s Products.ZopeVersionControl
  • -s Products.CMFEditions -t test06_retrieveWithNoMoreExistentObject
  • -s Products.CMFEditions -t test16_delete_history_on_content_deletion
  • -s Products.CMFPlone -t test_site_logo_is_stored_in_registry: "Object is of wrong type" in fieldErrorBox. Check def validate()...
  • -s plone.protect -t test_change_password_on_root_does_not_throw_other_csrf_protection
  • -s plone.formwidget.namedfile -t widget.rst

Fail on Jenkins only

Some tests still fail when running in Jenkins but pass when running locally. Weird.

  • -s z3c.form -t datamanager.txt
  • -s five.customerize


After the sprint Jens tackled the package plone.rfc822 that deals with serialization (also of schemata) and fixed all remaining issues (I think...). Here are a couple of tests that failed before:

  • -s plone.rfc822
  • -s plone.namedfile -t marshaler.rst
  • -s -t TestMailAction
  • -s Products.CMFPlone -t test_request_reset_password


David ported to Python 3. For this we had to re-add XMLRPC support to Zope (it was removed for Zope 4) and ported it to Python 3. We also had to work around a pretty tough bug in Python itself. See plone/ for details.

Locally the robot-test are now running and some are passing. We still need to setup Jenkins properly to run them there and then fix the failing robot-tests.

Migrate tests away from PloneTestCase and PloneTestCaseFixture

We migrated a ton of tests from PloneTestCase to I also changed PloneTestCase to use Dexterity instead of Archetypes to make porting some tests easier that rely heavily on self.publish (see plone/ A lot of additional tests are now running because of this change but I also found a couple of issues where dexterity is failing (e.g. testClearFindAndRebuildKeepsModificationDate).

Add PY23DoctestChecker

To run doctests in Python 3 and Python 2 we use a pattern PY23DoctestChecker that can modify the expected and received values in doctests for Python 2 (for Python 3 they should pass without any tricks). See for a simple example.

Strategy to deal with random ordering

In Python 3 (as actually in Py2) keys in a dict do not have a deterministic order. There are many tests which implicitly test the order of dicts. They had to be fixed to work in Py2 and Py3).

We applied a couple of different patterns for different tests. The best is to simply sort the keys.

Where are some of the test that used to fail:

  • -s Products.DCWorkflow -t test_exportimport
  • -s -t test_formvariables_sequences
  • -s -t testExport

Cannot adapt lists

A issue with __slice__ prevented lists of brains from being adaptable to IContentListing. See #2429

Fix issues in GenericSetup

David fixed some more issues in the import/export code of GenericSetup. The main issue there was (as usual) serialization of lists of bytes and text.

Issue with IObjectInitializedEvent

When creating Dexterity-content with invokeFactory there is a issue when a new item is moved before it's completely added. Using createContentInContainer instead fixes this. See plone/

Open tasks

Plone runs fine with the current configuration ( But there are a lot of open tasks that need to be done before we can make a release.

Packages that need to be migrated

plone.outputfilters is being worked on by @MrTango @petschki et al (see plone/plone.outputfilters#27 plone/plone.outputfilters#31).

Products.PortalTransforms still has a lot of failing tests and needs someone to take care of those. and plone.restapi. Both packages were merged into Plone 5.2 but they are not yet compatible with Python 3. I started working on this in plone/ and plone/plone.restapi#542. See #2474.

Fix all tests

We are currently at 9408 tests with 170 failures and 331 errors. The added tests and failures are mostly because I changed PloneTestCase to use Dexterity and also included and plone.restapi in the Python 3 build.

Merge all open pull-requests

We currently have 88 open pull-requests that need to be reviewed and merged. They also need change notes and updated trove classifiers to specify support for python3:

(updated by @jensens at 2018-09-27)


  1. collective/Products.DateRecurringIndex#4
  2. plone/borg.localrole#9
  3. plone/plone.api#402
  4. plone/
  5. plone/
  6. plone/
  7. plone/
  8. plone/
  9. plone/
  10. plone/
  11. plone/
  12. plone/
  13. plone/
  14. plone/
  15. plone/
  16. plone/
  17. plone/
  18. plone/
  19. plone/
  20. plone/
  21. plone/
  22. plone/
  23. plone/
  24. plone/
  25. plone/
  26. plone/
  27. plone/plone.autoform#34
  28. plone/plone.batching#20
  29. plone/plone.browserlayer#8
  30. plone/plone.cachepurging#13
  31. plone/plone.caching#5
  32. plone/plone.contentrules#8
  33. plone/plone.dexterity#84
  34. plone/plone.folder#9
  35. plone/plone.i18n#23
  36. plone/plone.indexer#5
  37. plone/plone.locking#17
  38. plone/plone.portlet.static#16
  39. plone/plone.recipe.alltests#5
  40. plone/plone.resource#25
  41. plone/plone.resourceeditor#21
  42. plone/plone.schemaeditor#60
  43. plone/plone.session#13
  44. plone/plone.stringinterp#12
  45. plone/plone.subrequest#19
  46. plone/plone.supermodel#21
  47. plone/Products.CMFDiffTool#33
  48. plone/Products.CMFDynamicViewFTI#15
  49. plone/Products.CMFFormController#15
  50. plone/Products.CMFPlacefulWorkflow#23
  51. plone/Products.CMFQuickInstallerTool#20
  52. plone/Products.MimetypesRegistry#15
  53. plone/Products.PlonePAS#34
  54. zopefoundation/five.customerize#6
  55. zopefoundation/plone.z3cform#16
  56. zopefoundation/Products.CMFUid#5
  57. zopefoundation/Products.GenericSetup#51
  58. zopefoundation/Products.PluginRegistry#9
  59. zopefoundation/Products.ZopeVersionControl#1
  60. zopefoundation/z3c.formwidget.query#7
  61. zopefoundation/zope.schema#38


We need to start testing the migration-script zodbupdate with Plone and need to add and write the required zodbupdate_decode_dict for the packages in Plone that need it. For details see This is likely the biggest and most important task for the sprint in Halle.

Document Support for Windows

So far no one tested Plone with Python 3 on Windows.


We need to add the necessary scripts to the WSGI start script:

  • run (for running scripts)
  • debug
  • adduser

Improve Jenkins setup

The Jenkins setup for the PLIP job is basically OK but we soon need to start testing all pull-requests and changes in Python 2 and Python 3. For this we need some serious Tox know how.

Migrate mtest to python 3

@Rotonen did a lot of work on test parallelization with serious speed-improvements (see As soon as we test everything with Py2 and Py3 tests take even longer. We are looking forward for the tests speedup be in use.

Adapt Plone's ZMI pages

There is a lot of work being done to port the ZMI to Bootstrap (see zopefoundation/Zope#249). We will have to make a list all ZMI templates that Plone adds and test/fix them the new ZMI theme.

Port development plugins

The most important developer tools are probably plone.reload, Products.PDBDebugMode, and Products.PrintingMailHost. These packages need to be ported.

Port other plugins

We would love to see that some frequently used plugins are already compatible with Python 3 when when the first alpha of 5.2 is released.
Two that come to mind are and Mosaic, where mosaic is probably much more work since it comes with a whole bunch of dependencies.

Test against Python 3.7

Python 3.7 is out. We need to update the jenkins-jobs to test against it. One of the changes that might be relevant is that dicts preserve the order of items by insertion.

Deal with Deprecation- and ResourceWarnings

Running Plone on Python 3 yields many deprecation warnings. We should fix these. Also there are a lot of ResourceWarnings for unclosed files, we want to get rid of these by using with open(x) as fd: ...

Final words

Please pitch in to bring Plone to Python 3:

Copy link
Member Author

@pbauer pbauer commented Aug 7, 2018

There is now a demo-site for this PLIP:

Copy link

@jensens jensens commented Aug 17, 2018

FYI: I changed the above "Merge all open pull-requests" into a check list style. I am atm about to check the packages.

Copy link

@jensens jensens commented Aug 17, 2018

Checked all, please keep up to date

Copy link
Member Author

@pbauer pbauer commented Sep 19, 2018

The Saltlabs-Sprint in Halle ( is approaching. More than 30 people are coming to the sprint (!!!) and I hope we will get a lot done. In preparation for the sprint there is some work under way:

Merge branches: @jensens, @thet and I are currently trying to merge as many python3-branches as possible. We're currently down to 44 unmerged braches. Many of the remaining branches work fine in python 3 but depend on changes in other packages (mosty, plone.testing, Products.CMFPlone or plone.rfc822), so they are not easily merged.

Fix failing tests: We currently have 216 failing tests in Python 3, most of those are in CMFPlone (because I changed PloneTestCase to use Dexterity) and in plone.restapi.

With I created a jenkins-job that runs the branches of this PLIP in Python 2. That should make it easier to find issues that need to be fixed before merging.

I would have loved to have a alpha-release of 5.2 out before the sprint but fixing all remaining tests and merging all remaining branches seems more and more unlikely (even I have to sleep sometimes and need to earn some money...).

But: Things are looking good:

  • is working most of the time (unless someone merges a branch without updating the py3-config)
  • There are promising first result from migrating Plone Databases to Python 3
  • @gforcada will add some additional jenkins nodes so that jenkins will not be the bottleneck

If you want to help:

  • review, test and merge some branches
  • fix some failing tests
  • come to the sprint

The tasks for the sprint are basically still the same as mentioned above. We'll publish a more detailed list next week.

Copy link

@gforcada gforcada commented Sep 19, 2018

@pbauer regarding more servers, I already asked @polyester to get a server (someone at the board should have the hetzner account, I also got an account there, but with no billing permissions 🤑 )

Copy link

@gforcada gforcada commented Sep 19, 2018

@pbauer as I saw some commits from you updating trove classifiers, I thought about updating 162 out of 290 packages ported

Copy link

@jensens jensens commented Sep 20, 2018

I updated the above list of open PRs and we're down to 28.

Copy link

@jensens jensens commented Sep 27, 2018

We are at 21 PR left - 61 done. Also, there were 10 AT BBB related PRs merged (not listed here).

Copy link

@jensens jensens commented Sep 27, 2018

State of tests on Python 3: 57 failures.
On Python 2.7 way more, mainly (but not only) because of exception and string outputs in doctests. Should be easy to fix most of them.

Copy link

@ale-rt ale-rt commented Sep 27, 2018

I switched the Zope branch to plone-py3 which contains the current Zope master plus the two patches:

@jensens jensens mentioned this issue Sep 27, 2018
139 of 150 tasks complete
Copy link

@thet thet commented Sep 29, 2018

Regarding WebDAV and WSGI - there is a WSGI middleware for WebDAV (which also includes a standalone WebDAV server):

This project looks quite promising:

  • It has a good software architecture - everything is implemented against interface specifications.
  • It comes with default DAVProvider, PropertyManager and LockManager implementations and allows for providing more specific ones.
  • It's tested against a lot of WebDAV clients: Windows File Explorer and drive mapping, MS Office, Ubuntu, Mac OS X, …

This could help us a lot providing WebDAV on WSGI for Plone/Zope.

Copy link

@davisagli davisagli commented Sep 29, 2018

There are some test failures in CMFCore due to Plone monkey patches that change the behavior that CMFCore tests for (at least patches/dateIndexPatch and patches/speed). Ideally each patch should come with a function to apply it and a function to unapply it and we could apply them as part of the Plone test fixture and during Zope startup instead of at import time. But that's probably quite some work so the practical thing to do for now is to trust that CMFCore is fully tested prior to release and stop running its tests as part of Plone's test suite.

Copy link
Member Author

@pbauer pbauer commented Oct 11, 2018

A super-short update:

  • We have 5 remaining failing robot-tests on the job, that is running the whole python3-branches plus Archetypes in Python 2.
  • And the py3 job has also 5 remaining faiing robot tests.
  • Zope 4.0b6 is released. Updating our versions leads to some more issues that need to be fixed (#2590)
  • Once 4.0b6 is used and both jobs use are green we need to merge a lot of branches at the same time.
  • The sprint in Halle was a huge success and we made a lot of progress. A report will be published soon (I was down with a nasty cold until yesterday)
@pbauer pbauer moved this from In Process (approved) to Merged in PLIPs Feb 23, 2019
Copy link
Member Author

@pbauer pbauer commented Feb 23, 2019

I declare this done. There are follow-up tasks but the PLIP is merged and Plone 5.2b1 released.

@pbauer pbauer closed this Feb 23, 2019
Python 3 automation moved this from In Progress to Done Feb 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Python 3
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.