[Zope-CMF] Re: Eggification redux
Tres Seaver wrote:
SVN Reorganiztion
-
I just worked a bit today on spliting CMF 2.1.0 (GenericSetup 1.3.2) out
into separately releasable egg-based distributions. For the initial
pass, see:
svn://svn.zope.org/repos/main/Products.GenericSetup/tags/1.3.2
Note that the SVN URL above is not the same as the one we've been using
(svn://svn.zope.org/repos/main/GenericSetup) and that it adds the
additional namespace package ('Products') to the checkout.I plan
to fix up the externals currenly pointing into '/GenericSetup' in the
CMF trunk and 2.1 branch, and then make '/GenericSetup' empty, with a
pointer to the new location.
Egg Releases
I uploaded the Products.GenericSetup 1.3.2 egg to the Cheeseshop:
http://pypi.python.org/pypi/Products.GenericSetup
The egg should be 'easy_installable' in any environment with setuptools
installed; if that environment has a properly-namespaced 'Products'
package (Zope2 trunk, or with the backport I'm proposing for Zope issue
#2359), it should Just Work.
Further Work
I'd like to break the remaining CMF packages out (moving from '/CMF' to
'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs
out, as well as equivalent changes for PluggableAuthService and
PluginRegistry.
Any objections, or other thoughts?
Big +1 :)
Hanno
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Eggification redux
Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Regarding the naming change: this would be consistent with other Zope 3 style changes. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Eggification redux
Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. We badly need it, not only for Zope 3 proper but also for projects which consume Zope 3 eggs (probably Zope 2 in the future, but naturally also grok). +1 to the eggification -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: GenericSetup: How to use upgradeStep?
Hi, I've been on vacation I took my time answering. Rob Miller, on 2007-09-06: okay, here's where things get off track. in GenericSetup, there is no such thing (yet, perhaps) as an upgrade profile. it's possible to define an extension profile and to USE it as part of an upgrade process (Plone has been doing this), but there's no special profile type that GS knows about. Understood. upgrade steps are not meant to represent simple profile edits. for those, you'd just change the profile and up the profile version number, no need for an upgrade step at all. How do you add a version number to a profile? You can add a version to an import step in import_steps.xml, but I do not see version info in the zcml of a profile. Or do you just mean the version.txt? The quick installer uses that of course. GenericSetup does not use that anywhere as far as I see. upgrade steps are needed for more complex situations, which cannot be represented as profile edits, and which require custom python code. My main gripe with GS is currently the handling of catalog.xml. See this issue (well, feature request): http://www.zope.org/Collectors/CMF/455 When you want to remove an index or column you can do that by editing the profile and adding remove=True to that index or column. So this upgrade can be represented as a profile edit. But applying the profile will empty the remaining indexes that are mentioned in that profile. So ideally I would want to apply the profile only once when installing and rely on upgrade steps to handle any further changes without applying that complete profile again. It seems the new upgrade steps do not really solve this particular use case then. (It can sure be handy for other things, no doubt about that.) But I had hopes to use them to work around this issue with catalog.xml. Apparently a workaround is no substitute for really solving the problem. ;-) Is anyone going to the sprints after the Plone conference who wants to take a shot at this with me? Preferably someone with commit rights. :-) [snip example] performing a full upgrade, then, would require reapplying the profile configuration and running the upgrade steps. reasonably the quickinstaller (or even the GS interface) could do this all as one step. Right. Or a warning could be displayed: This profile has upgrade steps available; do you want to run them? hopefully my above explanation helps clarify the intent of the upgradeSteps directive. Certainly. Thanks a lot. -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ Do not worry about your difficulties in computers, I can assure you mine are still greater. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Eggification redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote: Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. I don't know what you mean by this. This is the known good problem. I'm pretty convinced that adding some kind of PyPI subset, where gardeners for a given package set keep the list of packages / versions known to work well together, is the only way out of this issue. E.g., a URL like: http://pypi.python.org/pypi/release/zope3.4 would be usable as an 'index-url' for setuptools: when used this way, setuptools would only find / install eggs from the gardened set, rather than whatever anyone happened to have uploaded that day. If PyPI can't be tweaked to provide such a feature, we may need to come up with some kind of mirroring scheme which does allow it. 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 iD8DBQFG+PWv+gerLs4ltQ4RApd3AKCNANKTREE+1V7MJEexRgwNZl0DSwCfTTdL W5IG3LF2jjLbYnVTl1/6+YA= =GlfL -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Zope-PAS] Re: Eggification redux
On 25 Sep 2007, at 13:20 , Jim Fulton wrote: On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote: Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. I don't know what you mean by this. There are several problems. * We've had to nail some of the versions because buildout was being a bit over-zealous when getting eggs on Windows. It would take the newest egg, despite the fact that other eggs had binary releases. I guess that's not its fault. But it's a working set problem. * When package A depends on Y and package B also depends on Y, but with some version restrictions, buidout will first try to get the newest version of Y when installing A. But then when installing B, it is likely that it has to get a different version of Y. The result is a version conflict. This could also easily be fixed with a working set that dictates which versions would be used from the beginning. * Even with newest=false enabled in grokproject's buildout.cfg template, the versions that people will end up when trying out grok are non-deterministic. This has led to people installing newer versions of something, sometimes even faulty releases, even though Grok hadn't been tested with these newer versions yet and older versions that were known to work were the better choice. Again, a working set problem. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 11 OK
Summary of messages to the cmf-tests list. Period Mon Sep 24 12:00:00 2007 UTC to Tue Sep 25 12:00:00 2007 UTC. There were 11 messages: 11 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:25:48 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006414.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:27:19 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006415.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:28:49 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006416.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:30:20 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006417.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:31:51 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006418.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:33:22 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006419.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:34:53 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006420.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:36:23 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006421.html Subject: OK : CMF-2.1 Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:37:53 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006422.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:39:23 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006423.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Sep 24 21:40:54 EDT 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-September/006424.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [Zope-PAS] Re: Eggification redux
Previously Philipp von Weitershausen wrote: On 25 Sep 2007, at 13:20 , Jim Fulton wrote: On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote: Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. I don't know what you mean by this. There are several problems. * We've had to nail some of the versions because buildout was being a bit over-zealous when getting eggs on Windows. It would take the newest egg, despite the fact that other eggs had binary releases. I guess that's not its fault. But it's a working set problem. * When package A depends on Y and package B also depends on Y, but with some version restrictions, buidout will first try to get the newest version of Y when installing A. But then when installing B, it is likely that it has to get a different version of Y. The result is a version conflict. This could also easily be fixed with a working set that dictates which versions would be used from the beginning. This is a real problem and something that has to be fixed. It will bite us with the separate repositories Tres mentioned as well. You need to be able to analyze the dependency/conflict graph before doing anything or you will risk breaking a working system. WIchert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Eggification redux
Previously Tres Seaver wrote: Jim Fulton wrote: On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote: Charlie Clark wrote: Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Grok's problems are primarily related to the lack of a working set definition for Zope 3. I don't know what you mean by this. This is the known good problem. I'm pretty convinced that adding some kind of PyPI subset, where gardeners for a given package set keep the list of packages / versions known to work well together, is the only way out of this issue. E.g., a URL like: http://pypi.python.org/pypi/release/zope3.4 would be usable as an 'index-url' for setuptools: when used this way, setuptools would only find / install eggs from the gardened set, rather than whatever anyone happened to have uploaded that day. If PyPI can't be tweaked to provide such a feature, we may need to come up with some kind of mirroring scheme which does allow it. +1 It's the same problem Linux distributions have solved in their package managers. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Known working sets II [was: Eggification redux]
(Also CCing zope3-dev where the first known working set discussion started a while ago) Tres Seaver wrote: This is the known good problem. I'm pretty convinced that adding some kind of PyPI subset, where gardeners for a given package set keep the list of packages / versions known to work well together, is the only way out of this issue. E.g., a URL like: http://pypi.python.org/pypi/release/zope3.4 would be usable as an 'index-url' for setuptools: when used this way, setuptools would only find / install eggs from the gardened set, rather than whatever anyone happened to have uploaded that day. If PyPI can't be tweaked to provide such a feature, we may need to come up with some kind of mirroring scheme which does allow it. This is certainly an interesting approach. I'd be curious how you would garden this known working set. Martijn makes a pretty good case for maintaining such working sets close to the package in question (e.g. the grok egg, the Plone egg, etc.). I see two more solutions: * A versions.cfg that's loaded via HTTP. zc.buildout actually supports this now which makes it quite appealing. Also, far as I know, all major deployers of Zope3 that use zc.buildout for deployment use this form of pinning egg versions right now, which means it's actually being used out there. * Adding version conflict resolution to zc.buildout and/or setuptools. That way you could create meta eggs (e.g. the 'Zope' egg) with '==' version specificers (for Grok, the 'grok' egg would function as the meta egg as well). If this would cause version conflicts (and they often occur in buildout due to the lack of a full dependency tree before download), it should be possible to say which egg's versions are authoritative. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Known working sets II [was: Eggification redux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (CC'ing the Python distutils list, which is where setuptools development is discussed; maybe I should be including the catalog-sig too, but I don't read that list). Philipp von Weitershausen wrote: (Also CCing zope3-dev where the first known working set discussion started a while ago) Tres Seaver wrote: This is the known good problem. I'm pretty convinced that adding some kind of PyPI subset, where gardeners for a given package set keep the list of packages / versions known to work well together, is the only way out of this issue. E.g., a URL like: http://pypi.python.org/pypi/release/zope3.4 would be usable as an 'index-url' for setuptools: when used this way, setuptools would only find / install eggs from the gardened set, rather than whatever anyone happened to have uploaded that day. If PyPI can't be tweaked to provide such a feature, we may need to come up with some kind of mirroring scheme which does allow it. This is certainly an interesting approach. I'd be curious how you would garden this known working set. Martijn makes a pretty good case for maintaining such working sets close to the package in question (e.g. the grok egg, the Plone egg, etc.). I would argue that this problem is too big for developer convenience to drive it: we need concerted effort from the different communities of interest to manage the problem, in much the same way that Debian / Fedora etc. manage their various distribution releases. I see a PyPI subset implemented as follows: - Subset creator / owner defines the list of PyPI project names which are included in the subset. - For each project, the available releases known to PyPI fall into one of the following states: o 'unknown' is the default: newly-uploaded distributions start here. o 'known_good' is a terminal state: the creator / owner of the subset has blessed this version. o 'known_bad' is also a terminal state: this version won't *ever* be compatible with the others in the subset. - Other users should be able to report works for me / broken against a given distribution *for that subset.* Perhaps we can set up an RSS feed for each subset showning the unknown packages, so that people know they need testing. - Note that it would be possible (assuming setuptools requirements specs are sufficiently flexible) to generate a meta-egg from the known_good distribution list: such an egg's 'install_requires' would need to list the known_good values, rather than attempting to do range arithmetic. - The subset homepage would be usable as 'index_url' for setuptools, so that folks wanting to 'easy_install' a package (or drive buildout) could restrict the available packages to the known good versions. I see two more solutions: * A versions.cfg that's loaded via HTTP. zc.buildout actually supports this now which makes it quite appealing. Also, far as I know, all major deployers of Zope3 that use zc.buildout for deployment use this form of pinning egg versions right now, which means it's actually being used out there. Locking down the file doesn't solve the problem of knowing that there are new candidate / unknown distributions which need testing, nor of colleting the works for me / broken information from users. A subset could certainly generate such a view, however, which would make zc.buildout integration work on a par with the 'easy_install --index-url usecase. * Adding version conflict resolution to zc.buildout and/or setuptools. That way you could create meta eggs (e.g. the 'Zope' egg) with '==' version specificers (for Grok, the 'grok' egg would function as the meta egg as well). If this would cause version conflicts (and they often occur in buildout due to the lack of a full dependency tree before download), it should be possible to say which egg's versions are authoritative. As with an apt / yum repository, a subset could harvest and export the full dependency graph information for all included distributions, assuming that setuptools was willing to use such information rather than incrementally discovering dependencies after download. I'm not sure there is much point in trying to compute such a pickle across the whole of PyPI, however. 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 iD8DBQFG+P/I+gerLs4ltQ4RAqnvAJ43njIxLFcs3CeBiPg59EsvIP+RhACg3HZT /+6YTbnB1V50SkLtYzuNeRc= =yVfp -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature
Re: [Zope-CMF] Known working sets II [was: Eggification redux]
Am 25.09.2007 um 14:06 schrieb Philipp von Weitershausen: * A versions.cfg that's loaded via HTTP. zc.buildout actually supports this now which makes it quite appealing. Also, far as I know, all major deployers of Zope3 that use zc.buildout for deployment use this form of pinning egg versions right now, which means it's actually being used out there. This sounds essentially similar to what Tres is proposing: an online resource with explicit configuration details. * Adding version conflict resolution to zc.buildout and/or setuptools. That way you could create meta eggs (e.g. the 'Zope' egg) with '==' version specificers (for Grok, the 'grok' egg would function as the meta egg as well). If this would cause version conflicts (and they often occur in buildout due to the lack of a full dependency tree before download), it should be possible to say which egg's versions are authoritative. This sounds like an accident waiting to happen in terms of maintenance. I guess the underlying problem is the move towards the more library- based approach to Zope which makes mixing packages a bit more challenging. I haven't spent a lot of time with the various Linux package managers because most of my unix experience has been with FreeBSD where make install just works, except if you want to install unixODBC and iODBC at the same time ;-) but I have been bitten by different libraries going in different places and incompatabilities between libraries. I've also had some experience with CPAN which always does make test before installing and given the chance of incompatibilities I would hope that any installer would run tests on a temporary install before actually installing anything for real. I don't think any installer should be able to break existing components with default settings. My experiences suggest that I will be installing from source for a while yet. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Eggification redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: * When package A depends on Y and package B also depends on Y, but with some version restrictions, buidout will first try to get the newest version of Y when installing A. But then when installing B, it is likely that it has to get a different version of Y. The result is a version conflict. This could also easily be fixed with a working set that dictates which versions would be used from the beginning. IN the long run, this would be better served by a better algorithm for constructing setuptools working sets. ... which would require having access to the dependency data before installation. No, not really, at least not in buildout's case. It's really not that big a deal to download a distribution that you ultimately don't use. If we can keep setuptools from prematurely installing downloaded eggs, sure; at the moment, it is trivial to get setuptools into a false conflict situaltion, because it processes dependencies incrementally, rather than solving the transitive closure of the graph before attempting to install anything. I agree it might be better if the index made dependency data available. Not exposing the dependency information in the index seems like a missing-feature-is-really-a-bug to me. 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 iD8DBQFG+RLj+gerLs4ltQ4RAobUAJ9Fj52kb9SqHJ5rbYVNCkxUr0XRZACeKNs2 kTPVmL+rwbYixYDCm/X1LIc= =1WIX -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Known working sets II [was: Eggification redux]
Tres Seaver wrote: [snip] This is certainly an interesting approach. I'd be curious how you would garden this known working set. Martijn makes a pretty good case for maintaining such working sets close to the package in question (e.g. the grok egg, the Plone egg, etc.). I would argue that this problem is too big for developer convenience to drive it: we need concerted effort from the different communities of interest to manage the problem, in much the same way that Debian / Fedora etc. manage their various distribution releases. I want the ability to make releases of Grok so that when someone writes an application against it, it will continue to work, no matter what egg releases follow. That's a community of interest, I guess? I just want the technical ability to do so, and easily. If it's *not* convenient for developers to maintain it, it won't get maintained well by the various communities of interest. I think it's important to maintain these lists of dependencies close to what they talk about, preferably inside the packages themselves. As far as I know what is required is the ability for grok, in its setup.py, to include a list of suggested pinned dependencies (besides, and separate from, the normal dependencies). It should also be easy to configure buildout to inspect this list. What is also required is a way to easily create and maintain this list. Now I think you're talking about ways to maintain, report and test such lists below, but I want to solve my immediate problems first. I also need this solved preferably today. It's the primary hurt of Grok today. Everything else is peanuts. Of course, if we don't need flexibility to allow application developers to diverge from Grok's recommendation, this problem is solved today, except for the bit to actually generate the list of dependencies. We can simply hardcode them as dependencies in Grok's setup.py and tell everybody who wants to use newer versions of eggs for whatever reasons in their applications too bad, wait for the new release. Regards, Martijn ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
Martijn Faassen wrote at 2007-9-25 17:22 +0200: ... Should we then encourage everyone to hardcode version numbers in their setup.py's dependencies list? I think this goes against building applications from components -- as it drastically increases the probability of conflicts. Components should are week dependancy requirements to be maximally usable -- not fixed dependancies. I think, this holds for frameworks, too, as they are also components. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
