Kapil Thangavelu wrote:
I've been using zope3 as a wsgi app, without a zodb. it bypasses the
zodb publishing traversal via replacement of the published application,
all of which can be managed in zcml.
Hey, this discussion shouldn't be taking place on zope3-dev, which has
been retired. Can
Hey,
Stephan Richter wrote:
[snip]
For me z3c.formdemo is a good example of a small Zope 3 application. It is
built on top of the Zope 3 Web application server. But in order to get it
working, I did not have to install anything special. I just use the
libraries.
Sure, when I use Grok I just
Hey,
Tres Seaver wrote:
[snip]
Frozen Releases
-
A frozen release would consist of:
- A single, frozen KGS (index pages cannot change after release).
[snip]
With Grok we're now using such a versions list with buildout, using the
buildout extends mechanism. This has two
Stephan Richter wrote:
On Monday 08 October 2007 15:09, Tres Seaver wrote:
Presuming agreement on the known good set (KGS) term, I would think
that we have two candidates for what makes up platform releases
Frozen Releases
I started commenting this section until I saw the
Hi there,
I just tried something Stephan also tried, but deserves another topic. I
just wrote a simple script that takes all the eggs grok uses and tries
to run their tests. This is to see whether our pile of eggs isn't broken
in some way.
I get a ton of errors. Mostly a ton of import
Hi there,
2007-10-10 - The Grok project is happy to release Grok 0.10.1! Grok
0.10.1 is a bugfix release of Grok, and the first outcome of the
Neanderthal Grok sprint that was hosted by GfU Cyrus in Cologne,
Germany, last week.
The sole aim of this release is to fix Grok's installation story.
Stephan Richter wrote:
On Sunday 07 October 2007 17:13, Martijn Faassen wrote:
I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants
to be. I do think that such an approach needs to be supplemented by a
framework approach (and I've been putting work into one way to do
Roger Ineichen wrote:
Hi Philipp
Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3
[...]
Soon, we will change Grok so that it emits configuration
actions, rather than doing the registrations right away. That
way, you will still be able to inspect what exactly Grok is
doing (for
Hey,
Stephan, I tried to reply to your points but I realized I was getting
lost in a sea of semantics and that it wasn't useful.
The Zope 3 web application server is not primarily what the Zope 3
project appears to be developing. I strongly suspect there are more
users of Zope 3 technology
Hey,
On 10/8/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
[snip]
... emit configuration actions instead of component
registrations directly. This is underway, started at the sprint last
week by Godefroid Chapelle.
Great! Where can this work be seen?
Good
Jim Fulton wrote:
[snip]
Let me make the case for bug-for-bug compatibility:
I assume by this you mean setting fixed versions.
Yes.
[snip]
I'm not suggesting that setting fixed versions is a bad idea. I think
some projects may choose to go this way. This is a valid policy
decision.
Jim Fulton wrote:
IMO, the Python standard library and batteries included is a mess.
Despite being a Python contributor, I've very unmotivated to be a
contributor because the time lag between contributing and deriving
benefit from the contributions is too long. People had similar
complaints
Jim Fulton wrote:
On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote:
[snip]
- We need a *realistic* (especially wrt available resources) process
for managing releases. There are 2 aspects of this. We shouldn't
make plans for which there aren't enough resources. We also
shouldn't plan
PM, Martijn Faassen wrote:
...
Grok will pick up the balls Zope 3 dropped here.
Hm. I didn't think Zope 3 was animate. Who are you referring to?
That I was pretty annoyed by what I read to be a pretty cavalier
attitude towards the pain people have been going through with eggs,
after all
Jim Fulton wrote:
On Oct 5, 2007, at 1:59 PM, Martijn Faassen wrote:
[snip]
but moved to a new place. zope.app.error, is, I understand, gone now.
I have no idea about this specific move. If there was a zope.app.error
before, then distributions of it should still exist and new
Fred Drake wrote:
On 10/6/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Yet zope.app.error was split up into zope.error and zope.app.error
without releasing a zope.app.error 3.4.0 final first. The split up
should have been done entirely in the 3.5.x series, *after* producing
stable
Hey,
I'm glad some steps are taken!
What I really don't like about this proposal is that it talks about
updating index pages. If I understand this right, an updated index page
will force everybody that uses this index page into an update. I don't
think this is acceptable. Instead I'd suggest
Stephan Richter wrote:
On Friday 05 October 2007 22:45, Benji York wrote:
Stephan Richter wrote:
2. How many packages should be controlled in this index? I think we
should definitely add packages from z3c and the zc namespace.
What is the motivation to include non-controlled packages?
Jim
Benji York wrote:
Stephan Richter wrote:
2. How many packages should be controlled in this index? I think we
should definitely add packages from z3c and the zc namespace.
What is the motivation to include non-controlled packages? I suppose it
is to let people use those packages with (in
Hey,
Another point of feedback:
I saw Stephan's mail on a (partially new) toolchain and somewhat
extensive workflow on using it. I'm a bit surprised a toolchain is
necessary and that the workflow is so involved. With Grok's approach
using extends in buildout, we can just publish such a list
Jim Fulton wrote:
On Oct 6, 2007, at 4:56 AM, Martijn Faassen wrote:
I think Zope 3.4 is currently not usable unless you already know
exactly what you're doing with egg dependencies. What you're supposed
to be doing isn't exactly documented anywhere.
I think you are probably right. I
Hey,
Jim Fulton wrote:
[snip]
I thought that *never* in the 3.4 line of eggs should they *suddenly*
start relying on 3.5 eggs. That's nothing to do with the notion of a
3.4 release, but with the notion that during the stabilization phase,
or with minor bugfix releases, you don't suddenly
Jim Fulton wrote:
On Oct 6, 2007, at 5:24 AM, Martijn Faassen wrote:
[snip]
What I really don't like about this proposal is that it talks about
updating index pages. If I understand this right, an updated index
page will force everybody that uses this index page into an update.
Only people
Roger Ineichen wrote:
[snip]
But I also see another point of view. Zope 3 as a product we
can lobby for and a application server which is ready to use
with a easy setup. e.g. windows installer or buildout,
easy install.
I think such a Zope 3 application server has the following
benefit.
-
Jim Fulton wrote:
There's work going on to create a second version of WSGI. Last time, we
didn't pay much attention until WSGI was a done deal. This time, I
think it would be better if we were involved earlier. Unfortunately, I
don't have time to pay attention. Does anyone else?
I
Hi there,
zope.error is a 3.5 egg, but is needed by 3.4.x releases. I guess this
also happened because large package refactorings happened and were
released as 3.4.x releases. It's pretty bizarre to run into, though.
Regards,
Martijn
___
Fred Drake wrote:
On 10/5/07, Martijn Faassen [EMAIL PROTECTED] wrote:
zope.error is a 3.5 egg, but is needed by 3.4.x releases. I guess this
also happened because large package refactorings happened and were
released as 3.4.x releases. It's pretty bizarre to run into, though.
It's only
Jim Fulton wrote:
On Oct 5, 2007, at 12:07 PM, Martijn Faassen wrote:
Hi there,
zope.error is a 3.5 egg, but is needed by 3.4.x releases. I guess this
also happened because large package refactorings happened and were
released as 3.4.x releases. It's pretty bizarre to run into, though
Stephan Richter wrote:
On Tuesday 02 October 2007 17:14, Jim Fulton wrote:
One hole I see is giving people guidance on what needs to be tested
(and how) before a release is made. My preference would be to rely
heavily on judgement with a few checks so as not to make things too
heavy.
Jim Fulton wrote:
[snip]
Maybe grok was already trimmed down. In my case, I basically eliminated
all ZMI support (since I didn't need it). I got about 40%,
Grok is trimmed down in the sense that it doesn't depend on all Zope 3
packages, though due to the interesting dependency structure
Hi there,
Besides causing us a lot of problems here at the Grok sprint, I also
wonder why in the world are we doing major packaging reorganizations and
releasing them as minor 3.4.x releases? You'd think such a
reorganization would warrant a 3.5 release!
Regards,
Martijn
Hi there,
A release of zope.dottedname was made apparently today that refers to a
CHANGES.txt but doesn't have one. Probable scenario: someone forgot to
svn add a CHANGES.txt, then didn't check out before the tag before
releasing...
This is like the third time Grok (trunk *and* the 0.10
Hey,
[eggs in debian]
Okay, I can see this as an additional, more stably maintained resource
of eggs than the cheeseshop. That might indeed be helpful.
Now, how would you use the Grok gated community with the sqlalchemy
gated community if they had common dependencies, and those dependencies
Hey,
On 9/28/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
Total effort involved in maintaining the gated community then becomes
keeping a set of tarballs available at some web-downloadable location,
and re-running the script after adding / removing them to regenerate
the index.
How many
Hey,
First: thanks for listening, Jim.
On 9/28/07, Jim Fulton [EMAIL PROTECTED] wrote:
[snip]
we could investigate whether we can't come up with something that:
* doesn't break the existing notation. The cleanest way to support
such non-interference seems to be to do this using an extra
Hey,
On 9/28/07, Tres Seaver [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
On 9/28/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
Total effort involved in maintaining the gated community then becomes
keeping a set of tarballs available at some web-downloadable location,
and re
Dominik Huber wrote:
It would be great, if we could handle other adaption-derivations by the
proposed unified, reasonable adaption-api too.
[snip interesting proposal]
Okay, so there seems to be quite a bit of consensus for *some* form of
support for this. I've seen a number of proposals
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.
I'm *not* kidding about that: taking shortcuts
Hey,
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone ASAP) is incompatible with
our goals (ensure that users can install a given package and its
Hey,
Tres Seaver wrote:
[snip]
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone ASAP) is incompatible with
our goals (ensure that users can install a given
Philipp von Weitershausen wrote:
On 27 Sep 2007, at 13:07 , Martijn Faassen wrote:
[snip]
Let's focus on the reasons for each step and keep the discussion at
that level, please? I think it's useful if people ask is that really
necessary? for steps in the release process. Just weigh the pros
Hi there,
While Jim expected to see some form of fireworks in the distutils
discussion that I started about the requirement to pin down eggs while
still leaving flexibility for those who want it, I think we've come to
an early conclusion.
Philip Eby responded and said that my use cases
Hey,
On 9/27/07, Stephan Richter [EMAIL PROTECTED] wrote:
On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:
[snip]
A fairly simple tool can find and report all the problems found and offer
assistance. I think it is worth investing in one, especially since it will
reduce my
Hey,
On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote:
On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
[snip]
Including a file other
that README in the root requires extra effort that I don't want to
require -- writing setup.py files is hard enough as it is.
Put the real README.txt and
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
Why don't you think it can be solved by having packages themselves
state preferred versions? The cheeseshop can be a festering pool of
madness, as long as the packages I pull from it have reasonable
preferred versions, I should
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
I don't like it either. I thought we resolved this though so I'm not
sure why we're discussing this. CHANGES.txt in the root dir it is,
right?
- -1. I argued for putting the CHANGES.txt and the real README.txt in
the *package*
Raphael Ritz wrote:
[snip]
I don't see this in conflict. Rather as complementing each other.
Yes, me too. We need human guidelines in any case.
Then we implement tools to help check the human procedure. If the tool
makes some of the human guidelines unnecessary as the tool catches the
Hi,
I thought Christian Theune already did some work on buildbots for Zope 3
buildouts.
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Hey,
We have a situation where we have developers, not maintainers, uploading
new versions of packages. There will be no integrated testing done for
all software built on all packages in the cheeseshop. Again, I can see
similarities, but I don't believe linux distributions have *exactly* our
Hey,
On 9/27/07, Brian Sutherland [EMAIL PROTECTED] wrote:
[snip]
There is one I thought of, but it's a bit backwards.
Essentially, Debian has a repository of mostly unmodified original egg
tarballs. And, they've already done the hard work of maintaining sane
dependencies.
So, why not
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
Hey,
On 9/26/07, Fred Drake [EMAIL PROTECTED] wrote:
On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
What does one need to tell setup.py to make sure CHANGES.txt is
available? I understand it isn't by default, then? Hm, it does appear to
be there by default. I checked grok 0.10's tgz
Jim Fulton wrote:
On Sep 26, 2007, at 3:32 PM, Philipp von Weitershausen wrote:
[snip]
* working from an svn checkout, in which case setuptools will use the
list of which files are in svn and which aren't as a hint of what to
include and what not
Certainly, I expect CHANGES.txt to be in
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-9-26 16:19 +0200:
...
* That you should never ever delete a release, even if it's a
brown bag release.
But, if you know it is severely broken and you do not have
a working replacement, you should remove it as soon as possible
--
Fred Drake wrote:
On 9/26/07, Marius Gedminas [EMAIL PROTECTED] wrote:
Reducing overhead is why I proposed an automated tool.
Exactly. I like this approach myself.
Sure, I support it too. That said, I'd still like the process *without*
the tool comprehensible by normal human beings. The
Dieter Maurer wrote:
Martijn Faassen wrote at 2007-9-25 19:57 +0200:
...
If you choose for flexibility first, people will need to think about
versions all the time.
I follow Tres argumentation: somehow the Linux distributors
have this problem mostly solved:
While I don't dispute we should
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
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
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
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
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
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
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
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 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
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
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
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
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
1 - 100 of 455 matches
Mail list logo
