Jim Fulton wrote:
On Apr 23, 2007, at 2:43 PM, Martijn Faassen wrote:
...
It'd be a lot easier. You'd still have to list it for all eggs that
you depend on directly. It would be nice if this could be automated as
well, as being in two places to add a single dependency is more work
than being
On Apr 23, 2007, at 2:43 PM, Martijn Faassen wrote:
...
It'd be a lot easier. You'd still have to list it for all eggs that
you depend on directly. It would be nice if this could be automated
as well, as being in two places to add a single dependency is more
work than being in one place. Co
Jim Fulton wrote:
On Apr 23, 2007, at 2:14 PM, Martijn Faassen wrote:
[snip]
As far as I can determine from this thread (I have some difficulty
following parts of David's long mail as well) you two are agreeing. :)
Jim, is it correct that you'd like the zope 3 recipe to grow an option
to au
On Apr 23, 2007, at 2:14 PM, Martijn Faassen wrote:
David Pratt wrote:
Hi Jim. I guess I missed the boat on app construction which I have
clarified hopefully below. I am speaking of using zc.zope3recipes.
As far as site.zcml. I think I'll need to experiment. At this
point I see a strong i
David Pratt wrote:
Hi Jim. I guess I missed the boat on app construction which I have
clarified hopefully below. I am speaking of using zc.zope3recipes. As
far as site.zcml. I think I'll need to experiment. At this point I see a
strong incentive to automate. Too many packages - too little time
Hi Jim. I guess I missed the boat on app construction which I have
clarified hopefully below. I am speaking of using zc.zope3recipes. As
far as site.zcml. I think I'll need to experiment. At this point I see a
strong incentive to automate. Too many packages - too little time and
too many errors
Hey Tres,
[Martijn]
I don't think something being policy means it's automatically a bad
candidate for automation. Information about the policy may after
all be elsewhere in the system, for instance in a buildout.cfg.
Tres Seaver wrote:
You don't see cases already where you want to use somethi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hello,
>
> Tres Seaver wrote:
>> David Pratt wrote:
>>> On the basis that eggs spell out dependencies, I am thinking the
>>> inclusion of packages and their dependencies should be enough to dictate
>>> the sequence of inclus
On Apr 22, 2007, at 10:32 AM, David Pratt wrote:
...
In looking at the way I am developing, my goals are package reuse
and thin glue in an app package (that is also the app egg) to bind
packages to make an application consisting mostly of installation,
security, testing and perhaps skinning
On Apr 22, 2007, at 12:00 PM, Tres Seaver wrote:
I don't think this is necessary. An egg that has ZCML should load
the ZCML from other eggs it depends on. This means that these eggs
have to be designed this way.
Our override story is too weak to support this now, because the author
of pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> On Apr 22, 2007, at 10:32 AM, David Pratt wrote:
> ...
>> In looking at the way I am developing, my goals are package reuse
>> and thin glue in an app package (that is also the app egg) to bind
>> packages to make an application
Hi Tres and Martijn. I apologize for the length of this post in advance.
I have been spending a bit of time on app buildouts over the past days.
What I have learned about some of this is that there are a couple of
ways to configure apps with pluses and minuses.
There are also major differences
Hello,
Tres Seaver wrote:
David Pratt wrote:
On the basis that eggs spell out dependencies, I am thinking the
inclusion of packages and their dependencies should be enough to dictate
the sequence of inclusion for package configuration (and creation of the
site.zcml) for the app buidout recipe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Pratt wrote:
> On the basis that eggs spell out dependencies, I am thinking the
> inclusion of packages and their dependencies should be enough to dictate
> the sequence of inclusion for package configuration (and creation of the
> site.zcml)
14 matches
Mail list logo
