Martin Aspeli wrote:
Jim Fulton wrote:
I'll make some small comments below, but I want to make a big
comment to start. Zope 2 and Plone are both examples of
extensible applications. In my note, I was trying to make the
point that I think such applications have value. I'd like to
see them
Andreas Jung wrote:
Hi,
because Zope 2.10.2+ will use unicode as internal representation for
page templates I am currently checking the options to get rid of
UnicodeDecodeErrors for Zope 2.11 by providing some more intelligent
conversion of non-unicode content. Basically I want if the content
Hi there,
We had a Grok sprint in Germany over the weekend, and we got two reports
about it:
Jan-Wijbrand's report:
http://jw.n--tree.net/blog/dev/python/second-grok-sprint
And mine:
http://faassen.n--tree.net/blog/view/weblog/2007/01/09/0
Regards,
Martijn
Martin Aspeli wrote:
Martijn Faassen wrote:
We had a Grok sprint in Germany over the weekend, and we got two
reports about it:
Rock on :)
What is the current state of the art in terms of Grok examples and
documentation? What is the best place to look to find out about the
latest
Martin Aspeli wrote:
Martijn Faassen wrote:
Hi there,
We had a Grok sprint in Germany over the weekend, and we got two
reports about it:
Rock on :)
What is the current state of the art in terms of Grok examples and
documentation? What is the best place to look to find out about
Martin Aspeli wrote:
Peter Bengtsson wrote:
Philipp has posted a blog entry with a good example of Grok code:
http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn
Gorgeous!
I especially like that you don't have to manually define the template
since
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
- Don't invent a new code generator. Please. :) PasteScript does
quite well, and seems to be adopted by others, e.g. Pylons. We
already use it to make new egg-like packages for Plone.
Agreed. We're looking into PasteScript, I believe
Andreas Jung wrote:
[snip]
[Bernd Dorn]
IMHO it should only accept strings, because in the value should be a xml
string and therefore always has to be encoded in 'utf-8' or in the
encoding specified in the processing instruction.
I disagree with that. Since Zope 3 is supposed to use unicode
Philipp von Weitershausen wrote:
[snip]
A workaround inside parseString() would to check for unicode
and convert the string on-the-fly to a Python string with utf-8 encoding.
This is possibly a limitation of the underlying Expat parser...any
recommendation how to deal with this issue?
Fixed
Hey,
Gmane isn't updating so I can't really reply to the message (not visible
in gmane) that I want to, but I saw the following solution proposed:
def ourparse(text):
if isinstance(text, unicode):
text = text.encode('UTF-8')
xml_parser.parse(text)
now consider what will happen if
Hey,
On 1/15/07, Andreas Jung [EMAIL PROTECTED] wrote:
[snip]
ok, got it. But this problem can be solved easily by changing the encoding
within the preamble.
I would say refusing to guess and bailing out with an error message is
better in this case. The Zen of Python:
In the face of
Chris Withers wrote:
Philipp von Weitershausen wrote:
u'?xml version=1.0 encoding=something-else?node /'
What should be done then?
Not sure. We could ignore it or raise an error. I'm inclined to ignore
it.
That's what I do too...
See my post elsewhere in the thread for an example of why
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
--On 14. Januar 2007 18:14:45 + Chris Withers [EMAIL PROTECTED]
wrote:
Dieter Maurer wrote:
A halfway intelligent parser would accept Unicode when it gets it
and concentrate on the remaining part of
Andreas Jung wrote:
--On 15. Januar 2007 15:44:01 +0100 Martijn Faassen
[EMAIL PROTECTED] wrote:
On 1/15/07, Andreas Jung [EMAIL PROTECTED] wrote:
[snip]
ok, got it. But this problem can be solved easily by changing the
encoding within the preamble.
I would say refusing to guess and bailing
Tres Seaver wrote:
[snip]
Unicode XML is not only problematic for streaming. For instance, you
*can't* pass a Unicode string to the libxml2 *at all* , unless you want
a core dump. The API requires that you pass it strings encoded as UTF8.
You can in lxml. :) libxml2 as a C API doesn't even
Andreas Jung wrote:
--On 15. Januar 2007 22:15:46 +0100 Martijn Faassen
[snip]
I still don't see what should ambiguous with this approach.
Ambiguous in that the string seems to say it's in two encodings at once.
You're then guessing: you're letting the Python string type trump
Dieter Maurer wrote:
Martijn Faassen wrote at 2007-1-15 15:44 +0100:
Hey,
On 1/15/07, Andreas Jung [EMAIL PROTECTED] wrote:
[snip]
ok, got it. But this problem can be solved easily by changing the encoding
within the preamble.
I would say refusing to guess and bailing out with an error
Tres Seaver wrote:
[snip]
The just store the XML scenario is in surprisingly nice. It only needs
attention to encoding and decoding in the always complicated ZPublisher
direct output scenario, and in the edit form scenario.
As you speculated, this is actually my preference, except that I
Andreas Jung wrote:
I am replying to the three proposals. First I have to kick the proposal
of Tres (UTF-8 storage). We want unicode as internal representation for
any kind of ZPT (both text/html and text/xml).
I'm not sure I understand this. Wouldn't the internal representation be
unicode
Marius Gedminas wrote:
On Thu, Jan 18, 2007 at 08:55:17AM +, Chris Withers wrote:
Marius Gedminas wrote:
BTW passing interfaces to provideAdapter/adapts is out of fashion.
This stuff is getting almost perl-ish in it's there's many ways to do
it, pick the style you like nature..
There's
Marius Gedminas wrote:
[snip]
Also, I'd like a way to specify the adapter name in the adapter class.
Something like
from zope.interface import implements
from zope.component import adapts, named
class MyNamedAdapter(object):
adapts(IFoo)
implements(IBar)
Philipp von Weitershausen wrote:
Marius Gedminas wrote:
and which causes registration as an adapter without the need for ZCML.
I am not sure I like that. When does the registration take effect? On
module import?
No, that would be quite terrible. It would mean you could never import
Hey,
Dominique Lederer wrote:
a week ago i posted this (
http://mail.zope.org/pipermail/zope3-users/2007-January/005348.html) at
the Zope3-users mailinglist, but got nearly no response. Maybe here i
get more attention :)
I will post my questions again, if you could spare some time, please try
Jim Fulton wrote:
Platform dependent distributions are *not* portable. They can depend on
system settings, such as Python Unicode size and library locations.
This can cause major annoyance and breakage when people automatically
download these with easy_install or zc.buildout.
Yeah, the
Hello,
Adam Groszer wrote:
I'd like to ask your opinion, your experiences about searching and
filtering in quite large object DBs.
We need to add search and filter functions to our current app, where
the user might be able to create quite _sophisticated_ filter criterias.
(The app is a pure Z3
Hi there,
I saw Andreas Jung checked in z3c.sqlalchemy. Cool! Some questions though:
* how is this different from zalchemy?
* I see it uses ZopeTestCase, while it appears to be pure Zope 3 code
otherwise, at least at first sight (and because of the package name).
Why is this done?
* The
Hey Jim,
On 3/27/07, Jim Fulton [EMAIL PROTECTED] wrote:
[snip]
After
that I thought we were actually going somewhere with this discussion,
but you now strengthen this impression by apparently giving up in
exasparation. That is what is making *me* slightly exasparated. :)
Fine. I gave up
Wichert Akkerman wrote:
Previously Uwe Oestermeier wrote:
Martijn Faassen [EMAIL PROTECTED] schreibt:
Now I'm hoping I'm missing some kind of strategy and perhaps someone
will have a luminous idea to make this work without the creation of a
separate index. Or if not, at least I can give up
Hey Christian,
Christian Theune wrote:
Am Mittwoch, den 28.03.2007, 01:12 +0200 schrieb Martijn Faassen:
[snip]
Quick shot on integrating the suggestion from Uwe:
- Reserve an OID from the ZODB storage, maybe create a 'shadow' object
in the ZODB.
- Use a directory that maintains a hard
Christian Theune wrote:
[snip]
Right. I'm not sure whether I missed anything, but I don't quite have
your whole use case on my radar.
The use case is basically that people can use Zope 3 off-line, working
on an SVN checkout. They then commit (through a UI) their changes, and
resync with the
Gary Poster wrote:
The work that Jim Washington and David Pratt have started recently to
make lxml an XHTML generator/ZPT replacement [#1]_ has really excited
me. It would be *great* with in-Zope pipelines [#2]_.
A general +1() for this whole effort!
I have been having some thoughts
Jim Fulton wrote:
Recently, I've been working on a project that uses twisted. I created
a distribution of twisted that installs with easy_install and buildout.
The project name is zc.twisted and the distribution can be found at:
Hi there,
I just tracked down what I believe is a bug in the Zope 3 page template
engine. I didn't know it was a bug in the Zope 3 page template engine as
I was tracking down a bug in Silva with Zope 2.10, which of course uses
the Zope 3 page template engine. For the proposed solution, see
Fred Drake wrote:
On 4/20/07, Martijn Faassen [EMAIL PROTECTED] wrote:
No, the current expectation is that it works, whatever the replacement
is. This currently works in Zope 2.8:
You'll need to explain how silently dropping the tal:attributes on the
floor was ever it works.
Sorry about
Fred Drake wrote:
On 4/20/07, kit BLAKE [EMAIL PROTECTED] wrote:
But those attributes *do* work. If you call that image without the
attributes, it won't have a title attribute. If you keep the tag as it
is, it will have a title attribute.
This is some pretty freaky behavior for page
kit BLAKE wrote:
2007/4/19, Martijn Faassen [EMAIL PROTECTED]:
Hi there,
I just tracked down what I believe is a bug in the Zope 3 page template
engine. I didn't know it was a bug in the Zope 3 page template engine as
I was tracking down a bug in Silva with Zope 2.10, which of course uses
Hey,
Anyone, can I conclude that z3c.widget is not available anywhere? Who
would like to upload a version? Can I help? Where shall we upload it?
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
Max M wrote:
Martin Aspeli skrev:
If you're talking about ArchGenXML, which generates AT code from UML,
it's
not too bad. The code it generates is pretty clean, and if you decide to
abandon code generation, there's a minimum of cruft (mostly a few comment
blocks) that you can remove if you
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
Hey,
Leonardo Rochael wrote:
[snip]
So, perhaps, we don't need powerful zcml overrides, just cooperative package
maintainers (of which we have plenty in this community).
Interesting to see some of my ideas for Grok make it back here. :) After
your mail I realize now that with ZCML you can do
Tres Seaver wrote:
[snip]
One example of such an implementation would be an optional, lxml-based
directive which uses the native structure of the ZCML file and XPath.
E.g. to include only adapters from a package ::
select package=my.package file=configure.zcml
path//adapter//path
/select
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Tres Seaver wrote:
[snip]
One example of such an implementation would be an optional, lxml-based
directive which uses the native structure of the ZCML file and XPath.
E.g. to include only adapters from
Jim Fulton wrote:
On May 4, 2007, at 6:25 AM, Baiju M wrote:
...
We will be using same Zope 3 resources for bug tracking, mailing list
and wiki for these satellite project's, is it ?
Thanks a very good question. I don't think we need more mailing lists.
In fact, I think zope3-dev and
Benji York wrote:
Christian Theune wrote:
Same here. I'm feeling like I'm not yet understanding what the trunk
will be used like.
I'm wondering if we need to maintain a Zope 3 project with any code in
it at all (or nearly so). Could Zope 3 just be a buildout with a
configuration that
Hi there,
I thought I should mention here that the EuroPython talk deadline is
fast approaching - the proposal deadline is friday may 18. I would like
to see a strong Zope presence at EuroPython, so please submit your Zope
related talks! Note that you won't be alone. If our talks are
Chris Withers wrote:
Fred Drake wrote:
[snip]
The value of the big release is more for people who are new to Zope 3,
and want to take a look. That's not an audience I'm good at judging,
either in terms of guessing what they really want, or in what makes
them take that first look.
Indeed,
Hi there,
Tomorrow (friday may 18) is the EuroPython talk submission deadline!
So if you are thinking about giving a talk at EuroPython, please
submit it soon!
http://www.europython.org/
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Hey,
Jim Fulton wrote:
I'm finally looking closely at Blobs and making a few changes. Some of
these are backward incompatible. Most are inconsequential. Since Blobs
are still considered experimental, I feel fairly free to do this, but I
don't want to create undue pain for people.
I will
Marius Gedminas wrote:
[snip the problems with system pythons]
seem to be minor inconveniences rather than show-stoppers to me. I'd
love to hear real horror stories.
Not sure whether this counts as a horror story, but...
Recently I upgraded my desktop to Ubuntu Feisty.
So I was running this
Hi there,
Recently I had the opportunity to try the new buildouts of two Zope 3
projects, namely zope.tal and zope.fssync. In both, the dependency
specification in install_requires looks innocent:
zope.tal:
'setuptools',
'zope.i18nmessageid',
'zope.i18n',
'zope.interface',
zope.fssync:
Hey,
Christian Theune wrote:
[snip]
I can't remember who I talked to about this who pointed out to me that,
in most cases, you don't have to care about the `default` folder and can
put the utilities that you don't want in content space just directly
into the site manager.
I think we discussed
Wichert Akkerman wrote:
Previously Christian Theune wrote:
Am Mittwoch, den 15.08.2007, 14:15 +0200 schrieb Christian Theune:
Hi,
I saw the error reports about zope.security and got talked to from a few
people that they had severe problems managing around this. I removed the
3.4b4
Christian Theune wrote:
Hey,
Am Mittwoch, den 15.08.2007, 14:15 +0200 schrieb Christian Theune:
Hi,
I saw the error reports about zope.security and got talked to from a few
people that they had severe problems managing around this. I removed the
3.4b4 distribution from download.zope.org to
Jim Fulton wrote:
[snip]
Just ran into this one. I think removing it is the right decision. b2
did work for me, but b4 just broke on me.
Try b5.
I'd love to try the mysterious b5, but it's just not there. :)
Regards,
Martijn
___
Zope3-dev
Christian Theune wrote:
Am Mittwoch, den 15.08.2007, 17:52 +0200 schrieb Martijn Faassen:
Wichert Akkerman wrote:
Previously Christian Theune wrote:
Am Mittwoch, den 15.08.2007, 14:15 +0200 schrieb Christian Theune:
Hi,
I saw the error reports about zope.security and got talked to from
Hi there,
I don't have any Windows knowledge, so my ability to review Roger's
changes to add (much needed!) windows support to z3.zope3recipes is
limited.
I do however notice that an entire doctest was more or less copied
verbatim: README.txt got copied to WINDOWS.txt. The Windows version
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
I don't have any Windows knowledge, so my ability to review Roger's
changes to add (much needed!) windows support to z3.zope3recipes is
limited.
I do however notice that an entire doctest was more or less copied
verbatim: README.txt
Hey Roger,
Roger Ineichen wrote:
[snip]
Was the original way to run Zope 3 trunk dependent on win32api?
I guess, but I'm not sure;
Python 2.5 includes ctypes which could be used as a
replacement for the win32 part.
I am fine with requiring win32api, though it'd be better if it were
indeed
Stephan Richter wrote:
it has been over a year, since we had a conference-independent fully Zope 3
focused sprint. And I think it is time to have one! :-)
If you ignore the two Grok sprints we've had in september and january
then that's indeed true. :)
Regards,
Martijn
Hey,
On 8/17/07, Sidnei da Silva [EMAIL PROTECTED] wrote:
On 8/17/07, Martijn Faassen [EMAIL PROTECTED] wrote:
I am fine with requiring win32api, though it'd be better if it were
indeed installable from the python package index. Otherwise you need to
tell people to install two things
Hey,
Does this mean the package won't get removed? I just prefer to use a
situation where I don't get the broken egg in the first place.
You're hosed, then: people are going to release eggs which break
downstream applications (think libs in Debian unstable). Until we
segreate the known
Benji York wrote:
Darryl Cousins wrote:
On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote:
I think my next step is to fix some dependencies for Grok to hard
version numbers...
I think that this is a good thing. I recently gave myself quite a bit
grief with a careless bin/buildout
Adam Groszer wrote:
Monday, August 20, 2007, 3:05:45 PM, Stephan Richter wrote:
Windows is pretty different in this respect. You really want to use an
installer, which means you get a wizard. People in Windows expect this
behavior and want it. It is quiet ignorant to ask them to use eggs
Stephan Richter wrote:
On Friday 17 August 2007 17:32, Gary Poster wrote:
However, it's worth noting to clarify this discussion that buildout
is being successfully used to install a wide variety of software on
*nix systems (I know of Red Hat, Ubuntu, and OS X). This includes
software that
Hey,
Thanks for noticing. I think we need to adopt a routine of building
Windows eggs whenever we make a new release of a package that has C
extensions. There aren't that many packages like that (about a dozen)
and they hopefully aren't going to have that many releases in the future.
I've
Benji York wrote:
Martijn Faassen wrote:
It would be nice if one could install Zope 3-based *applications*
using a Windows installer. But to ask developers to install all the
*library* dependencies separately using click-through wizards is
rather strange.
As a recovering Windows developer
Hey,
On 8/20/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
On 20 Aug 2007, at 18:48 , Martijn Faassen wrote:
[snip]
How solid are MinGW eggs?
So far nobody can tell me, except that Andreas Jung, Hanno
Schlichting and a couple of other guys seem to be able to use MinGW
well
Hey Benji,
Thanks for this suggestion (the downloadable versions.cfg). I was
thinking in the same direction after Jim briefly mentioned this
possibility.
For the Grok 0.10 release earlier this week I went with hardcoding it
in setup.py (where necessary) to make sure it at least worked on
Markus Leist wrote:
I want to pay Martijn Faasen a compliment for the grok-workshop this
last weekend in St. Augustin, Bonn, Germany.
With (t)his grok-view he builds a very informative and enjoyable bridge
to zope3 and all its capabilities.
Thank you and all the other Zope3-developers very
Hey,
A few months ago I voiced concerns about Python 3000 breaking existing
codebases and fracturing the community as a result. Various people in
the community landed on me like a ton of bricks. It wasn't fun.
I think Zope will be on Python 2.x for many years to come. That will
give Zope a
Hey,
Andreas Jung wrote:
[snip]
I am basically speaking here for the Zope 2 world. If we move core
components to Python 3000 we have to move the complete Zope 2 core to
Python 3000 which will cause a huge disaster because of almost every
third party component is likely to break. This is a big
Hey,
David Pratt wrote:
Ultimately, the
folks that will even want to maintain a 2.x code base will quickly erode
since the forefront of development is never the past. Perhaps it will
all move more quickly for this reason when python 3K is out for real.
This is what I fear will happen.
Hey,
But we cannot officially support Python 2.5 until Zope 2 is also ported.
(This is a policy of Zope Foundation, I guess)
Just to make it clear: the Zope Foundation itself never made a decision
on this. In general, the Zope Foundation is not making development
decisions. This was a
Hi there,
I see today a zope.lifecycleevent 3.4.0 was released to the cheeseshop
(but not to download.zope.org/distribution).
Unfortunately it seems to break when I install it into my buildout, with
the following error:
Running easy_install:
/home/faassen/bin/python2.4 -c from
Stephan Richter wrote:
On Saturday 01 September 2007 15:33, Martijn Faassen wrote:
I think Zope will be on Python 2.x for many years to come.
I really hope not. A friend of mine and I want to get a bit involved in Python
3000 once it is stable enough that the standard libs can get some
Hermann Himmelbauer wrote:
Am Samstag, 1. September 2007 13:11 schrieb Andreas Jung:
--On 1. September 2007 16:33:58 +0530 Baiju M [EMAIL PROTECTED] wrote:
Andreas Jung wrote:
--On 1. September 2007 16:00:19 +0530 Baiju M [EMAIL PROTECTED]
wrote:
I currently don't see how a smooth
Hey,
Tres Seaver wrote:
[snip]
Frankly, I'm uninterested in spending *any* effort on Py3K support:
we'd be more likely to get traction out of Jython / IronPython (which
are alreday stable, and run on platforms we don't yet support).
More far-fetched but still in some ways more in reach than
David Pratt wrote:
Yes these are all fairly painful scenarios. What's worse is the scenario
for organizations evaluating zope end user software using python 2. It's
will not be a great selling feature to start with the premise that
anything you see today will require major refactoring to give
Hey,
On 9/3/07, Hermann Himmelbauer [EMAIL PROTECTED] wrote:
Am Montag, 3. September 2007 13:25 schrieb Martijn Faassen:
[snip]
Well, I personally don't have good experiences with automatic code conversion
tools. Most often I had to manually edit the source. It may work in simple
cases where
Martin Aspeli wrote:
Lennart Regebro wrote:
I'm hoping that Guido will see the errors of his ways, and introduce a
Python 2.7 that has more forwards compatibility than what has been
promised for 2.6, so that there can be a useable overlap between
Python 2.7 and 3.0. Maybe a 3.1 with some more
Martin Aspeli wrote:
Paul Winkler wrote:
On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote:
Has there been a strong statement that there won't be a Python 2.7
and beyond? Will Python 2.x be actively killed off?
Quite the opposite, Guido proposed last year to do 2.7, 2.8, and 2.9.
Paul Winkler wrote:
On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote:
Has there been a strong statement that there won't be a Python 2.7 and
beyond? Will Python 2.x be actively killed off?
Quite the opposite, Guido proposed last year to do 2.7, 2.8, and 2.9.
After that it's not
Reinoud van Leeuwen wrote:
On Tue, Sep 11, 2007 at 10:29:58AM +0200, Martijn Faassen wrote:
Paul Winkler wrote:
On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote:
Has there been a strong statement that there won't be a Python 2.7 and
beyond? Will Python 2.x be actively killed off
Hey,
David Pratt wrote:
[snip]
Communication with the core python team on impacts could create a
cohesive strategy for the future and improve buy-in if there can be
agreement on how to move forward.
While I fully agree, my one (accidentally started) communication with
the core Python team
Paul Winkler wrote:
On Tue, Sep 11, 2007 at 12:49:23AM -0400, Paul Winkler wrote:
On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote:
Has there been a strong statement that there won't be a Python 2.7 and
beyond? Will Python 2.x be actively killed off?
Quite the opposite, Guido
Hey,
Thanks for the write-up. This needs some thinking. I will bring this up
on the board, too.
As a general point: the foundation board is happy to appoint someone as
its official representative in this and back them up where needed, but I
think it's unlikely at this point we'll be having
Hi there,
One of the issues I see is that we have two kinds of views - the ones
used to construct the ZMI, and special views, such as AbsoluteURL.
Simply making it possible to include the component registrations without
the browser registrations would also mean those special views don't get
Hi there,
From z3c.form's subform.txt:
Final Note: With ``zope.formlib`` and ``zope.app.form`` people usually
wrote complex object widgets to handle objects within forms. We never
considered this a good way of programming, since one looses control over
the layout too easily.
I then looked
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
Hey,
On 9/25/07, Dieter Maurer [EMAIL PROTECTED] wrote:
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
Hey,
Jim Fulton wrote:
In any case, you should probably raise this issue on the distutil-sig list.
/me goes to get popcorn.
I hope you have your popcorn ready:
http://mail.python.org/pipermail/distutils-sig/2007-September/008291.html
and here is a blog entry going into the reasoning
Stephan Richter wrote:
On Wednesday 26 September 2007 04:16, Christian Theune wrote:
The whole list of things that might be relevant here is:
- zope.securitypolicy
- zope.session, zope.app.session
- zope.app.authentication
- zope.app.i18n
- zope.i18nmessageid
- zope.app.applicationcontrol
-
Marius Gedminas wrote:
People make mistakes. Can we reduce the number/severity of those
mistakes by creating a Python script to automate the release process as
much as possible?
[snip]
I'd be happy to work on such a script during the sprint, if someone
could help me figure out what exactly
Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.
There is conflicting
Hey,
On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
[snip]
What about using CHANGES.txt, which we should be maintaining anyway?
[snip]
These are very good points. My guide [1] already recommends this practice.
[1]
http://svn.zope.org/*checkout
On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
Hey,
On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
[snip]
What about using CHANGES.txt, which we should be maintaining anyway?
[snip]
These are very good points. My guide [1] already
Jim Fulton wrote:
I'm not too keen on trying to automate this with a Python script. I
suggest we start with a human script. I think Philipp has a start at
this. Philipp, could you remind
us where this is? I suggest we review it and then post it prominately
somewhere that people (I) can
Stephan Richter wrote:
[snip]
Doing another checkout of the tag
will create a significant overhead to the release process of a package.
I'd like to highlight this. We need to be careful we don't increase
release overhead too much, otherwise it won't happen/people will make
mistakes.
Hey,
My opinions:
It'd be nice if getMultiAdapter's functionality was in reach without
typing: import zope.component; zope.component.getMultiAdapter. The
IFoo() single adapter lookup shows us a way to make this possible: a
method (in this case __call__ on the interface). It does bother me on
Hey,
Marius Gedminas wrote:
[snip]
+1 for CHANGES.txt (or NEWS.txt) in a separate file from README.txt
+1 for the latest changelog entries visible on the cheeseshop page (see
an announcement, go to cheeseshop, see whether you want to upgrade or
not)
+1 for README.txt and CHANGES.txt available
301 - 400 of 455 matches
Mail list logo
