Hi Martijn
> Betreff: Re: [Zope-dev] zope.globalrequest?
>
> Hi there,
>
> Roger Ineichen wrote:
> [snip]
> > Why should someone use a global request if he has a request
> available?
> > This package does nothing else then offer a request if non is
> >
Regards
Roger Ineichen
_
END OF MESSAGE
> -Ursprüngliche Nachricht-
> Von: zope-dev-boun...@zope.org
> [mailto:zope-dev-boun...@zope.org] Im Auftrag von Laurence Rowe
> Gesendet: Sonntag, 18. Januar 2009 16:43
> An: zope-dev@zope.org
>
Hi Andi
> Betreff: Re: [Zope-dev] zope.globalrequest?
>
> Roger Ineichen wrote:
> > I don't say that this is bad in general. I just say that if
> you build
> > an application based on zope.globalrequest, this is a
> totaly different
> > base concept how
test testing
an application.
I don't say that this is bad in general. I just say that if
you build an application based on zope.globalrequest, this
is a totaly different base concept how you will develop
applications like we do now. And you have to pay the price
with a complex test setup
ese packages.
>
> We have two at the moment:
>
> http://pypi.python.org/pypi/lazr.delegates
>
> Provides an interesting Python delegation pattern. Uses
> zope.interface.
cool !
1+ for move this to zope.interface
Regards
Roger Ineichen
___
Hi Martijn
> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form?
> [Re:zope.browser?]
>
> Hey there,
>
> Roger Ineichen wrote:
> [snip]
> > I don't like that. Probably we should use the existing devmode or
> > something like that? Devmode whoul
e existing devmode
or something like that? Devmode whould allow us to use it at
runtime and during testing. What about a deprecation mode?
I really like to use such deprecation messages in production too.
I think it's a must that we can use them on productive servers
and see what happens with thi
Hi Jim
Just found an issue in ZODB 3.8 branch. (3.8.1 release)
The line: 370 in blob.py uses *targetpath* (undefined)
This should be *path*.
The current 3.9 trunk is fixed.
I didn't fix and release that issue because I only have a
MinGW compiler installed. Can you pick that up?
Regards
;t use this
packages without the get the dependency back. And that hurts.
I think such cleanup ar not optional and only a nice thing.
Such cleanup allow us to participate on the same base.
And since BBB support is given (with a minimal deprecation
warning sideeffect) I th
hing to do with
beautify our test output.
Regards
Roger Ineichen
___
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/zo
Hi Christian
> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form?
> [Re:zope.browser?]
>
> On 2008-12-15 13:44:43 +0100, "Roger Ineichen"
> said:
>
> > Hi Christian
> >
> >> Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:
. But I think that's fine. Isn't it?
In my point of view, deprecation messages are a great concept
to announce changes/improvments without to break compatibility.
Without such announcements our code can get very quick out
of date and we have no change to know about that.
btw,
we also shoul
Hi Robert
> Betreff: Re: [Zope-dev] zope.browser?
>
> Hi,
>
> Am Donnerstag, den 11.12.2008, 17:13 +0100 schrieb Roger Ineichen:
>
> >
> > I just moved the zope.app.form.interfaces.ITerms interface to this
> > package. Which makes it possible to impleme
ike to keep the discussion to a minimum
and be a more productive.
I'll promiss to take care and do nothing which doesn't
make sense.
Does this Ok and does it make sense for you?
Regards
Roger Ineichen
___
Zope-Dev maillist - Zope-Dev@zo
Hi Martijn
> Betreff: Re: [Zope-dev] zope.browser?
>
> Martijn Faassen wrote:
> > Hi there,
> >
> > I saw that Roger Ineichen created and released a package called
> > zope.browser.
> >
> > I assume that this package is intended to reduce
>
Hi Herman
> Betreff: Re: [Zope-dev] z3c.form 2.0 release
>
> Am Dienstag 09 Dezember 2008 16:24:41 schrieb Roger Ineichen:
> > Hi Brian
> >
> > > Betreff: Re: [Zope-dev] z3c.form 2.0 release
> > >
> > > On Sun, Dec 07, 2008 at 11:27:01PM -0
illing to
> implement that if there's enough support.
>
> [1]
> http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
I agree
A package should never use another package as it's namespace.
Which means a package can
change.
Should I do that tomorrow? And adjust all related packages
like zope.app.form, z3c.form etc. Are there other packages
which use ITerms except the one in zope.*?
Christian, are you fine with this? Can you based on that
merge your branch to z3c.form?
Regards
Roger Ineichen
> Rega
Hi Michael
> Betreff: Re: [Zope-dev] z3c.form 2.0 release
>
> Am 08.12.2008 um 08:27 schrieb Stephan Richter:
> > On Friday 05 December 2008, Martin Aspeli wrote:
> >> Is there any indication on when we'll see a 2.0 release of
> z3c.form?
> >>
> >> We need a widget that's not in the 1.9 release,
Hi Dan
I just commited the latest changes for z3c.indexer.
Can you review this and let me know if this will fit
for you?
Any hints or improvment is very welcome.
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev
elcome.
I have some important changes in my workplace. I'll
merge your changes into this work an release it
this weekend.
Regards
Roger Ineichen
> --
> WBR, Dan Korostelev
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org
compared to a regular start.
>
> Any objections?
+1 very good idea
Regards
Roger Ineichen
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
ht
es to reduce the variants of it. It whould
not be helpful to have several different named interfaces
just because they support another constructor signature.
But describing a constructor signature is not in general a
bad thing.
Regards
Roger Ineichen
> --
>
s loaded after the import feature.
This was ending in none covered import lines and global
module variable (application-like code).
This was fixed in zope.testing
revision 90220:
- let the coverage feature start earlier then the find feature
- adjust test coverage test
and should be released in 3.
using Python 2.4?
Regards
Roger Ineichen
> Andreas
___
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
te
> function, and I believe it could be moved to z3c.batching?
yes, why not, sounds good to me.
I just added my latest pending bugfix to z3c.table.
I also added you as an Owner to the z3c.batching package at PyPi.
Regards
Roger Ineichen
__
Hi Malthe
> Betreff: Re: [Zope-dev] Interface for renderable component
>
> 2008/9/16 Roger Ineichen <[EMAIL PROTECTED]>:
> > yes, this package must be a zope.* package.
> > Then we could move the ITerms interface to this package too rather
> > then add a new on
different z3c.* packages.
The problem right now is that we need to ensure a
stable release concept for lxml on windows.
Are you doing future release for lxml?
btw,
are you using the Visual Studio or mingw compiler?
Regards
Roger Ineichen
___
Zope-Dev maill
Hi Stephan
> Betreff: Re: [Zope-dev] Interface for renderable component
>
> On Tuesday 16 September 2008, Malthe Borch wrote:
> > 2008/9/16 Stephan Richter <[EMAIL PROTECTED]>:
> > > Yeah, I like that. This is the right package, since it defines
> > > high-level patterns without any heavy implem
rface too. And the ITerms
interface could also become a part of this package rather
then move to a zope.term package which we already agreed on.
Regards
Roger Ineichen
> \malthe
>
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.z
events. Because the API which web dav uses
is implemented as views, right?
I also think this is probably special for FTP and Web Dav
but not required in web browser views.
Regards
Roger Ineichen
_
END OF MESSAGE
> --
> Sidnei da S
Hi Martijn
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
> Roger Ineichen wrote:
> [snip]
> > Most packages which are interesting for reuse provide more or less
> > only ZMI related views.
> >
> > What about zope.zmi if they provide
mature, dynamic and efficient.
Sounds interesting but let's put that on the todo later list.
Regards
Roger Ineichen
_
END OF MESSAGE
> On Wed, Sep 3, 2008 at 3:06 PM, Roger Ineichen
> <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> >> Be
e interesting for reuse
provide more or less only ZMI related views.
What about zope.zmi if they provide views for
the ZMI. This views are allmost unuseable
outside the ZMI (know as Rotterdam skin)
Regards
Roger Ineichen
> --
> Benji York
> Senior Software Engineer
> Zope Corporat
Hi Martijn
> Betreff: Re: [Zope-dev] Dependencies and future of zope 3
>
> Hi there,
> Roger Ineichen wrote:
> [snip]
> > Is someone willing to help doing that task?
>
> I'm very interested in this topic as well, especially from
> the perspective of Gr
redible tool already.
See in action, it's really great:
http://mg.pov.lt/blog/2007/09
http://wiki.zope.org/zope3/PackageDependenciesTool
Regards
Roger Ineichen
> Andreas
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/list
cause we didn't
see all the usecases. But now since we have grok, repoze and z3c
we have many more options to reuse other components and this makes
it much clearer what we have to provide as reusable and what not.
Regards
Roger Ineichen
> -aj
am of developers
which volunteer to review such cleanup work. That makes it
easier to make decisions and avoids that people get stocked
with their cleanup work.
Is someone willing to help doing that task?
Regards
Roger Ineichen
> Regards
> David
> ___
&
t; such into its
> > > own package zope.terms.
> >
> > I don't have a problem with that. :)
>
> That's what I thought. Impasse resolved? :-)
Yeah,
this sounds very good to me. I'll pick that up
next week and implement this part in a branch for review.
Regar
Hi Jim
> Betreff: Re: [Zope-dev] Make simple ISource usable
>
>
> On Aug 30, 2008, at 10:54 AM, Roger Ineichen wrote:
> > But zope.schema does already know about term.
>
> This was a mistake.
Let's fix that mistake and do it right. That's all
I'm asking
lternative to Roger's proposal would be to move the
> ITerms declaration and any possible generic implementation of
> such into its own package zope.terms.
+1
I'm fine with that. Everything is better then having
this interface in zope.app.form since zope.app.security
is using i
.
Take a look at MappedTerms in zc.sourcefactory.browser.mapping.
I guess this mapping is used for any zc.resourcefactory
implementation. right?
I'm not sure because I don't use that package right now.
Regards
Roger Ineichen
> Christian
>
> --
> Christian Theune · [EMAI
Hi Christian
> Betreff: Re: [Zope-dev] Make simple ISource usable
[...]
> > The ITrems is a standard API for handle ISource, doesn't
> nmatter how
> > you will query or get our data form an ISource.
>
> This sounds like you want to implement something different
> than ITerms but that you see
have now? Why
> do I need it?
I know that you are using the zc.sourcefactory package.
Take a look at that package and you will see that this
package can't do what it does without ITerms from
zope.app.form. If we don't move that from zope.app.form
to another location. We can neve
ns whihc offer ITerms
support within z3c.form out of the box. If this interface will stay
in zope.app.form we never can use such ITerms/ISource component.
Of corse we could remove the request as a required adapter
discriminator from ITerms by default.
Regards
Roger Ineichen
> --
> Chris
Source. ISourceQueriables
uses a queryable and ITerms could use ITerm objects. That's just
a standard concept which defines how other packages can implement
usable components to work with ISource.
Right now other packages are using the ITerms interface
from zope.app.form for implement
l value
but this value is invalid for Bool fields. If the goal
is to indicate a *not set value* then we are fine. If you
set the field to require=True and that's fundamental part
of your business logic, then it could end in a nightmare
because of the invalid default. At least if the application
w
Hi Chritian
> Betreff: Re: [Zope-dev] Make simple ISource usable
>
> On Fri, 2008-08-29 at 15:01 +0200, Roger Ineichen wrote:
> > [...]
> >
> > The only query API defined for ISource in zope.schema is the
> > ISourceQueriables API. That's defently to
f zope.app.testing and put
> it somewhere else (zope.testing?).
+1
Yes, we need both,
We need to move some parts from zope.app.testing to the right
packages and we need to remove zope.app.testing as a general
dependency from some packages.
Regards
Roger Ineichen
> Marius Gedminas
>
change; it seems we're about to have a fork
> the size of the emacs/xemacs conflict, because for projects
> like repoze.bfg, dependency hell is no longer acceptable.
Yes, I agree,
The same is true for our z3c.* based projects.
Regards
Roger Ineichen
> \malthe
>
> __
sh it *right
> now*, since we all have things we need to get done.
come on, that's a real bad answer and will only stop others
from doing the right thing for you. We can't take care
on everybody if we do cleanup work. And you have always
the option to relay on the KGS or other egg ve
Any objections or hints about that?
Regards
Roger Ineichen
_
Projekt01 GmbH
www.projekt01.ch
Boesch 65
6331 Hünenberg
phone +41 (0)41 781 01 78
mobile+41 (0)79 340 52 32
fax +41 (0)41 781 00 78
email [EMAIL PROTECTED]
__
ently the wrong type for such an attribute. If you like
to do so, you need to define a choice which you can
choose form and use another HTML input component then
a single checkbox input or two radio (yes, no) elements.
Hermann,
can you you give me a short description of the problem what
this thr
; > do that anyway sometimes.
>
> I don't understand what you're saying here. Are you talking
> about that application of yours that you've refered to
> earlier? Who has to migrate to z3c.form, and how does this
> affect the development of zope.app.form?
Sorry
which supports
the old behavior by default.
Note, this whould probably also break other packages like
z3c.csvvocabulary.
If nobody else objects I'm fine with this changes and will fix a
Zope3 revision for this project and start to migrate to z3c.form.
We have to do that anyway sometime
+1 too for a simple zope.configuration package which offers
the API for doing configuration how it should.
What do you think about to release z3c.unconfigure and merge it
to zope.configuration after the release. So we have both options
and a simple setup for the future.
Regards
Roger Ineichen
__
events
for specific interfaces if items get added.
I'm fine with everything if you make sure that you
don't notify events for my referenced objects. At least
not with default events which hook up existing subscribers.
Regards
Roger Ineichen
> Wichert.
>
> --
> Wichert Akke
lready excessively implicit, and often need
> to be suppressed for large applications.
I agree on that. I recommend everybody to use it's own custom
event handling in complexer applications. And avoid every
event which is offered by Zope3 as default. The speedup
can be hugh if you select carful
anager.
>
> Any objections?
Does this bring in new dependencies to zope.session?
if not moreDependencies:
+1
else:
-1
btw, I hope it will be still possible to remove the
zope.app.appsetup somedays from the zope.session package.
Regards
Roger Ineichen
> Jim
>
> --
> Jim Fulton
t; > on zope.app.container? What is the procedure? Then how can
> I run all
> > the tests?
>
>
> ok, it's explained in zope.kgs
Yeah, thanks!
I already released the zope.app.authentication package fix.
Regards
Roger Ineichen
> > Christophe
_
s different
container packages.
Just released zope.app.authentication 3.4.2
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross post
super(BTreeContainer,self).__init__()
instead of:
super(GroupFolder, self).__init__()
btw, did someone run the tests with all packages that depend
on zope.app.container?
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev m
onds (give
> or take) on a dual-core box with 3 simultaneous subprocesses.
Yeah, great!
Regards
Roger Ineichen
> Benji York
> Senior Software Engineer
> Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/
> 1 include per line
>
> Why's that?
Why not ;-)
I like one import per line too, because I get a better
overview. But that's just a personal taste.
Regards
Roger Ineichen
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope
so valid for high secure
systems that a deny is allways a deny. This means if you will get
any deny from somewhere you will not be allowd to access it.
The default policy makes it real hard to find out if some bad settings
give access to the wrong users. But since we have the great security
too
t a negative touch in the future. Probably you must
be able to switch very fast from google to a none shared DB
if customers become a bad feeling about it.
But I guess that's another topic. Anyway, sounds really great!
Regards
Roger Ineichen
> jodok
> --
> Lovely Systems, Partne
Hi Philipp
> Betreff: Re: NotFound
>
> Roger Ineichen wrote:
> > Is there a reason why zope.publisher.interfaces.NotFound
> > is not locatable?
> >
> > class NotFound(LookupError, TraversalException):
> > implements(INotFound)
> >
>
locatable
by default since it provides a location?
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding
btw, with a working setup I don't talk about a running server.
But at least all dependent packages should be there. And since
we have a buildout concept, I think it's the simplest way to
setup such dependencies and provide a working set.
Regards
Roger Ineichen
> Regards,
sus Unix line endings in
> subversion, which has nothing to do with this recipe.
>
> > I see, I 'll add a normalizer for that. I thought it was already
> > there, but could be not correct implemented.
>
> If you have a fix for that and you need me
concept
>
> Stephan Richter, on 2008-05-08:
> > On Wednesday 07 May 2008, Roger Ineichen wrote:
> >> > I like that it can extract locales from eggs. I don't
> like that it
> >> > uses zcml for this. Is the zcml really necessary?
> >>
> >>
Hi Maurits
Thanks for your feedback,
> Betreff: [Zope-dev] Re: AW: Re: New i18n locale extraction concept
>
> Hi Roger,
>
> Roger Ineichen, on 2008-05-01:
> > I agree, a tool whould be great. But the first we need to
> offer i18n
> > extract script which can han
Hi
> Betreff: [Zope-dev] Re: Heads up - package lost on pypi!
>
> Baiju M wrote:
> > Roger Ineichen wrote:
> >> Hi all
> >>
> >> The z3c.configurator package is gone on PyPi.
> >>
> >> Does sombody know what's happen? And mor
Hi all
The z3c.configurator package is gone on PyPi.
Does sombody know what's happen?
And more important, how can we recover this?
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev maillist - Zope-Dev@zope.org
Hi Maurits
> Betreff: [Zope-dev] Re: New i18n locale extraction concept
>
> Christian Zagrodnick, on 2008-05-01:
> > On 2008-05-01 02:06:17 +0200, "Roger Ineichen"
> <[EMAIL PROTECTED]> said:
> >>
> >>
> >> What does this mean?
&
> > this message is caused by z3c.form:
>
> The same happens for lovely.recipe:
>
> http://pypi.python.org/simple/lovely.recipe
I had no time to take a closer look at that. But I guess
it's the lovely.recipe which forces to return the
svn-- message.
Regards
Roger Ineiche
Hi Christophe
> Betreff: Re: [Zope-dev] Re: New i18n locale extraction concept
[]
> >> The best option whould be to split zope.app.locales into usefull
> >> packages. The not so good optipon whould be to copy over
> the relevant
> >> classes and scripts to the recipe and skip the dependen
Hi Hanno
> Betreff: [Zope-dev] Re: New i18n locale extraction concept
>
> Hi.
>
> Roger Ineichen wrote:
> > I added a new package for extract i18n locales and I have some
> > questions.
> >
> > Is it posible to split the zope.app.locales packa
domain including
the translation for a larger setup of packages, he is probably
willing to translate all of them because he allready started
the setup and beginns to translate.
Regards
Roger Ineichen
> --
> Christian Zagrodnick
>
> gocept gmbh & co. kg . forsterstrasse 29 .
?
Regards
Roger Ineichen
_
END OF MESSAGE
___
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
uld this
> break anything?
I guess you are talking about the zope.* namespace, right?
I'll start adding a generic z3c.locales which allows us to
start translate all z3c.* packages which define the plain z3c as domain.
[...]
Regards
Roger Ineichen
> Christian Zagrodnick
>
> gocep
the interfaces.
> >
> > If we want to support a nozodb-environment, it would be nice to not
> > have to pull in ZODB just to get these frameworky definitions.
> >
> > Is it package overkill to move these out to, say, zope.container?
>
> +1
>
> Also th
t crop up in a few builds.
> Anyone else seeing this. Many thanks.
I see this too. Try the buildout debug option, probably this
will you give a better output.
Regards
Roger Ineichen
_
END OF MESSAGE
> Regards,
> David
> _
Hi Christian
Regards
Roger Ineichen
_
END OF MESSAGE
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im
> Auftrag von Nikolay Kim
> Gesendet: Dienstag, 15. April 2008 22:29
> An: zope-dev@zope.org
> B
> > dependency on zope.testing, but I would and have used test
> extras to
> > avoid more extensive dependencies.
>
> +1 as well. One of my intentions here is to avoid getting zope.app.*
> dependencies in zope.* packages. However, in the long run,
> those dependencies p
Hi yuppie
> Betreff: [Zope-dev] coding style: using zapi recommended?
[...]
> In the Five version
>
>from zope.app import zapi
>factory = zapi.getUtility(IFactory, type_name)
>
> was replaced by
>
>import zope.component
>factory = zope.component.getUtility(IFactory, type_name)
which the package
doesn't need, we have two choices.
1. write tests wihtout thrid party code (code which is not a dependency
of the package at all)
2. write tests and depend on third party code but move the dependency
to extra_requires. This allows to i
ss this is one of the packages which makes it
impossible to get rid of testing stuff on production
servers! right or not?
This happens in 3.4.0, 3.4.0a1 was Ok.
Can anybody agree that the testing dependencies
should go to extra_requires ['test'] ?
Regards
Roger Ineichen
__
tp://wiki.zope.org/zope3/SessionCredentialsAPIEnhancements
Thanks a lot for pick up that work. Looks very promising.
One imporant part whould be to prevent write access on each
request. But you noticed that already on your wiki page.
Regards
Roger Ineichen
_
y since
probably not everybody will use zc.table or z3c.contents
Darryl also did some improvments on a branch of z3c.contents
which we need to merge back before we do a release.
If this is done, ZAM should be stable enough for production.
Regards
Roger Ineichen
> Chris Withers wrote:
> >
other
packages depending on zope.app.authentication.
Does somebody see a good reason not to move the password
manager part out of zope.app.authentication?
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev maillist - Zop
thentication.simple
Does anybody think we will need a migration script?
Regards
Roger Ineichen
_
END OF MESSAGE
> Regards,
> David
>
> Jim Fulton wrote:
> >
> > Let's move this discussion to zope-dev.
> >
> > On Apr 2, 2008, a
has already been transformed to a list (a
> bold assumtion as I think, since it depends on the default
> templates) and it will accept query-strings of the given form.
Ok, I got it, I think you are right.
Stephan, any hints?
Regards
Roger Ineichen
> Regards,
>
> Mat
>
_
u are trying to convert this simple data
string into a sequence, right?
Try to build a sequence of values as:
search.html?text=foo&text=bar
that's the right way to send sequence data and will give you
the result:
text = ['foo', 'bar']
at the server side.
Regards
Roger
bably the concept offered in z3c.filetype could be usefull
for a better solution. Any hints are welcome!
Regards
Roger Ineichen
_
END OF MESSAGE
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/lis
this by simply
set ``fields['foobar'].widgetFactory = TextWidget``.
-
Does this make sense to you?
Any hintes and improvments are very welcome.
Regards
Roger Ineichen
> Christophe
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.o
ride=" instead of "develop=".
Then override is what does not happen right now if there
is a version involved. Override has similar meanings in ZCML
allready.
Regards
Roger Ineichen
> The semantics are that it will list the packa
hich I add as develop externals
which are not listed in an index. I guess they behave very
different, right?
For me it's still very simple like for Martijn. If you develop
it's an explicit task and later if you are ready, you have to
think about release and deployment.
ne with version over develop. It's just another thing
you have to know for sucessfull development. I guess my brain has some
little space for remember such tweaks in buildout ;-)
Regards
Roger Ineichen
> regards
> Christophe
>
>
> >
> > Regards,
> > David
> >
ny system package installs :("
> As you found out, you can simply override the version in your
> buildout/
Only for development, it doesn't make sense this duplicated
definition. It sound like a additionl seatbelt. For what is this
double definition good for? Or is this based on some
101 - 200 of 234 matches
Mail list logo
