I finished my migration of a first Plone addon some a week ago sucessfully and started with migration of a further addon, collective.dexteritytextindexer to Python 3 compatibility. I was able to migrate the source code of the addon itself, but run into issues with the behaviors test script. The tests ran successful on Plone 4.3 to 5.2 and Python 2.7, but failed on Plone 5.2 on Python 3.
I did pour volunteer work for LibreOffice and its antecessor for about sixteen years. I worked in different roles for the open source project during this long periode. The project consumed a lot of my spare time. But then I experienced a ‘nice’ communication experience inside the community, that showed me a lack of respect for my project work, its value and also for my person. Thus I decided to completely stop my pour volunteer work within the project three month ago. The LibreOffice extensions and templates website (extensions.libreoffice.org) lost its maintainer and project reviewer since that time.
I used my free cycles to improve my fitness. And I was able to do this way something in balance to my day by day payed office work. Seemed it was a smart decision 😉
I worked on my first migration oft a Plone addon to Python 3 during the last days. There were some instructions available on Github how to procide and I followed them. I was able to run the addon inside my local environment, but I got some issues with the continous integration test on Travis-CI, once I submitted a pull request. I had to fix the scripts inside the addon for building and testing on Travis-CI and was successful with the great support from a member of the Plone community. He merged my pull request and released a new version of the addon cioppino.twothumbs today: https://pypi.org/project/cioppino.twothumbs
I usually don’t configure a mailhost for my local development environment. Thus I use the Products.PrintingMailHost to stop Plone from sending out emails and print into the shell instead.
I read about the porting work of this product/tool to Python 3 on:
https://www.starzel.de/blog/python-3-and-more and wanted to try this version out. I added the product to my buildout script ‘local.cfg’ but without success. Buildout fetched the product and I could change its branch to ‘python3’ but it had didn’t work. Its patch wasn’t applied to the Plone mailhost.
I solved this issue by adding ‘ENABLE_PRINTING_MAILHOST True’ to the ‘environment-vars =’ entry of the ‘[instance]’ of ‘core.cfg’.
It looks as follows yet:
environment-vars = zope_i18n_compile_mo_files true ENABLE_PRINTING_MAILHOST True
The printing mailhost is working as expected yet.
I created a new clean buildout from the Plone coredev Github repository using a checkout of the 5.2 branch. I added a local.cfg file to my local repo and added some packages to this file. This packages were checked out within the next run of buildout using the new local.cfg buildout file, extending buildout.cfg.
I created the local.cfg using the pointer from this webpage:
I added a further section to the local.cfg for ‘mr.bob’. Thus my local.cfg looks like this:
[buildout] extends = buildout.cfg parts += mrbob always-checkout = true custom-eggs += collective.dexteritytextindexer bobtemplates.plone test-eggs += collective.dexteritytextindexer [test] auto-checkout += collective.dexteritytextindexer bobtemplates.plone [mrbob] recipe = zc.recipe.egg eggs = mr.bob bobtemplates.plone [sources] collective.dexteritytextindexer = git git://github.com/andreasma/collective.dexteritytextindexer bobtemplates.plone = git git://github.com/plone/bobtemplates.plone.git
I created a new branch inside the collective.dexterity local repository with ‘git checkout -b python3’ and did on this branch the steps that are described on this website:
I run sixer and python-modernize on the package and was able to get it running with Plone 5.2 on Python 3.6. I already created a new Plone site from scratch for this.
Then I created a new Plone add-on package using mr.bob and run sixer and python-modernize against the new package. Once this was finished I added the package to the local.cfg buildout script and run buildout again. I was able to start the Plone site with ‘./bin/instance fg’ without issues again. I installed the new addon within the ‘Site Setup’ page of Plone. The new addon had no real content at that time (only the necessary boilerplate / template).
This created the environment to migrate the current state of my Plone addons to the new Plone 5.2 version and Python 3. This migration is necessary because the support for Python 2, currently used by Plone, ends within a year.
It’s interesting how much spare you gain once you withdraw from a busy message environment. This helps to invest more time into more healthy acitivities (like outdoor runners training). It makes it also possible for me to concentrate more on improving my skills on Plone and Python and work on the migration of Plone addons to the next Plone main release, 5.2, running on Python 3.
And it is also interesting to notice the difference between the official speach of people about the volunteer work you have done and the real rating of that work. That helps to reclassify things and justify my direction.
I started with my work to migrate a first Plone addon to Plone 5.2 on Python 3. I did this work on the addon cioppino.twothumbs. I first applied ‘sixer’ on it and than run ‘python-modernizer’ as described on this page. But I got some errors with the imports afterwards, once I started the Plone instance with ‘fg’. This imports were implicite relative. I changed them to explicite relative or absolute. The addon is running yet in the Plone instance. But there is a remaining issue with the css-file of the addon. I pushed my changes to the new git branch ‘python3’: https://github.com/tdf/cioppino.twothumbs/commits/python3.
I created a further buildout for Plone from the Plone coredev Github repository and checked out the 5.2 branch. The buildout went fine and I could create a new Plone site.
I tried out to create a new add-on with bobtemplates and it worked with my new Plone site (on Python 3.6). I was able to install the add-on without errors. I’ll try out some further add-ons with this buildout using my own extension of the core buildout script. I’m curious, if this add-ons will work with my buildout. If they will not run on Python 3 I’ll try to upgrade them.
Es ist tragisch, dass statt der Einführung einer einfachen blauen Plakette für Diesel-Fahrzeuge, die in Bereiche mit Fahrverboten für Diesel mit zu hohen Stickoxidwerten einfahren dürfen, nun eine komplette Videoüberwachung aller in den Bereich einfahrenden Fahrzeuge eingeführt werden soll. Mal abgesehen von dem technischen Aufwand (eventuell nur für einen begrenzten Zeitraum) für diese Erfassung widerspricht sie dem Gesichtspunkt der Datensparsamkeit, der dem Datenschutz und auch der DGSVO zugrunde liegt. Es sollte immer die insoweit für die informationelle Selbstbestimmung des Bürgers am wenigsten beeinträchtigende Alternative gewählt werden, also eine einfache blaue Plakette. Die grüne Plakette hat und tut ihren Dienst schließlich auch.
The social security systems inside the European Union are not unique system. The European Union respectively the countries that signed the contract of the union decided not to build one system for the whole union but to coordinate the different social security systems of the member states to ensure one of the essential cornerstones of the union the free movement of persons (workers) inside the union.
The basic principle of social security is that a worker is insured in the country where she/he is doing the work. E.g., if a German is working in Belgium she/he is insured in the Belgium social security system. This rule would also apply if she/he has a German employer and the latter sends him to work in Belgium. Because the employer in Germany has to insure the worker also in Germany the worker has a double insurance (in Germany and Belgium).
And there comes the A1 form into the game. This form is the tool to coordinate the social security systems and help to avoid such doubled insurance. If – like in the above example – a German employer sends his employee to Belgium he had to apply the A1 form (https://europa.eu/youreurope/citizens/work/social-security-forms/index_en.htm) before the employee went to Belgium. The employee has to carry at least the A1 application with him, once he left Germany and enter Belgium (regularly he should own the A1 form in this situation).
The application for an A1 is a duty of the employer. He has to submit this application to the competent social security institution of his place of business, in the example the one in Germany.
If the authorities of the other state (in the example the Belgium authorities) came across the German employee without an A1 form (or at least the evidence of the application for an A1) they will hand out a punishment to the employer. This fine could be very expensive and is regularly not refundable.
It is current opinion among employers that an A1 form is only needed for longer foreign work periods, but that is not a correct interpretation of the European regulations. The employee needs an A1 form for every work, he was send to another country of the European Union (or a country where the regulation of the European Union are effective, e.g. Swiss or Norway). Thus the employee needs such a form too, if she/he makes a business trip only for a very short time into the other country, e.g. only for an hour or hours (https://www.krankenkassen.de/ausland/portable/a1/ , https://www.haufe.de/personal/entgelt/meldeverfahren-a1-bescheinigungen-kuenftig-maschinell_78_378230.html), e.g. visits an event, a conference for an hour or hours on behalf of his employer (regularly within his working hours, work contract).
The need of an A1 form is not narrowed to employees (and employers), it applies to self-employed people too, if they cross the border to do their work in another country of the European Union (or the countries where the coordination rules of the European union are effective).