Re: [Zope3-dev] Known-good-sets problem
On Oct 5, 2007, at 10:45 PM, Benji York wrote: Stephan Richter wrote: 2. How many packages should be controlled in this index? I think we should definitely add packages from z3c and the zc namespace. What is the motivation to include non-controlled packages? I suppose it is to let people use those packages with (in this case) Zope 3.4. Yes What if someone wants Zope 3.4 and Twisted version X and Plone version Y (just making those up). That's why the KGS index is a PyPI mirror of all uncontrolled packages. Perhaps we need a way to refer to several KGS when constructing an application. Or is one KGS supposed to define a universe of packages known to work together. If so, I would think there would be no place for non-controlled packages. The semantics I think we want are kind of tricky. A KGS index needs to be authoritative for the projects it controls. If we looked in multiple KGSs, there would need to be semantics for deciding which was authoritative. setuptools lets you define a single index and multiple find-link servers. The highest version found on any server is authoritative. I think supporting multiple KGSs with the right semantics would be useful, but there isn't a way to do it in setuptools. We can achieve the same effect on the server. For example, with this software, you could chain several KGSs together. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Known-good-sets problem
On Friday 05 October 2007 14:49, Jim Fulton wrote: I discussed this a bit this afternoon with Stephan and we came up with an idea that we think might help. Stephan is going to try to prototype it. I'll try to explain it Hi everyone, the first version of the tools required to develop KGS's is now done. I simply added them to the ``zc.mirrorcheeseshopslashsimple``. That said, here is what we have: 1. There is a new index located at http://download.zope.org/zope3.4. 2. This index contains all PyPI packages. 3. There is a file called controlled-packages.cfg that has a list of projects for which we define a set of versions that are known stable within this index. The projects' pages are rewritten to only link to the stable versions. 4. There is also a buildout.cfg that is generated from the controlled packages config file. You can download it and use it to test the complete set of packages. (There are currently test failures!) The good part about it is that the index works right now giving application developers some stability. However, there are still some issues: 1. Not all zope.* and zope.app* packages are yet listed. An example is zope.viewlet. 2. How many packages should be controlled in this index? I think we should definitely add packages from z3c and the zc namespace. 3. The workflow of maintaining the KGS is somewhat unclear. Here is a workflow that works right now: (a) Install zc.mirrorcheeseshopslashsimple tools. (b) Download controlled-packages.cfg from the set you want to modify or test. (c) Use the generate-buildout script to create a buildout.cfg file. (d) Without using the KGS index (so you can pickup new versions), run buildout, so that the test script is created. (e-I) Change controlled-packages.cfg to include a new version of a package and go back to (c). (e-II) Alternatively, if you want to create a new release of a package to fix issues in the KGS, you can list the package in buildout.cfg as a develop egg and make a new version entry in controlled-packages.cfg when you have released a new version. (f) Once you are done, upload controlled-packages.cfg again. Note that this file is not under version control, so be careful to not overwrite someones work. This is probably a good reason to only have one release manager per KGS. Overall I am very pleased with that approach since it addresses our current instability problems. It also resembles QA methods used by the Linux distribution creators. BTW, I shamelessly copied the initial list of stable versions from grok. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Known-good-sets problem
Stephan Richter wrote: 2. How many packages should be controlled in this index? I think we should definitely add packages from z3c and the zc namespace. What is the motivation to include non-controlled packages? I suppose it is to let people use those packages with (in this case) Zope 3.4. What if someone wants Zope 3.4 and Twisted version X and Plone version Y (just making those up). Perhaps we need a way to refer to several KGS when constructing an application. Or is one KGS supposed to define a universe of packages known to work together. If so, I would think there would be no place for non-controlled packages. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Known-good-sets problem
On Friday 05 October 2007 22:45, Benji York wrote: Stephan Richter wrote: 2. How many packages should be controlled in this index? I think we should definitely add packages from z3c and the zc namespace. What is the motivation to include non-controlled packages? Jim mentioned that setuptools only supports one index. :-( If that's not true, then I would be glad to try a more constrained approach. I suppose it is to let people use those packages with (in this case) Zope 3.4. What if someone wants Zope 3.4 and Twisted version X and Plone version Y (just making those up). Perhaps we need a way to refer to several KGS when constructing an application. If this would be possible, then great! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
