[Zope3-Users] Re: KGS Site Updated
On Sunday 18 November 2007, Philipp von Weitershausen wrote: > > 5. There is now an introduction page called "intro.html" that lists all > > versions and files. It also explains how to use the files. See: > > http://download.zope.org/zope3.4/intro.html > > You have a typo there. The buildout option is called "extends", not > "extend". Hi Phillip, I was actually hoping that you could provide me with a little blurb on how to best use the KGS with zopeproject. Actually, I think it would be really cool, if you could just have a command-line option specifying the KGS, like:: --kgs=zope3.4 Of course, less specific choices would include something like this:: --index=http://download.zope.org/zope3.4 On the other hand, I wonder whether Zope and zopeproject releases should be somewhat synced, so that a particular line of zopeproject releases uses a particular KGS by default 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] Re: [Zope-dev] KGS Site Updated
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.) > Even if there are bugfixes available, you may not want them, or you > may have fixed the bugs your own way already (though patches or what- > have you). Maybe the KGS isn't it, but there needs to be a way to get > the very same packages, unfailingly, every time, no exceptions for > bugfixes, etc. I wish the KGS was this but it still isn't it. Well, the versioned versions.cfg file will not change. In the buildout world, I think most people will end up using versions-*.cfg when pinning down versions plus specify their own version block in their buildout.cfg for packages that we do not control. > >> The first is true for what we have now neither of the "minimal" set > >> or > >> the set you're calling the "KGS". > > > > 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. > 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. 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
Re: [Zope3-Users] A question regarding zope generations
Thanks Bernd, I am working around this issues as you have suggested. - Shailesh On Nov 17, 2007 5:31 PM, Bernd Dorn <[EMAIL PROTECTED]> wrote: > > On 16.11.2007, at 13:56, Shailesh Kumar wrote: > > > As of now, I am thinking of a following solution. For the current upgrade, > I will have some code which will automatically evolve the existing > installation during startup > (i.e. DatabaseOpenedEvent) and actually assign a generation number in the > root[generations_key]['product_name'] key. > > In the later upgrades, I will replace this with the regular schema > manager. > > Comments from the zope 3 experts would be very useful. > > > well this is a real flaw with generations ... > > in our projects we always add an initial .generations package to avoid > such cases, you can do this too, but it needs an intermediate version but > no "dummy" schema manager. > > in generations/__init__.py you add > > from zope.app.generations.generations import SchemaManager > > pkg = 'myapp' > > schemaManager = SchemaManager( > minimum_generation=0, > generation=0, > package_name=pkg) > > and register the manager. > > make a realease, this will set the generation to 0 > > then add your first "evolve1.py" to generations, the manager stays the > same - you only have to increase the generation number > > regards, bernd > > > > > > ___ 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 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. ;-) Note that if the KGS really wants to be a KGS (literally "known good", it's a matter of semantics, not of technology): I agree. - An invariant must be met that only one version of each package should be present in the index. 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. Even if there are bugfixes available, you may not want them, or you may have fixed the bugs your own way already (though patches or what- have you). Maybe the KGS isn't it, but there needs to be a way to get the very same packages, unfailingly, every time, no exceptions for bugfixes, etc. I wish the KGS was this but it still isn't it. The first is true for what we have now neither of the "minimal" set or the set you're calling the "KGS". 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? The second I'm pretty sure is not true of the thing you're calling the KGS (it still mirrors the cheeseshop regularly), I'm not sure about the intent for the "minimal" set. Well, this is a limitation of the current setuptools system. In buildout I can only specify one index, since setuptools can have only one index. So it is necessary that I make all packages available in that index and this is what I produce as download.zope.org/zope3.4. But I have explained this multiple times before, so I am not going to repeat the argument any more. Please try buildout and see for yourself. 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. In any case, thanks a lot for the work! - C ___ 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 Sunday 18 November 2007, Stephan Richter wrote: > > The first is true for what we have now neither of the "minimal" set or > > the set you're calling the "KGS". > > Right. Note that versions-*.cfg and links-*cfg are frozen. I am probably > going to freeze minimal/ as have minimal-*/ too. I have now changed the code to version the minimal index as well. It still contains multiple versions of packages that we know work together; however, for your purposes setuptools will only pick up the latest one anyways. 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] Re: [Zope-dev] KGS Site Updated
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. > Note that if the KGS really wants to be a KGS (literally "known good", > it's a matter of semantics, not of technology): I agree. > - An invariant must be met that only one version of each package > should be present in the index. 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. > - The set is frozen (no packages will be added to or removed from or > changed). Yep, I agree. No packages will be added or removed for the Zope 3.4 version of the KGS. I will soon add a new Zope-Dev KGS, which is open to new feature releases. > The first is true for what we have now neither of the "minimal" set or > the set you're calling the "KGS". Right. Note that versions-*.cfg and links-*cfg are frozen. I am probably going to freeze minimal/ as have minimal-*/ too. > The second I'm pretty sure is not > true of the thing you're calling the KGS (it still mirrors the > cheeseshop regularly), I'm not sure about the intent for the "minimal" > set. Well, this is a limitation of the current setuptools system. In buildout I can only specify one index, since setuptools can have only one index. So it is necessary that I make all packages available in that index and this is what I produce as download.zope.org/zope3.4. But I have explained this multiple times before, so I am not going to repeat the argument any more. Please try buildout and see for yourself. 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] Re: [Zope-dev] Re: KGS Site Updated
On Sunday 18 November 2007, Philipp von Weitershausen wrote: > > 3. A new "links.html" file now lists all packages in one URL, so that it > > is suitable for the "find-links" option. (I have not tested this yet, > > anyone?) > > That's quite useful when combining multiple KGSs Yes, it actually does. However, this can be a little bit misleading. By default, when no index is specified, PyPI will be used as index and find links are only used to extend beyond PyPI. However, PyPI will provide more versions than the KGS find-links. So in order to use it properly, you have to specify a Null-Index. Please correct me, if I am wrong. > You have a typo there. The buildout option is called "extends", not > "extend". Fixed. 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] Re: [Zope-dev] KGS Site Updated
On Nov 17, 2007, at 10:00 PM, Stephan Richter wrote: Hi everyone, I just updated the Zope 3.4 KGS with some new features. 1. You only need to upload the "controlled-packages.cfg" file now; all other files are generated. 2. The "controlled-packages.cfg" file now supports a name and version option. Thus, all generated files are versioned now. The unversioned version of the files refers to the latest one. 3. A new "links.html" file now lists all packages in one URL, so that it is suitable for the "find-links" option. (I have not tested this yet, anyone?) Nice. 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. 5. There is now an introduction page called "intro.html" that lists all versions and files. It also explains how to use the files. See: http://download.zope.org/zope3.4/intro.html 6. The KGS now supports extensions, meaning one KGS can build on another. You simply specify the "extend" option in the "[KGS]" section of the controlled packages configuration file. This should allow frameworks built on top of Zoep 3, like grok, to build their own KGS without much effort. That said, I would really like for people to test all the features and see whether they work for them. But most importantly, I would like for people to contribute to the "Usage" section of the introduction page! Thanks to all for listening! 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). The first is true for what we have now neither of the "minimal" set or the set you're calling the "KGS". The second I'm pretty sure is not true of the thing you're calling the KGS (it still mirrors the cheeseshop regularly), I'm not sure about the intent for the "minimal" set. - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: KGS Site Updated
Stephan Richter wrote: I just updated the Zope 3.4 KGS with some new features. 1. You only need to upload the "controlled-packages.cfg" file now; all other files are generated. 2. The "controlled-packages.cfg" file now supports a name and version option. Thus, all generated files are versioned now. The unversioned version of the files refers to the latest one. 3. A new "links.html" file now lists all packages in one URL, so that it is suitable for the "find-links" option. (I have not tested this yet, anyone?) That's quite useful when combining multiple KGSs 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?) 5. There is now an introduction page called "intro.html" that lists all versions and files. It also explains how to use the files. See: http://download.zope.org/zope3.4/intro.html You have a typo there. The buildout option is called "extends", not "extend". 6. The KGS now supports extensions, meaning one KGS can build on another. You simply specify the "extend" option in the "[KGS]" section of the controlled packages configuration file. This should allow frameworks built on top of Zoep 3, like grok, to build their own KGS without much effort. That said, I would really like for people to test all the features and see whether they work for them. But most importantly, I would like for people to contribute to the "Usage" section of the introduction page! ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: virtualenv problems
George Wright wrote:
Gidday
I have been trying to set up a virtualenv as has been suggested several
times on this list.
Following steps in section 1.4 of "Zope Component Architecture.pdf"
I have a path problem:
$ easy_install virtualenv
...
virtualenv 0.8.4 is already the active version in easy-install.pth
Installing virtualenv script to
/Library/Frameworks/Python.framework/Versions/2.4/bin
Using
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/virtualenv-0.8.4-py2.4.egg
...
Finished processing dependencies for virtualenv
$ virtualenv myvirtualenv
New python executable in myvirtualenv/bin/Python
ERROR: The executable myvirtualenv/bin/Python is not functioning
ERROR: It thinks sys.prefix is
'/Library/Frameworks/Python.framework/Versions/2.4' (should be
'/Users/georgewright/myvirtualenv')
ERROR: virtualenv is not compatible with this system or executable
$
How do I fix that sys.prefix problem?
You update to a newer virtualenv version that has a fix for this
problem. easy_install -U virtualenv. Or you install a proper Python
executable that isn't messed up as a framework build (see below).
Following threads on virtualenv I gather I should be using a "non-system
python installation". How do I do that?
By compiling it yourself. Download the Python-2.4.4.tgz tarball and do
the configure --prefix=...; make; make install dance.
I highly recommend that everybody, no matter what platform s/he's on,
does this. Default Python setups ("system pythons") are just too messed
up and often tainted by the global installation of eggs.
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
