Plone 5.2rc1 has been soft-released. Please give it a try and let me know if there are any critical issues. http://dist.plone.org/release/5.2rc1-pending/versions.cfg
For those who haven't run across soft-releases before, this is the last step before the final release. Because things haven't been finalized yet, some packages may change between now and the release. It is not recommended to use soft-releases in production.
@vincentfretin Could we have a new release of plone.app.locales for this?
I'm running into errors trying to build buildout.coredev on Python 3. It seems to be pulling in the Archetypes pins when building the [test] section. Has anyone else run across this?
Nope and as far as I can see jenkins is also able to properly run the coredev buildout.
Did you try rebuilding your bin/buildout executable (try with ./bin/pip install -IUr requirements.txt, it will force bin/buildout to be rewritten).
Sometimes it happens that bin/buildout is rewritten by buildout itself and will contain some spurious path that cause weird failures.
Switching between python versions in one buildout resulted in some weird problems (I do not remember the details). I then created https://github.com/collective/coredev52multipy to have one sources tree and one buildout.coredev but two separate buildouts and never ran into problems.
It's not specifically a version issue. When I'm building the releases, I use a cfg file that ignores all of the checkouts and dumps all of the dist files in a separate directory. For some reason, under Python 3, that's trying to pull in plone.app.collections and since that's only pinned for 2.7, buildout throws an error.
Ah. I looks like plone.restapi is the issue. If I remove the checkout, I get the failure. See https://jenkins.plone.org/job/plone-5.2-python-3.7/582/console
There's nothing new in that package since the 1.7.0 release, so I'm not sure what the difference is. @tisto any idea what may be happening? We may just need a new release.
I currently don't see how this could be related with plone.restapi. I see the p.a.collection issue but plone.restapi has no dependency on p.a.collection. If you have another pointer I am more than happy to look into this. We can also just downgrade to plone.restapi 3.6.0.
I just build buildout.coredev 5.2 with the following Makefile command:
I did not encounter any problems.
I can reproduce the issue in coredev. In python 3 no AT-dependencies are pulled for [test] when I have plone.restapi as a checkout (like it is right now). When I remove plone.restapi from checkouts with auto-checkout -= plone.restapi I get all AT-dependencies.
Here is the requires.txt of plone.restapi-3.7.0-py3.7.egg:
PyJWT
plone.behavior>=1.1
plone.rest>=1.0a6
plone.schema>=1.2.0
python-dateutil
pytz
setuptools
[test]
Products.ATContentTypes
Products.Archetypes
Products.contentmigration
archetypes.schemaextender
collective.MockMailHost
freezegun
mock
plone.api
plone.app.blob
plone.app.collection
plone.app.contenttypes
plone.app.robotframework
plone.app.testing[robot]>=4.2.2
plone.tiles
requests
That's wrong and must have happened during the release. Maybe you released using python 2?
It is probably better to use the following pattern in setup.py:
TEST_REQUIRES = [
'collective.MockMailHost',
'plone.app.contenttypes',
'plone.app.robotframework',
'plone.app.testing [robot] >= 4.2.2', # ROBOT_TEST_LEVEL added
'plone.api',
'requests',
'freezegun',
'plone.tiles',
'mock',
'archetypes.schemaextender ; python_version<"3"',
'Products.Archetypes ; python_version<"3"',
'Products.contentmigration ; python_version<"3"',
'Products.ATContentTypes ; python_version<"3"',
'plone.app.blob ; python_version<"3"',
'plone.app.collection ; python_version<"3"',
]
I can reproduce that as well. Somehow, the egg that gets built has a wrong sys.version_info and then when running setup.py it adds all AT dependencies:
Trying to pin different versions of plone.restapi give the same error for me:
The previous release, 3.5.1, is the first one that works for me on python 3.7 and without pulling plone.app.collection. 
(well, I guess) 
@mauritsvanrees added this commit after releasing 3.5.1:
But a universal wheel for plone.restapi is not possible as on setup.py there is a check to see which python version is being used to install it.
Since, I guess, @tisto is making the releases on python 2, you get a wheel built supposedly for both py2 and py3 but that in fact is only py2 compatible, as it pulls all the AT dependencies.
This pull request should fix the problem, I hope, @tisto can you merge that and make a new release, so that we can test it? 
Ah, you are right. My bad. When setting up to release universal eggs, I was only checking for packages with C code, as those cannot be universal AFAIK. But when the requirements are different between Python 2 and 3, it cannot be a universal wheel either.
A quick grep on setup.py files with a complete checkout (i.e. change checkouts.cfg to have auto-checkout = *) shows only 3 setup.py files that have a sys.version_info check: plone.restapi, ZODB3 and plone.app.robotframework.
I'm removing the universal wheel on p.a.robotframework right now 
Does this look ok?
With universal wheels explicitly disabled like this:
[bdist_wheel]
universal = 0
the side effect would be that zest.releaser no longer creates wheels at all, only the standard source release that it always creates. To counter this, we would need another setting in setup.cfg:
[zest.releaser]
create-wheel = yes
I could change zest.releaser to create a wheel even when universal is false: when there is a bdist_wheel setting, it seems logical that the developer wants a wheel. Relevant code is here.
Edit: zest.releaser issue created: https://github.com/zestsoftware/zest.releaser/issues/315.
Would my proposed change fix the issue?
TEST_REQUIRES = [
'collective.foo',
'some.oldpackage ; python_version<"3"',
]
http://dist.plone.org/release/5.2rc1-pending/versions.cfg has the exact same versions as 5.2b1. Also no file in the folder is newer than 19-Feb-2019.