On Tuesday 17 February 2004 01:10 pm, Dieter Maurer wrote:
It would be better if the type of the imported
object (schema or component) were orthogonal
to the location from where the object is found
(in a package or via an URL).
I agree, that does seem nicer.
Another approach would be to
On Thursday 26 February 2004 06:50 am, Nikolay Kim wrote:
is there any way create server for new protocol without changing ZServer
module?
There's clearly a need for some more documentation here, but I'm not sure what
to write yet, or where it should go.
Contrary to many of the other
On Sunday 29 February 2004 11:21 pm, Nikolay Kim wrote:
P.S. i'm developing smtp server for zope and already have working code.
Ooh! This is really cool. Will this be open source? I'll be a lot of people
will be interested in this.
-Fred
--
Fred L. Drake, Jr. fred at zope.com
On Tuesday 09 March 2004 01:58 pm, Ian Beatty wrote:
This has to be an easy one.
Good, I'll take it. ;-)
From within my Python-based product's code, how do I get access to the
product's directory on the filesystem? os.getcwd() seems to provide the
working directory of the shell used to
On Tuesday 09 March 2004 02:30 pm, Chris McDonough wrote:
There is also a convenience function for this in Zope:
from Globals import package_home
here = package_home(globals())
Maybe I'm just weird, but I generally prefer the general approach when there's
not a clear improvement in
On Thursday 11 March 2004 10:40 am, Tres Seaver wrote:
#!/usr/bin/python2.3
distutils will munge it anyway, if it installs the scripts.
That won't work for a lot of developers, I'll bet, who have python2.3
installed in /usr/local/bin. The env hack is more reasonable for
developers; since
On Friday 12 March 2004 05:40 am, yuppie wrote:
I don't care much *how* this is resolved, but I'd like to have this
consistent and up to date. If I always have to check if the python
version is set correctly that line isn't helpful at all.
Well, Tres appearantly hasn't had time to respond.
On Tuesday 30 March 2004 01:40 pm, Dieter Maurer wrote:
Furthermore, stylesheets often contain customization variables,
e.g. for a color scheme. I think, this is useful.
This is one of the most painful warts in CSS that would have been really easy
to do right, I think. Being able to name
On Thursday 08 April 2004 10:00 am, Philipp von Weitershausen wrote:
I would like to backport this patch (including tests) to Zope 2, since I
need to i18n XML generated by ZPTs.
None here.
-Fred
--
Fred L. Drake, Jr. fred at zope.com
PythonLabs at Zope Corporation
I've posted a distribution for ZConfig 2.1 on the ZConfig page:
http://zope.org/Members/fdrake/zconfig/
This fixes a few bugs and improves the ability to set default values in
schemas. It also adds some helpful schema building blocks, including a
general mapping type and support for
On Tuesday 13 April 2004 01:44 pm, Paul Edward Brinich wrote:
I was wondering if someone on this list could point me in the direction
of an appropriate place to post Zope job openings. I am looking for an
audience well-versed in Zope. Thanks for any guidance!
There's the Python Job Board:
zLOG is dead
The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has
been declared obsolete. All logging for Zope products will use the
logging package from Python's standard library.
The zLOG package still exists in Zope 2 and the separate package for
Jim Fulton noted:
Of course, having two packages with names differing only in case is a
bit ugly.
Do we want to consider renaming one or both of these packages
to avoid the conflict?
A bit ugly, but I can live with it.
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
-1 to renaming
On Wednesday 14 April 2004 01:49 am, Andreas Jung wrote:
What is the recommend way to migrate existing code?
I assume using:
import logging
logger = logging.getLogger(loggername).
That works, and certainly matches what I've been doing, and what we see in the
Zope 3 codebase as well.
On Wednesday 14 April 2004 09:54 am, Kapil Thangavelu wrote:
its probably a problem imo for mac users who are on a case insensitive
fs.
Is this still an issue for Mac OS X, or is your concern for classic Mac OS? I
don't know if we support that (simply because I've never heard anyone mention
On Wednesday 14 April 2004 11:44 am, Lennart Regebro wrote:
Yeah, but is it reasonable to think that people who write new products
will do this? A rule that most people will break is a bad rule... That
people working on Zope itself can be well versed enough to use Zope.
for things in
On Wednesday 14 April 2004 10:52 am, Jim Fulton wrote:
packages become very unsttractive. It turns out that pkgutil will be
confused by the Zope package on Windows or Mac OS, adding it's directory
to the zope package's path. This is a bug in pkgutil that can be fixed,
but it is an example
On Wednesday 14 April 2004 10:45 am, Andreas Jung wrote:
For consitency: Zope.Products.
For lazy writers: Zope. X
I prefer the second solution...everyone should know what are products and
what
are packages. In fact the name does not matter because you can see in the
traceback
On Thursday 15 April 2004 10:23 am, Jim Fulton wrote:
(BTW, I think it was a mistake to have top-level persistent and
transaction packages. I think that will eventually come back to haunt us.)
I won't disagree with this. ;-(
The only way to avoid collissions is to pick stupid names
On Thursday 15 April 2004 13:22, Martijn Faassen wrote:
Note that for checking dependencies in Python code I still think this
tool could be improved by using technology from importchecker.py
...
which can use Python's compiler module to lift all imports from source
code, which I think is
On Friday 16 April 2004 01:31 pm, Michael Bernstein wrote:
From a consistency in nomenclature POV, I find 'z' jars a bit with
ZConfig, zdaemon, ZEO, zLog, and ZODB, which one might expect to find
nested within 'z' (as 'z.Config' for example). This is admittedly only
an issue for the
On Friday 16 April 2004 03:06 pm, Michael Bernstein wrote:
Shouldn't we strive for consistency in nomenclature going forward?
Definately. My point was that we don't have anything to base it on, not that
we shouldn't be.
Zope 3 kindly specifies some guidelines for naming, including module and
On Friday 16 April 2004 03:24 pm, Shane Hathaway wrote:
- Spelling it zOPE to take advantage of a frequent mishap involving
the cAPS lOCK key
That must be what happened for zLOG, and I declared that dead. I don't think
anyone's ready for that for Zope 3 just yet. ;-)
-Fred
--
Fred L.
On Tuesday 20 April 2004 01:22 pm, Andreas Jung wrote:
- the entries in the event.log are currently written without the log
level. Is this dedicated
behaviour? I think the log level should be part of the event.log
It should. This was lost when I changed the zLOG -- logging mapping, and
On Tuesday 20 April 2004 01:15 pm, Christian Heimes wrote:
Fred Drake wrote:
* Do I need to take care that the messages are logged into the event log
and on the console or can I safly use the logging package like::
...
zLOG has logged the messages to the console when zope was started
I wrote:
- In debug mode, add a new handler that dumps to standard output. This
is fairly easy to code, but is inflexible.
Andreas responded:
But flexible enough for most usecase. The point is that you want to see
the tracebacks on the console during the development phase. Watching the
On Wednesday 21 April 2004 04:48 am, Chris Withers wrote:
I'm guessing there is some kind of log-to-console logger already?
If so, why not just add that in zope.conf and comment it out when you move
to production?
That would work for me, but not everyone at ZC agreed, so I've made some
At a suggestion from the community, I've created a new mailing list for
ZConfig users. This is for general discussion and questions. The list is
run using Mailman at Zope.org; you can sign up at
http://mail.zope.org/mailman/listinfo/zconfig/
-Fred
--
Fred L. Drake, Jr. fred at
On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote:
cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
That should be:
svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
cvs co http://svn.zope.org/repos/Zope3/trunk Zope3
and this would be:
svn co
On Sunday 25 April 2004 01:00 pm, Jim Fulton wrote:
Oops. Thanks. I gues some habits will be hard to kick. :)
Yeah. Of course, CVS isn't just an old habit; it'll still be current
practice, not just for Zope 2.6.x and 2.7.x, but for lots of projects. The
general pain of two widely-used
On Saturday 24 April 2004 06:26 pm, Chris Withers wrote:
And there was me looking forward to writing a product that added its own
ZConfig section :'(
You still can if you like. ;-)
Okay, how can I get the log level and exception type into the subject?
That's not currently possible,
On Monday 26 April 2004 03:23 pm, Jim Fulton wrote:
2. Convert the mainline history, but leave off the branches.
This sounds good to me.
-Fred
--
Fred L. Drake, Jr. fred at zope.com
PythonLabs at Zope Corporation
___
Zope-Dev maillist -
On Wednesday 28 April 2004 04:01 pm, Lennart Regebro wrote:
Yes, but I'm pretty sure there are default settings for which files that
should be treated as binary on the server side in CVS. At least I rember
setting it up. :´)
Yes, this is specified in the CVSROOT/cvswrappers file.
-Fred
On Friday 30 April 2004 10:50 am, Chris McDonough wrote:
Is this improved at all by Fred's latest zZLOG-removal checkins? If
not, I will open a collector issue.
None of my changes have been applied to Zope 2.7; they only exist on the Zope
2 HEAD. The removal of zLOG is only for the Zope 3
On Friday 30 April 2004 12:25 pm, Lennart Regebro wrote:
Only that the Subversion people are wrong. Ad-hoc is not good enough. It
must be able to be configurable on the server.
Another possible approach would be to write a script to use for adds instead
of the default client; it could set
On Wednesday 05 May 2004 01:59 am, Jim Fulton wrote:
I'm thinking of trying again to do the cvs to svn conversion of the
main-line development branches (cvs heads) on Tusday May 11. This would
entail moving ZODB, Zope 2, and Zope 3 head development to subversion
(along with ZConfig,
Regarding putting more information in email's generated using email-notifier
sections, I wrote:
That's not currently possible, though it wouldn't be hard to add.
Perhaps some future ZConfig revision would add this.
On Wednesday 05 May 2004 05:41 am, Chris Withers responded:
Surely ZConfig
On Friday 07 May 2004 01:50 pm, Ken Manheimer wrote:
cvs.zope.org is wedged - you can connect to it (ping, web, ssh) but not
get any further. We've got a call in for attention, hopefully it'll be
back available soon...
Yay! It's working again! Ken, you're my hero. ;-)
-Fred
--
On Wednesday 26 May 2004 08:42 am, Philipp von Weitershausen wrote:
That works for me too, but please *above* the diff.
Yes; I should have been more clear and said *immediately* following the commit
message.
No, the CVS should stay in there to tell them apart, for the very same
reason you
On Thursday 01 July 2004 07:42 pm, Chris Withers wrote:
Is it still necessary to specify INSTANCE_HOME and SOFTWARE_HOME in the
start script for Zope?
I'm pretty sure I removed that requirement long ago, back when I added the
App.config module.
Or would the following work?
python
This hotfix product fixes a security bug in Page Templates. This fix
ensures that values substituted in named slots in translated elements
are properly encoded. If encoding is not desired and the source of
the replacement text is trusted, the structure modifier can be used
with the tal:content
This hotfix product fixes a security bug in Page Templates. This fix
ensures that values substituted in named slots in translated elements
are properly encoded. If encoding is not desired and the source of
the replacement text is trusted, the structure modifier can be used
with the tal:content
On Mon, 19 Jul 2004 09:48:00 -0700 (PDT), C. Olmsted
[EMAIL PROTECTED] wrote:
Not sure if this is quite the correct list to post to, but I'm having
trouble with Hotfix20040714. We're running zope 2.7, plone 2.0.3, and
zwiki 0.32.0.
Can you test with the 2.7.2 release candidate? This very
On Tue, 20 Jul 2004 10:40:22 -0700 (PDT), Cliff O.
[EMAIL PROTECTED] wrote:
Ok, so I just finished loading up 2.7.2rc1 and all seems well using the
same products and database as before. I can probably migrate the site
once 2.7.2 final is released but, of course, it would be great to apply
the
On Fri, 30 Jul 2004 11:50:57 -0400 (EDT), Ken Manheimer [EMAIL PROTECTED] wrote:
Accepted: Issues that some supporter(s) has responsibility for resolving
it, and it is not yet resolved.
Your description says that some supporter has assessed the
issue as
On Wed, 04 Aug 2004 10:24:30 +0200, Godefroid Chapelle
[EMAIL PROTECTED] wrote:
I would like to confirm that ZConfig keys are case insensitive and
that the corresponding attributes on the config object returned by the
'loadConfig' call are always lower case.
It sounds like I need to clarify
On Mon, 27 Sep 2004 14:18:30 -0400, Tres Seaver [EMAIL PROTECTED] wrote:
Transformation is already complete at that point. The only difference
is the type of the result returned (eventually) to the publisher.
Ok, that sounds good.
BTW, I looked again at where StringIO is used, and it seems
On Tue, 05 Oct 2004 12:44:32 +0200, Tino Wildenhain [EMAIL PROTECTED] wrote:
Well, the problem might be the asymptation part of the filename
should be considered an indicator of its contents.
That is a nuissance. It's unfortunate we still don't have any sort of
common type system for
On Tue, 05 Oct 2004 09:47:11 -0500, Evan Simpson [EMAIL PROTECTED] wrote:
This is part of my attempt to allow the various bits of ZPT to work
outside of Zope. It assumes that the presence of the 'Zope' module is a
reliable test. Perhaps this is a YAGNI, or perhaps there's a better way
of
On Tue, 05 Oct 2004 12:47:33 +0200, yuppie [EMAIL PROTECTED] wrote:
There are two annoying bugs that make the XML mode unusable for many tasks:
- http://collector.zope.org/Zope/1101 (i18n namespace broken)
- http://collector.zope.org/Zope/1474 (XML files opened in binary mode)
I would
On Tue, 05 Oct 2004 18:44:04 +0200, yuppie [EMAIL PROTECTED] wrote:
Ok. I'll remove that line in CVS/SVN.
Thanks!
I added a new comment to the issue. Hope that makes things clearer.
( http://collector.zope.org/Zope/1474 )
Ok; let's just say the discussion's moved there.
-Fred
--
Fred
On Sun, 17 Oct 2004 18:43:34 +0200, Andreas Jung [EMAIL PROTECTED] wrote:
Python 2.4 is still in alpha stage and there are no plans to support Python
2.4 in the short term.
It's in beta as of Friday evening; this would be a good time for
someone with time to start testing it with various Zope
On Mon, 18 Oct 2004 06:59:26 +0200, Andreas Jung [EMAIL PROTECTED] wrote:
Zope 2.7.3 + Python 2.4 fails when running the unittests:
Then a collector item should be filed. ;-) I don't know anything
about ThreadedAsync myself.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Zope
I'm proposing some (small) changes to the TAL specification. This
would result in a
new version of TAL for Zope X3 3.1 (and Zope 2.8 if anyone wants to backport the
relevant code changes).
The discussion will be on the ZPT list, where I've sent a copy of the
proposal. The
proposal is also
On Thu, 28 Oct 2004 11:07:52 +0200, Radoslaw Stachowiak
[EMAIL PROTECTED] wrote:
Could anyone please provide me information when ZopeInterface product is
going to be updated ?
And how is it related to zopex3 releases ?
I'm planning to release a final version around the time that Zope X3
3.0.0
On Mon, 31 Jan 2005 19:25:15 +0100, Lennart Regebro [EMAIL PROTECTED] wrote:
Note that diskussions about the Zope2 + Zope3 pagetemplate issue arrived
in the conclusion that, the faster we can get Zope3 pagetemplates back
ported to Zope2, the happier we will be. ;) I have no idea if that is a
On Mon, 14 Feb 2005 15:22:38 -0200, Leonardo Rochael Almeida
[EMAIL PROTECTED] wrote:
It's obvious that the container-class directive is being evaluated
much earlier than the products directive. Without delving further into
the code, it looks like the container-class directive has an error
On Mon, 14 Feb 2005 18:41:20 -0200, Leonardo Rochael Almeida
[EMAIL PROTECTED] wrote:
Should I bother with the collector entry or is it a known limitation no
one is going to bother with? :-)
It's not a bad idea to file a report in the collector. While I've no
plan to change it myself, that's
On Mon, 21 Mar 2005 10:54:11 -0500, Andrew Langmead
[EMAIL PROTECTED] wrote:
I haven't tried the
latest version of Parrot, but I'd think that Zope would be the last
thing that will run successfully.
I don't know that Parrot tries to emulate Python's C API either, and
Zope definately contains
On 5/9/05, yuppie [EMAIL PROTECTED] wrote:
But I still believe it was wrong to change the 'inet_address' datatype
in ZConfig.
I spoke with Tim about this briefly today, and I can't remember the
reasons for some of the relevant changes. I suspect at this point
that putting less magic in the
On 6/10/05, Paul Winkler [EMAIL PROTECTED] wrote:
Mind if I check in text-only changes to the 2_8 branch?
It's still Friday for Andreas, so this is a good time!
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Zope Corporation
___
Zope-Dev
On Fri, Jun 10, 2005 at 02:21:32PM -0400, Paul Winkler wrote:
Done. Like I said, just trivial docs typos.
Yeah, but improvements are improvements!
On 6/10/05, Paul Winkler [EMAIL PROTECTED] wrote:
While I'm at it, anybody object to the attached patch to
doc/FAQ.txt ?
I don't see a need to
On 6/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote:
Gosh, that looks too nice to be true. I will try that out tomorrow and
write out a how-to on zope.org if it works out.
It is too good to be true; sorry.
Well, it is true, but it's not what you're looking for. You can't use
it to extend the
On 7/1/05, Chris McDonough [EMAIL PROTECTED] wrote:
FWIW, I don't know if it helps at all, but there's a concrete example of
allowing a 3rd-party product to add a section to zope.conf via %import
in the ClockServer product at
http://www.plope.com/software/ClockServer/ . It sounds from your
On 7/1/05, Jens Vagelpohl [EMAIL PROTECTED] wrote:
That just has the disadvantage that you're increasing the number of
configuration files to maintain in an instance. If it's imported and
used in zope.conf at leaast there's just one file to deal with...
This is true. Is that really important,
Hey all,
I'm working on a revised build process for Zope 2.9, based on the work
that we've done for Zope 3. What this means is that we'll have a
setup.py that uses the code from zpkg
(http://www.zope.org/Members/fdrake/zpkgtools/) to load metadata from
the various packages are part of the
On 9/30/05, Paul Winkler [EMAIL PROTECTED] wrote:
One thing Tino suggested: it might be a firewall issue.
Does svn's externals-fetching look somehow different to a firewall
than does a regular (non-external) checkout?
When I tried checking out on my laptop, I noticed that ZoneAlarm asked 'me
On 9/30/05, Paul Winkler [EMAIL PROTECTED] wrote:
Hypothesis:
Is it possible that svn.zope.org is configured such that when you get
the externals, it uses plain svn (i.e. an anonymous checkout)
rather than svn+ssh?
As noted, very likely. The default port for SVN w/out SSH is 3690:
[It doesn't look like my response went to the zope-dev list; re-sending.]
On Tuesday 18 October 2005 15:43, Tim Peters wrote:
I'm copying Fred because he may remember more about this than I do.
Fred, do you know of a reason why I can't stitch a newer ZODB into
Zope(2) trunk? I have a dim,
On 11/5/05, Tino Wildenhain [EMAIL PROTECTED] wrote:
The usual setup.py from distutils to make it more pythonic.
The install.py in the root of the distribution is actually a
conventional setup.py. Would it be helpful to keep the setup.py name?
We renamed it to encourage the configure/make
On 11/5/05, Jim Fulton [EMAIL PROTECTED] wrote:
It's main benefit is that it leverages a familiar pattern, but
I'm not convinced that it's worth it. Also, as tools like rpm and
deb become more widely used, I'm not sure how familar the configure/make
dance is. Other than Python and Zope, I
On 11/23/05, Lennart Regebro [EMAIL PROTECTED] wrote:
Basically, I'd like to create a site once, and use it for all
subsequent tests, until I made a change that means the site needs to
be recreated. But how? Well, I'm not sure. How, for example, could I
Jim's new test runner includes support
On 11/23/05, Stephan Richter [EMAIL PROTECTED] wrote:
Using this group, we have about an 80-90%
-1 vote count.
I'll weigh in with a -1 as well, for all the reasons cited by the
other -1 voters on this issue. Zope 2 and Zope 3 are far too
different at this point. The only way I see for
On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote:
I have some product that would greatly benefit from being able to be
configured from within zope.conf. I don't want a separate
configuration file. Period.
Tres Seaver and I implemented this during the Goldegg sprint in
Fredericksburg, which
On 11/30/05, Sidnei da Silva [EMAIL PROTECTED] wrote:
I haven't seen this being checked in at all, maybe it's in Tres
laptop?
These were committed to the trunk before the 2.9 branch was created:
r39652 | tseaver |
On 12/1/05, Chris Withers [EMAIL PROTECTED] wrote:
In this case, I think zopeschema.xml should be documentation enough,
especially as any product author wanting to use this feature is going to
have to write a component.xml at least ;-)
Actually, a product author isn't required to write a
On 12/19/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Now I see what you mean by contract. You're right, I guess it isn't
documented then, but
perhaps it should be.
That's never been part of the contract and, as Tres notes, it's
inconsistent. The implmentation will only sort when
On 12/21/05, Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:
My point is: I don't think there's anything wrong in the install
procedure being different between the checkout and the tarball, but it
should never take more than a couple of fixed (and documented) steps to
convert a checkout to a
On 12/22/05, Andreas Jung [EMAIL PROTECTED] wrote:
Jar files have no dependencies.
Well, I know you know what you mean here, but I'll elaborate since the
kids haven't started fighting yet this morning. :-)
Jar files don't have dependency metadata. They're pretty much
equivalent to zipped
On 1/9/06, Andreas Jung [EMAIL PROTECTED] wrote:
ZODB defines these levels but I can not see any code in the ZODB package
that actually uses these levels.
Nobody should be using the zLOG levels with the logging package, but
rather use the logging package levels. So in the end, there's no need
On 1/9/06, Florent Guillaume [EMAIL PROTECTED] wrote:
My point is that the python logging levels are insufficiently fine
grained.
The python logging framework leaves room for numeric levels and
registering equivalent strings, and indeed ZODB and zLOG have them
defined.
I want to use them.
On 1/17/06, Tino Wildenhain [EMAIL PROTECTED] wrote:
Add to it the fact the zpt@zope.org was due to be retired
anyway ;)
Though retirement for the list was discussed, it was decided not to
retire it since it was still the best place for implementors to
discuss matters. The implementations in
On 1/18/06, Jim Fulton [EMAIL PROTECTED] wrote:
If eggs work out, as I hope they will, I'd like to stop work on
zpkg and just use eggs.
+42
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
There is no wealth but life. --John Ruskin
___
Zope-Dev
On 2/16/06, Chris Withers [EMAIL PROTECTED] wrote:
To be clear: I'm talking _only_ about merging the dev lists, _not_ the
user lists. The users lists are still largely independent, but it seems
like just about every post to the dev list now has a bearing on both
Zope 2 and Zope 3, especially
On 3/24/06, Jim Fulton [EMAIL PROTECTED] wrote:
We've had sucess writing XSLT templates to transform the pickle data
into formats easily parsable for particular applications.
As part of a recent task (likely the same one Jim's referring to
here!), I transformed the XML export into another XML
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree),
and I'm not the first. I've created a feature development branch for
this, and checked in my initial implementation.
I've modified the existing code to use PY_LONG_LONG instead of int for
the key and/or value type; there's no
On 4/17/06, Jim Fulton [EMAIL PROTECTED] wrote:
The fact that IIBTrees is so widely used is exatly the reason
I want to use 64-bits for the existing types rather than having to
introduce a new type.
Oops, I was checking in the separated version of 64-bit BTrees while
this was landing in my
On 4/13/06, Fred Drake [EMAIL PROTECTED] wrote:
I've created a feature development branch for
this, and checked in my initial implementation.
I've made another branch for this, with a different twist. I'm not
sure it'll be interesting, but I think it'll solve my immediate need
until I can get
On 5/15/06, Sidnei da Silva [EMAIL PROTECTED] wrote:
Also on a similar subject, running 'make install' from a checkout only
copies packages that have a 'SETUP.cfg' inside. Is that intentional?
I thought someone was in charge of fixing the 'make install' dance.
Someone might be, and it might
On 5/15/06, Sidnei da Silva [EMAIL PROTECTED] wrote:
I was looking at zpkg for the first time today, and was sorry to
realize it won't run to completion on a Windows machine due to some
minor use of os.WIFEXITED which is due to a dubious use of the 'tar'
command, since Python has a 'tarfile'
On 5/25/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
I think they do pretty much the same thing (but I could be mistaken).
Are they interchangeable? If not, are they compatible so that we just
add both ways to both files? If they're not compatible, which one should
we use in the
On 12/17/06, Christian Theune [EMAIL PROTECTED] wrote:
Nope, not yet. I don't have any plans for Zope 2, but I'll be working on
the Zope 3 side.
...
- Make the existing File implementation use blobs
This would be good so people see how to use them and get blobs widely
exposed. Ideally,
On 12/18/06, Christian Theune [EMAIL PROTECTED] wrote:
a) provide a generation to convert old data structures
Since we tend to work with high-availability issues at ZC, I'm
hesitant to go this route; expensive generations that affect large
portions of a database can be very difficult to run
On 1/10/07, Dieter Maurer [EMAIL PROTECTED] wrote:
*It* must be informed whenever it is used in a different thread.
Perhaps it could use some thread-local data to keep track of this?
threading.local comes to mind.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Every sin is the result
On 3/1/07, Martin Aspeli [EMAIL PROTECTED] wrote:
Sets may turn out to be *sorted* if they're implemented with trees, but I
don't think the implementation promises that either.
The BTrees implementation definitely does promise the sorting
relationship for the results of iteration, which is
On 10/15/07, Chris Withers [EMAIL PROTECTED] wrote:
I'm pretty sure automated bug expiry is a very bad thing.
Agreed; it's completely unhelpful.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote:
A common issue we are seeing is that we have eggs depending on each
other, but they still need to load the zcml from those dependencies
somehow. As a temporary solution to play with the concept I added
something simple to the
On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote:
The main win, IMHO, is to avoid the requirement for people to install
slugs for third party products. Slugs suck - they are confusing to
explain and people forget them all the time. Buildout makes it a bit
easier, but it's still not a
On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote:
Right - but you're building an application, and you're pretty
experienced with Zope. A lot of Plone users just want to install a
plug-in (a product), basically. Before, they just dropped it into a
It sounds like your concerns center around
On 10/27/07, TIm Terlegård [EMAIL PROTECTED] wrote:
When using zc.buildout I discovered that it installed a part that I
didn't
specify in the 'parts' option. This happened because I referenced this
part somewhere else. Is this how it's supposed to be? I would prefer
if it
only installs the
1 - 100 of 226 matches
Mail list logo
