Re: [Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Hanno Schlichting wrote: Hi. Chris McDonough wrote: True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from "stock" Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive. We have lots of instance creation logic in the plone.recipe.zope2instance package as well. While it currently still calls mkzope2instance internally, there isn't really anything from it which it depends on anymore. While this code is currently zc.buildout specific, I would favor a smarter general instance creation script where we could offload all logic to. Currently there is too much zope.conf building stuff and a improved test runner and control script in that recipe, where lots of the parts are reusable. Most of this is providing a Python API to build zope.conf and adjusting the default values of some options to more sensible values. We also have the zope2zeoserver recipe which on top provides the missing Windows support scripts and adjustments for ZEO. Do people feel any of this should be more generally reusable? What does repoze.zope2 currently do in this area or would like to do? repoze.zope2 doesn't use any of the instance-file-creation stuff in Zope. So far we haven't much want to either, because creating instances is pretty easy. Also, because repoze.zope2 depends on PasteScript, we have the opportunity to use "paster create" to create repoze.zope2 instances. Although we don't yet do that, that might be the natural way for us to go if we did want to use any framework to create instances. But "paster create" would probably not be a reasonable way to generate instances for "plain old Zope", because it would form a dependency on PasteScript, which Zope 2 doesn't currently need otherwise. But with that in mind, I think we would be happiest if there was an egg that could be installed that got all the Zope libs but which didn't subsequently install instance creation / instance management console scripts (back to the "zope2libs" idea..). Might that also be the case for Plone? - C ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Hi. Chris McDonough wrote: True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from "stock" Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive. We have lots of instance creation logic in the plone.recipe.zope2instance package as well. While it currently still calls mkzope2instance internally, there isn't really anything from it which it depends on anymore. While this code is currently zc.buildout specific, I would favor a smarter general instance creation script where we could offload all logic to. Currently there is too much zope.conf building stuff and a improved test runner and control script in that recipe, where lots of the parts are reusable. Most of this is providing a Python API to build zope.conf and adjusting the default values of some options to more sensible values. We also have the zope2zeoserver recipe which on top provides the missing Windows support scripts and adjustments for ZEO. Do people feel any of this should be more generally reusable? What does repoze.zope2 currently do in this area or would like to do? Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Philipp von Weitershausen wrote: I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The "one big egg" strategy might also let us explain it a little more easier to old-hand Zope2 devs who aren't used to eggs: "everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that you're used to eggs, we've moved DateTime out into a separate egg", so on and so forth. Ok, fine by me. Cool. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow. Which they're not :). We might call it 'zope2libs'. What's wrong with just 'Zope2'? It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost "meta-egg" (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, "Zope2" sounds good to me. Well, taking your "everything that used to be in the tarball..." argument, then this would indeed be the outmost egg, incl. the instance scripts. True, although the Zope2 instance-creation scripts will probably become setuptools console scripts, which means that things will likely need to get shuffled around a bit from how things are now regardless and old hands will be baffled anyway. repoze.zope2 needs the libraries, but doesn't need the stock Zope instance creation scripts (repoze.zope2's may actually conflict name-wise with those from "stock" Zope 2). I'll see if I can figure out a way that repoze.zope2 can just use stock zope2 instance-creation scripts so making a different meta-egg that includes just instance creation stuff isn't as attractive. A nit: I might call the outermost egg "zope2" because I have a preference for lowercase egg names and we also already have a *package* named "Zope2", and it'd be nice to know where you are at the bash prompt without needing to print the whole path. I have a slight preference for "Zope2" because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with "Zope2". Alright. I'm excited about this. ;-) - C ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
On 19 Apr 2008, at 22:39 , Chris McDonough wrote: Philipp von Weitershausen wrote: Chris McDonough wrote: I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime). I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The "one big egg" strategy might also let us explain it a little more easier to old- hand Zope2 devs who aren't used to eggs: "everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that you're used to eggs, we've moved DateTime out into a separate egg", so on and so forth. Ok, fine by me. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow. Which they're not :). We might call it 'zope2libs'. What's wrong with just 'Zope2'? It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost "meta-egg" (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, "Zope2" sounds good to me. Well, taking your "everything that used to be in the tarball..." argument, then this would indeed be the outmost egg, incl. the instance scripts. A nit: I might call the outermost egg "zope2" because I have a preference for lowercase egg names and we also already have a *package* named "Zope2", and it'd be nice to know where you are at the bash prompt without needing to print the whole path. I have a slight preference for "Zope2" because that's what egg names usually look like. Also, if you told people Zope 2 was now available in egg form and asked them to guess what the egg was called, I think most would come up with "Zope2". ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Philipp von Weitershausen wrote: Chris McDonough wrote: I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime). I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3 folks, ZODB folks, or other independent authors) maintain shipped inside a single egg. In particular, I think this might be what to aim for in the very first Zope 2 egg-based release, because we can always move stuff out in a later release, but it's harder to reel something back in if we find that moving it out has been a mistake. The "one big egg" strategy might also let us explain it a little more easier to old-hand Zope2 devs who aren't used to eggs: "everything that used to be in the tarball except ZODB, Zope 3 libraries, and external libs is in the zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that you're used to eggs, we've moved DateTime out into a separate egg", so on and so forth. But I'll try not to get hung up on it if other really want to bust things apart. I guess in particular, I'm not keen on trying to externalize ExtensionClass or Acquisition unless somebody else has a strong desire to do this because they're using them outside Zope somehow. We might call it 'zope2libs'. What's wrong with just 'Zope2'? It would be nice to disambiguate the libraries needed to run Zope 2 from the wrapper stuff required to configure an instance. The very outmost "meta-egg" (or buildout, or whatever) should probably be named Zope2. This might or might not be it. If this *is* that outermost egg, "Zope2" sounds good to me. A nit: I might call the outermost egg "zope2" because I have a preference for lowercase egg names and we also already have a *package* named "Zope2", and it'd be nice to know where you are at the bash prompt without needing to print the whole path. What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly. I don't see this as a huge problem. You have a point that C headers introduce un-documented dependencies, but then again, how often do C headers change? It has worked so far with externals to the ZODB tree, it's not like anything's going to change there any time soon. (For instance, when I hacked Acquisition to support __parent__ pointers, I didn't have to change the headers either). We can probably manage it by being careful to match up egg dependencies to externals at release time. If folks force an install that doesn't make sense dependency-wise, they can lose. - C ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]
Chris McDonough wrote: I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on Yup. These are all done already. The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). Yup, we can do it like that. I still maintain that the zLOG, Interface and DateTime packages could be packaged separately without much effort. The benefit with those is that they'll either be obsolete very soon (zLOG, Interface) or may need off-beat updates (DateTime). We might call it 'zope2libs'. What's wrong with just 'Zope2'? What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly. I don't see this as a huge problem. You have a point that C headers introduce un-documented dependencies, but then again, how often do C headers change? It has worked so far with externals to the ZODB tree, it's not like anything's going to change there any time soon. (For instance, when I hacked Acquisition to support __parent__ pointers, I didn't have to change the headers either). ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
