[Zope3-Users] Re: [Zope-dev] KGS Site Updated
On Nov 19, 2007, at 2:17 AM, Stephan Richter wrote: On Sunday 18 November 2007, Chris McDonough wrote: I disagree. This is not what this means to me. I think a KGS can receive bug fix releases, which the Zope 3.4 KGS does. However, no new feature releases are allowed. In the Linux world, these purposes are served by separate indexes (e.g. Debian security releases are in their own index). There's no problem with what you're saying, it's just not a source for repeatable installations, which is something that's required for many builds. Yes, I agree. I accommodated those needs by having versioned links.html, versions.cfg, controlled-packages.cfg, and now minimal/ files and directories. Those will *never* change once released. (Of course there will be versions like 3.4.1dev that change until 3.4.1 is released, simply so that I do not have to version every single little change to the KGS while testing. But maybe that is even desirable at some point. We will see.) Sorry, I don't think I understand the last sentence there but I get the sense from the rest of your message that the minimal index will not change once released, and new versions of it will be made for each release (however those are defined in a post-big-release world) and that will be beneficial for lots of people. Right. Note that versions-*.cfg and links-*cfg are frozen. I am probably going to freeze minimal/ as have minimal-*/ too. Will they will change for bugfixes? Nope. That's the reason they are frozen. They are like tags in SVN. OK, that's good to hear. I have tried buildout, of course. Massaging the index to meet some set of expectations developers have of the client they use to install the software is fine, you did a lot of work to do this, which is appreciated, and it's your index. But I suggest that we don't discount the *really KGS* requirement, which is *absolutely repeatable builds* (today, tomorrow, two years from now), and we let people know that the KGS is not that. Why? I have listened to the community very early on, reacting to the need having certain frozen output. A few weeks back I sent a mail to the zope-dev _[1] list outlining how I think the index can be used in buildout. Since then, functionality has only expanded and other combinations are possible now. .. [1] http://mail.zope.org/pipermail/zope-dev/2007-November/030210.html So if you go to http://download.zope.org/zope3.4/intro.html into the sub-section Version 3.4.0b2 you see a bunch of links. With the exception of the Index link, all other links point to versioned file and directories, which will not change. Also, any of the versioned files and directories do not contain references to packages that are not controlled by the KGS. Great. I'm happy to be wrong. A mention on the intro page about how this versioning scheme is meant to work going forward would be nice. Nice job, - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: KGS Site Updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: On Nov 18, 2007, at 7:52 PM, Stephan Richter wrote: On Sunday 18 November 2007, Chris McDonough wrote: 4. A new minimal/ folder now contains an index just of the controlled packages. This minimal index can be used by compoze as one contributing index. (I have not tested this yet, can anyone try this and report how it can be done?) Very cool, thank you! I'll try this. Great. I would love to get a little write-up on how to use it, so I can put it on the intro page. Compoze is not ready for prime time yet, I'm afraid. You can use it to download all source packages from a working set and create an index from these. But currently I think only Tres knows how to make it do it. ;-) One you have a tested set of packages installed (findable on sys.path, actually), compoze can download the corresponding distributiongs and make a package index via: $ bin/compoze fetch --fetch-site-packages --path=/tmp/kgs \ index --path=/tmp/kgs Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQabm+gerLs4ltQ4RAtHMAJ4m5DAaFKtixNOrj6qpKdq9ZJ0epwCeJpLP KuyeNNUXSnoQchE801QTQs4= =2pSC -END PGP SIGNATURE- ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: KGS Site Updated
On Nov 19, 2007, at 9:54 AM, Tres Seaver wrote: It's a limitation of buildout, perhaps. It is possible to use setuptools with multiple indexes: 'compoze' allows spelling multiple '-index-url' items on the command line. E.g.:: I'm curious what API you're using. buildout uses setuptools.package_index.PackageIndex. This only accepts a single index URL. Of course, I could create multiple index instances, use each one and merge the results. Is that what you're doing? Jim -- Jim Fulton Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: [Zope-dev] KGS Site Updated
On Nov 19, 2007, at 1:26 PM, Dieter Maurer wrote: Chris McDonough wrote at 2007-11-18 16:50 -0500: ... Note that if the KGS really wants to be a KGS (literally known good, it's a matter of semantics, not of technology): - An invariant must be met that only one version of each package should be present in the index. - The set is frozen (no packages will be added to or removed from or changed). I do not think this is correct: The assumption that something is known good can prove to be an error. As soon as this happens, the index is no longer known good. As a consequence, it can (and should) be changed. I agree this is a really super-useful kind of index and maybe even deserves the term KGS. If it makes more sense than trying to redefine KGS, I'm arguing that there's an additional use case of a completely frozen index to get a completely repeatable set of packages, every time, forever. For example: - You create an automated developer sandbox build using the non- minimal KGS to get zope. You want this build to work repeatably, every time, without fail. - While developing, you find a bug in it that isn't yet fixed upstream. - You modify your automated build process to patch the installed KGS files using diffs to fix the bug locally. The diffs change files installed from the KGS. Those patches may begin to fail for new runs of the automated build if someone uploads a bugfix release to a package you were patching. This really isn't a problem, because Stephan has provided the capability and has signaled the intent to maintain frozen minimal sets for each release. Now we just need to define what a release is ;-) - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: KGS Site Updated
On Nov 19, 2007, at 2:52 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Nov 19, 2007, at 9:54 AM, Tres Seaver wrote: It's a limitation of buildout, perhaps. It is possible to use setuptools with multiple indexes: 'compoze' allows spelling multiple '-index-url' items on the command line. E.g.:: I'm curious what API you're using. buildout uses setuptools.package_index.PackageIndex. This only accepts a single index URL. Of course, I could create multiple index instances, use each one and merge the results. Is that what you're doing? Yes. Hm, OK. Does this let you search multiple indexes for the same package? I assume so. I consider this to me moving beyond setuptools. I'm not saying that this is necessarily bad. I imagine it would be pretty simple to add a per-package override to buildout.cfg which caused a separate index to be used to fetch a given distribution. You can already do this with the egg recipe: http://pypi.python.org/pypi/zc.recipe.egg#detailed-documentation This still only lets you search a single index when looking for a distributions to use to satisfy a set of requirements. buildout could be expanded to search multiple indexes, using the technique you seem to be using in compoze. This makes me uneasy as it seem to be moving far beyond easy_install, if not setuptools. It is my goal that buildout be compatible with easy install, in some sense. -- Jim Fulton Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: [Zope-dev] KGS Site Updated
On Monday 19 November 2007, Chris McDonough wrote: Now we just need to define what a release is ;-) Yes, I thought about this a little bit this weekend and I would love to see some discussion. For example, I do not think it will be necessary to create a new release for every change in the KGS, but rather collect them. So for example, once 3.4.0 is out, I set the version in controlled-packages.cfg to 3.4.1dev. I leave it like that until we are ready for 3.4.1 and change it then. Maybe just calling it 3.4dev would be better and whenever we are ready for a release, we create a controlled-packages.cfg file with that final version number, such as 3.4.1 or 3.4.2. All of this, of course, does not answer: What is a release? I simply do not know, but I have a hunch that it will be defined by a timespan. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] How to close a ZODB connection and reopen it for testing?
Hi,
I am currently writing a doctest for one of my persistent classes. It's
purpose is to check, if object modifications, e.g. through methods, are
really persistent, however, my objects are magically remembered, therefore I
cannot properly test them.
My doctest looks like this:
from ZODB import FileStorage, DB
storage = FileStorage.FileStorage('tests/tmp/test.fs')
db = DB(storage)
conn = db.open()
dbroot = conn.root()
x = myClass()
dbroot['x'] = x
Now I can do some modifications of my object, call some methods which modify
the object and call transaction.commit().
Next I want to somehow close the database, reopen it, read my object and check
if my modifications were really stored, e.g.:
conn.close()
db.close()
conn = db.open()
dbroot = conn.root()
y = dbroot['x']
But unfortunately, the following applies:
x is y
True
This is bad, as it means that Python/ZODB magically remembered my object and
did not reread it from the database. Therefore I cannot correctly check
persistence issues.
What is the suggested solution to this?
Best Regards,
Hermann
--
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] AW: [Zope-dev] KGS Site Updated
Hi Dieter Betreff: Re: [Zope-dev] KGS Site Updated Chris McDonough wrote at 2007-11-18 16:50 -0500: ... Note that if the KGS really wants to be a KGS (literally known good, it's a matter of semantics, not of technology): - An invariant must be met that only one version of each package should be present in the index. - The set is frozen (no packages will be added to or removed from or changed). I do not think this is correct: The assumption that something is known good can prove to be an error. As soon as this happens, the index is no longer known good. As a consequence, it can (and should) be changed. I agree, But this also means, changes must be 100% compatible with everything which was working with the KGS before the changes. (whatever this means) Otherwise it's not known good anymore. Regards Roger Ineichen -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: KGS Site Updated
On Sun, 18 Nov 2007 23:17:53 -0800, Stephan Richter [EMAIL PROTECTED] wrote: So if you go to http://download.zope.org/zope3.4/intro.html into the sub-section Version 3.4.0b2 you see a bunch of links. Just a minor observation, nowhere on that page is it explained what KGS means. :) -- Alexander Limi · http://limi.net ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
