RFC: Make maintenance of Zope eggs versions by pulling them from upstream.
I don't see any reason why we don't use upstream zope *versions.cfg files. This just duplicates work and makes maintenance tedious especially now that we have zope2, zope4py2 and zope4py3. Also: * Remove pinned versions on eggs with newer version or already defined in Zope versions.cfg files. * Make sure that pinned versions in stack/slapos.cfg do not override Zope versions (for example ZConfig versions set in stack/slapos.cfg was creating a version conflict while installing another egg).
[buildout] | ||
extends = | ||
# Exact version of Zope | ||
ztk-versions.cfg | ||
zope-versions.cfg | ||
buildout.hash.cfg | ||
# This has to be before Zope versions.cfg otherwise eggs such as ZConfig have | ||
# their versions overridden when slapos.cfg is extends by some component... | ||
../../stack/slapos.cfg | ||
https://raw.githubusercontent.com/zopefoundation/Zope/4.5.3/versions.cfg | ||
|
||
../../component/fonts/buildout.cfg | ||
../../component/git/buildout.cfg | ||
../../component/ghostscript/buildout.cfg | ||
... | ... | @@ -676,9 +677,7 @@ Zope = 4.5.3+SlapOSPatched002 |
pylint = 1.4.4 | ||
# use newer version than specified in ZTK | ||
PasteDeploy = 1.5.2 | ||
argparse = 1.4.0 | ||
zope.dottedname = 4.1.0 | ||
# modified version that works fine for buildout installation | ||
SOAPpy = 0.12.0nxd001 | ||
... | ... | @@ -719,7 +718,6 @@ WSGIUtils = 0.7 |
astroid = 1.3.8 | ||
erp5diff = 0.8.1.7 | ||
five.formlib = 1.0.4 | ||
five.localsitemanager = 2.0.5 | ||
google-api-python-client = 1.6.1 | ||
httplib2 = 0.10.3 | ||
huBarcode = 1.0.0 | ||
... | ... | @@ -761,8 +759,6 @@ zbarlight = 2.3 |
cloudpickle = 0.5.3 | ||
dask = 0.18.1 | ||
toolz = 0.9.0 | ||
zope.globalrequest = 1.5 | ||
waitress = 1.4.4 | ||
xlrd = 1.1.0 | ||
# Re-add for as it is required to be there for uninstallation | ||
... | ... | @@ -791,20 +787,12 @@ jedi = 0.15.1 |
parso = 0.5.1 | ||
yapf = 0.28.0 | ||
z3c.etestbrowser = 3.0.1 | ||
zope.testbrowser = 5.5.1 | ||
WSGIProxy2 = 0.4.6 | ||
WebTest = 2.0.33 | ||
beautifulsoup4 = 4.8.2 | ||
WebOb = 1.8.5 | ||
soupsieve = 1.9.5 | ||
eggtestinfo = 0.3 | ||
oic = 0.15.1 | ||
Beaker = 1.11.0 | ||
Mako = 1.1.4 | ||
pyjwkest = 1.4.2 | ||
alabaster = 0.7.12 | ||
future = 0.18.2 | ||
pycryptodomex = 3.10.1 | ||
strict-rfc3339 = 0.7 | ||
... | ... | @@ -814,8 +802,6 @@ jsonpointer = 2.2 |
# WIP Zope 4 ⚠ | ||
zope.interface = 5.2.0 | ||
ZConfig = 3.5.0 | ||
Products.CMFCore = 2.4.0 | ||
Products.StandardCacheManagers = 4.1.0 | ||
Products.ZSQLMethods = 3.14 | ||
... | ... |
-
Owner
We use to extends from github directly and we stopped in 8f222b41 (without explanation on commit message, but maybe @kazuhiko remembers ?).
By having the profiles fetched from an external source, there's a risk that one day they are not available or that they became different. I don't think networkcache applies for buildout extends and buildout extends are not verified (there's no md5sum).
By having the profiles copied in the repository, it's a little bit easier to look at the history (that point is not really important)
My preference would be to continue copying these profiles in slapos repository. If it helps, maybe we can use different filenames ( something like
Zope-4.5.3-versions.cfg
)BTW, this seem to break the build because we use a different version of zc.buildout
-
Developer
Thanks for the review ! I don't have a strong preference between an URL or a copy, except that it was not obvious to me that this was a copy from Zope buildout and I started to do modifications... So let's wait for @kazuhiko to reply then (@kazuhiko: it would have been nice to write an useful commit message BTW).
-
Owner
The reason why I stopped direct extend in 8f222b41 is simply because versions.cfg was no longer included in repository in 2.13.23 or later in 2.13 branch, by https://github.com/zopefoundation/Zope/commit/56b6790d1fd3a6e0105925adcc7cca29e9ab21cf
-
Owner
For reference: @arnau and I discussed a bit and there were not clearly a "best way" of handling zope versions.
Using zope versions like ( https://raw.githubusercontent.com/zopefoundation/Zope/4.5.3/versions.cfg ) is good because we use the "canonical source of information", so it's easy to look for new version. One problem is that we don't use exactly these versions.
Sometimes slapos.cfg uses a different version (
zc.buildout
of course, but alsoZConfig = 2.9.3
orzope.interface = 5.2.0
) sometimes ERP5 uses a different version from Zope: for security reasons like 571e78f2 or because we need to patch, like with Acquisition.We could use versions from github and have explicit overrides in
stack/erp5/buildout.cfg
, but there are two questions:- shall we use https://raw.githubusercontent.com/zopefoundation/Zope/4.5.3/versions.cfg or https://raw.githubusercontent.com/zopefoundation/Zope/4.5.3/versions-prod.cfg ?
- what shall be the order of extends ( or maybe why slapos.cfg needs ZConfig ? )
I hope I summarized correctly, I wanted to update also because my first comment sounds like I'm against this, but I'm not against.
-
mentioned in merge request !1122 (merged)
-
Owner
In a7e370de we updated Zope, I have used some curl commands to download zope profiles https://lab.nexedi.com/nexedi/slapos/blob/a7e370de393797dbb1f373622acfacdf51b36ed1/stack/erp5/buildout.cfg#L4-6
# versions pins from zope, vendored with # curl https://zopefoundation.github.io/Zope/releases/4.8.2/versions.cfg | sed -e s/versions-prod.cfg/zope-versions.cfg/g > ztk-versions.cfg # curl https://zopefoundation.github.io/Zope/releases/4.8.2/versions-prod.cfg > zope-versions.cfg
there are still many open questions, but I have noted there the procedure used
-
mentioned in merge request !1332 (merged)