Re: [Zope-dev] Re: [Zope3-dev] December release post-mortem

2006-01-23 Thread Chris Withers

Jim Fulton wrote:


If Python had and used a packaging system, like eggs, this wouldn't be 
necessary.

Someday.


*grinz*

The irony that python is so successfuly _because_ of it's batteries 
included nature isn't lost on me ;-)


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope-dev] Re: [Zope3-dev] December release post-mortem

2006-01-23 Thread Jim Fulton

Chris Withers wrote:

Jim Fulton wrote:



If Python had and used a packaging system, like eggs, this wouldn't be 
necessary.

Someday.



*grinz*

The irony that python is so successfuly _because_ of it's batteries 
included nature isn't lost on me ;-)


I would argue that it is successful despite it.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope-dev] Re: [Zope3-dev] December release post-mortem

2006-01-20 Thread Jim Fulton

Chris Withers wrote:
...
On a side note, I see python now includes doctest.py, why are we still 
maintaining our own copy in zope.testing?


doctest has been in Python for a long time, far longer than we've been using it.

Now that we use it aggressively and are aggressively contributing to it, we
usually need a newer version than is available in the Python release we're 
using.

If Python had and used a packaging system, like eggs, this wouldn't be 
necessary.
Someday.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-20 Thread Dieter Maurer
Martijn Faassen wrote at 2006-1-19 19:37 +0100:
 ...
I'm talking about a Zope 2 release including (most of) what's in a Zope 
3 release, so that Five developers can work on exposing *that* in Zope 2 
too (which can then be part of the next Zope 2 release as we integrate 
the newer Five in it).

I very much like Jims idea: having a small core with the ability
to add separately released extensions on demand.

-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Benji York

Stephan Richter wrote:

Let's say zope.testbrowser is an egg and I discover a bug in
zope.textbrowser while doing some other Zope 3 development, I have to
check out zope.testbrowser, fix the bug, check it in, download the
new egg and hope it fixed my Zope 3 problem.


I'm an egg neophyte, but I believe you can put an egg in dev mode (or 
whatever it's called) and you'll get a subversion (or cvs) checkout. 
You can then make your changes, etc.

--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Jim Fulton

Stephan Richter wrote:

On Wednesday 18 January 2006 19:09, Jim Fulton wrote:


You know my position concerning the repository and the release; I'd
prefer them to be kept as similar as possible to simplify the release
process. I hope we can go in that direction. It also makes things more
predictable to developers. We noticed that some Zope 3 packages weren't
packaged into Zope 2 after the release, even though in a developer's
sandbox of Zope 2 they were there.


Right. If eggs work out, then a respository check out will be a lot
smaller, but will download needed eggs.  This would be a replacement of the
use of externals we have now.



Oh, this will make development so much more tedious. Let's say 
zope.testbrowser is an egg and I discover a bug in zope.textbrowser while 
doing some other Zope 3 development, I have to check out zope.testbrowser, 
fix the bug, check it in, download the new egg and hope it fixed my Zope 3 
problem. Honestly this is far too much and I will at most make a bug report.


I beliave that Eggs have a development mode in which you can work on the source.
This apears to be easy to switch too, perhaps easier than editing externals.
I haven't gotten to try this myself.  We'll see as we learn more about eggs.
I'm at least as lazy as you are, so rest assured, I'm gonna try to come up
with a methodology that makes my life as easy as possible.

If more than one application uses a package, it is feasible for at most
one application to include it.  Managing the application that way makes
it more complicated for other applications to use.  For example, the
package's releace cycle becomes bound to the release cycle of the
including application, which is cumbersome for other applications.

I have seen you take a similar approach to zope.testing and I found that 
painful just by watching the checkins.


I don't understand what you mean.  Having a separate zope.testing project has
been extremely useful.  For example, in our comercial apps,
we often used newer versions than existed in Zope 3.  We often needed
enhacements to zope.testing at times that Zope 3 was feature frozen.
We could have made a Zope 3 branch just to modify zope.testing, but that
would have been a hassle for us and for Zope 3 developers.  Note that
the new test runner (from zope.testing) was used in ZODB long before it
was used in Zope 3.

 I feel like an old record, but please
let's keep the development process as simple as possible. I rather make some 
concessions to the packaging and dependency system than spending more time 
developing.


Perhaps our goals are different. I want Zope's packages to be usable
outside of Zope.  I also want to make it easier to use external packages.
I think that a more package-centric development methodoligy will make
achieving these goals much easier.  I also think it will make Zope releases
go smoother because the scope of the release will be narrower.  Someday,
A Zope release will include an app-server specific core and a collection of
other package releases.  To the extend that those packages have their own
lifeccyles, and quality control, the amount of newly released code in a Zope
release wil be smaller.  A package-based approach will also make it easier to
release less. We'll be freed from a batteries included mentality that
encourages large high-risk releases. And it will make it easier for people
to make custom releases that have configurations targeted to specific needs.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Martijn Faassen

Jim Fulton wrote:

Martijn Faassen wrote:
...

How do you assemble releases 'from releases'? I'm not sure I 
understand that. You mean make a Zope 2 release using a Zope 3 release?



No, I mean using eggs.  Zope should be broken into separate projects
with their own eggs.  A Zope release might just be an egg with 
dependencies.

Or it might just be a collection of eggs.


Ah, makes sense. A 'meta-package', so to speak. Works well in Debian, so 
I think that's an interesting pattern to follow. As long as we can do 
those micro releases quickly -- the problem is that Zope 3 is one 
project, and we want one communication channel, as we simply don't have 
enough people otherwise. From another perspective it's many projects, 
though.


You know my position concerning the repository and the release; I'd 
prefer them to be kept as similar as possible to simplify the release 
process. I hope we can go in that direction. It also makes things more 
predictable to developers. We noticed that some Zope 3 packages 
weren't packaged into Zope 2 after the release, even though in a 
developer's sandbox of Zope 2 they were there.



Right. If eggs work out, then a respository check out will be a lot 
smaller,

but will download needed eggs.  This would be a replacement of the
use of externals we have now.


A risk here is that if I find a bug in package X, I can't easily track 
it into package Y and fix it there, as package Y is an egg. The current 
system doesn't have this problem.


As a side issue: From the perspective of Five, it is beneficial to 
have as much Zope 3 code included into Zope 2 releases, as that gives 
us an opportunity to start using this functionality right away, 
exposing it to Zope 2, without waiting for a new release.


Understand though that there is nothing like a backward compatibility
promise for something that hasn't been released.


Yes, but Zope 2 included *less* than Zope 3 in the most recent release, 
and I'd like *all* packages that are in a Zope 3 release to be available 
in a Zope 2 release. I.e. Five doesn't want packages that aren't in a 
Zope 3 release, but not less either.


[snip]
  (If you're interested I can try to explain some of my thinking a bit 
deeply.) Eggs are a nice distribution mechanism, but I'd also want the 
knitting process to work for a SVN checkout -- developers working with 
SVN need to be very easily work with a 'knitted' version, so perhaps 
svn:externals will remain a valuable tool.


Assuming that eggs fullfill their promise, I think I'd
rather use eggs than externals.


Sure, but see the risk I mentioned earlier in this mail.


As part of this decomposition, we need to make zope.app much smaller.
 Early in Zope 3 development, I proposed a simple rule for
organization of the repository: Anything that depended on zope.app
went in zope.app. Anything else went in zope.  If there was doubt,
put it in zope.app.  I think that served us well at the time, but I
think we've moved beyond that,  I'd like to migrate most of zope.app
elsewhere.  Zope 2.10 should not include zope.app.


This worries me; Five is currently using massive quantities of code in 
zope.app, and as expressed above, I value Five having access to 
potentially all Zope 3 code that's in a Zope 3 release.


The code that Five is using will still be available, but it will be
somewhere else (with necessary backward compatibility hacks).


As long as Zope 2.10 contains all packages in Zope 3.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Martijn Faassen

Stephan Richter wrote:

On Wednesday 18 January 2006 19:09, Jim Fulton wrote:


You know my position concerning the repository and the release; I'd
prefer them to be kept as similar as possible to simplify the release
process. I hope we can go in that direction. It also makes things more
predictable to developers. We noticed that some Zope 3 packages weren't
packaged into Zope 2 after the release, even though in a developer's
sandbox of Zope 2 they were there.


Right. If eggs work out, then a respository check out will be a lot
smaller, but will download needed eggs.  This would be a replacement of the
use of externals we have now.



Oh, this will make development so much more tedious. Let's say 
zope.testbrowser is an egg and I discover a bug in zope.textbrowser while 
doing some other Zope 3 development, I have to check out zope.testbrowser, 
fix the bug, check it in, download the new egg and hope it fixed my Zope 3 
problem. Honestly this is far too much and I will at most make a bug report.


Ah, exactly the risk I pointed out too, I should've read the thread 
first before I repeated you. :)


I have seen you take a similar approach to zope.testing and I found that 
painful just by watching the checkins. I feel like an old record, but please 
let's keep the development process as simple as possible. I rather make some 
concessions to the packaging and dependency system than spending more time 
developing.


What if we can create in SVN the equivalent of what would be an egg + 
its dependencies for checkout, using externals? I know Jim said he 
doesn't want to use externals, but I'm thinking in that direction. You'd 
have one SVN directory for each egg, which then contains the right 
externals to pull in all the dependencies. Hopefully the process of 
creating such an SVN directory could be automated from egg dependency 
metadata.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Martijn Faassen

Stephan Richter wrote:
[svn reflecting egg dependency structure]
That would work for me. If it resolves the risk and is still pretty automated, 
SVN checkout or even calling make, then it is fine by me. The others have 
also pointed out the egg development mode.


Right, I didn't know of that, but if that fulfills the usecases, then 
that's even better.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Jim Fulton

Martijn Faassen wrote:
...
Sure, I support dependencies and separating out Zope into sub projects, 
I'm just listing an additional use case: the repository state should be 
similar to release state, to avoid confusion for developers as well as 
people who want to become developers.


I.e. a developer should have the ability to easily see the same (or 
similar) code layout, dependencies, etc, as in a release, and someone 
familiar with a release should see the same (or similar) code layout, 
dependencies, if they become a developer.


Right, got it.  A checkout and a release should be very similar.
If eggs work out, then they would both use eggs to satisfy their
dependencies.

Another use case, probably mostly in the context of Five, it's nice to 
have an inclusive release of Zope 3 in Zope 2. The goal of reducing the 
amount of code included in Zope 2 sounds nice in theory, but it stops 
Five developers from exposing Zope 3 code in Zope 2 because it simply 
isn't there in a particular release. It is *nice* to have all of Zope 3 
included in Zope 2. I don't want to lose that good thing in the rush to 
minimize dependencies.


Right now Five/Zope2 include lots of packages they don't and may never
use.  I want Five/Zope2 to not *have* to include packages they don't
need just because we've created monoliths.  I especially don't want
to release experimental code through Five/Zope2 just because we don't
have our repository and/or packaging in order.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Jim Fulton

Martijn Faassen wrote:
...
A risk here is that if I find a bug in package X, I can't easily track 
it into package Y and fix it there, as package Y is an egg. The current 
system doesn't have this problem.


There are two issues here:

1. Debugging. Can debugging tools show you code in eggs? They should.
   If they don't they may need to be improved.  If that's not an option,
   eggs let you expand an egg into a normal directory at installation time.
   I don't think this will be a problem, although we may need to
   take some steps to assure that it isn't.

2. Updates.  We can't update packages now that we get via externals.
   If we didn't adopt eggs, I expect that we'd make greater and greater
   use of externals.  Eggs don't make update any harder than externals.

...


Understand though that there is nothing like a backward compatibility
promise for something that hasn't been released.



Yes, but Zope 2 included *less* than Zope 3 in the most recent release, 
and I'd like *all* packages that are in a Zope 3 release to be available 
in a Zope 2 release. I.e. Five doesn't want packages that aren't in a 
Zope 3 release, but not less either.


I'm surprised that it included less.  I think a more powerful
packaging architecture will make it easeir to include what we want.
Deciding what we want is another issue.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Jim Fulton

Stephan Richter wrote:

On Thursday 19 January 2006 07:00, Jim Fulton wrote:


 I feel like an old record, but please



let's keep the development process as simple as possible. I rather make
some concessions to the packaging and dependency system than spending
more time developing.


Perhaps our goals are different. I want Zope's packages to be usable
outside of Zope.  I also want to make it easier to use external packages.
I think that a more package-centric development methodoligy will make
achieving these goals much easier.  I also think it will make Zope releases
go smoother because the scope of the release will be narrower.  Someday,
A Zope release will include an app-server specific core and a collection of
other package releases.  To the extend that those packages have their own
lifeccyles, and quality control, the amount of newly released code in a
Zope release wil be smaller.  A package-based approach will also make it
easier to release less. We'll be freed from a batteries included
mentality that encourages large high-risk releases. And it will make it
easier for people to make custom releases that have configurations targeted
to specific needs.



I think we do have different goals here. I would agree with that approach, if 
we would have a large community where small groups take over the maintenance 
and development of a package. But that's not the case and it will not change 
any time soon, I think.


I disagree.  There are sub-projects within The Zope tree that are worked on
by a few people.  Take viewlets for example.  I think we'll have more of this
once we have a more supportive environment.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Tim Peters
...

[Stephan Ricther]
 I have seen you take a similar approach to zope.testing and I found that
 painful just by watching the checkins.

[Jim Fulton]
 I don't understand what you mean.  Having a separate zope.testing project has
 been extremely useful.  For example, in our comercial apps,
 we often used newer versions than existed in Zope 3.  We often needed
 enhacements to zope.testing at times that Zope 3 was feature frozen.
 We could have made a Zope 3 branch just to modify zope.testing, but that
 would have been a hassle for us and for Zope 3 developers.  Note that
 the new test runner (from zope.testing) was used in ZODB long before it
 was used in Zope 3.

I want to note that this was good for Zope3, too:  as a willing early
adopter of zope.testing, ZODB hit bugs and platform-dependent
glitches first, and got them fixed before the larger Zope3 development
community could be bit by them.

Also want to note that ZRS needed to add new features to
zope.testing, and ZRS doesn't include _any_ Zope code (ZRS builds on
ZEO, not Zope).  Having zope.testing be its own project without all
the adminstrative overheads of having its own official releases made
it very easy to add new code for ZRS's benefit without disturbing any
of zope.testing's other users.

In all, zope.testing is a poster child for the value of package
development outside of a Zope tree.  It's true that, to make changes
in zope.testing, I needed to have a distinct checkout of zope.testing.
 I didn't feel that to be a burden, though.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Martijn Faassen

Jim Fulton wrote:

Martijn Faassen wrote:
...

What if we can create in SVN the equivalent of what would be an egg + 
its dependencies for checkout, using externals? I know Jim said he 
doesn't want to use externals, but I'm thinking in that direction. 
You'd have one SVN directory for each egg, which then contains the 
right externals to pull in all the dependencies. Hopefully the process 
of creating such an SVN directory could be automated from egg 
dependency metadata.



I'm confused. I thought you wanted a checkout to look like a release.
Releases won't use svn:externals.  What about dependencies that aren't
managed in subversion?  Will you import them into a repository just so
you can use an external?  What if a dependency of a dependency changes?
Externals don't handle this well.  Eggs do.


I wasn't fully aware when I wrote that that eggs can help during 
development. I need to read up on development eggs.



I think we should investigate eggs.  Do I know they will work? No.  I
haven't done much with them yet. Do you know they won't? Obviously not.
I suggest we reserve jusdgement until we have had an opportunity for
some prototyping.  Based on what I've seen so far, I'm very hopeful.
And then there's the fact that they come from a much wider community
than just Zope.


No, I don't know they don't work, I just hadn't considered eggs as a 
development tool. I agree wholeheartedly eggs should be explored, and I 
was homing in on a possible solution before I understand what other 
alternatives exist. :)


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Martijn Faassen

Jim Fulton wrote:

Martijn Faassen wrote:


Yes, but Zope 2 included *less* than Zope 3 in the most recent 
release, and I'd like *all* packages that are in a Zope 3 release to 
be available in a Zope 2 release. I.e. Five doesn't want packages that 
aren't in a Zope 3 release, but not less either.



I'm surprised that it included less. 


It was a bug, and I think some of it already got resolved (Philipp would 
know more), but it wasn't noticed until fairly late, as during 
development such dependencies are development.



I think a more powerful
packaging architecture will make it easeir to include what we want.
Deciding what we want is another issue.


Agreed. I just wanted to make clear what I want early on. :)

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Martijn Faassen

Jim Fulton wrote:

Martijn Faassen wrote:


Another use case, probably mostly in the context of Five, it's nice to 
have an inclusive release of Zope 3 in Zope 2. The goal of reducing 
the amount of code included in Zope 2 sounds nice in theory, but it 
stops Five developers from exposing Zope 3 code in Zope 2 because it 
simply isn't there in a particular release. It is *nice* to have all 
of Zope 3 included in Zope 2. I don't want to lose that good thing in 
the rush to minimize dependencies.



Right now Five/Zope2 include lots of packages they don't and may never
use.  I want Five/Zope2 to not *have* to include packages they don't
need just because we've created monoliths.  I especially don't want
to release experimental code through Five/Zope2 just because we don't
have our repository and/or packaging in order.


Hm, some confusion.. Perhaps the cause is this: With Zope 3, I mean 
Zope 3 *as released*. I imagine you might think of Zope 3 differently, 
i.e. Zope 3 as what's in the repository, which includes things beyond 
what gets released (i.e experimental packages).


I'm talking about a Zope 2 release including (most of) what's in a Zope 
3 release, so that Five developers can work on exposing *that* in Zope 2 
too (which can then be part of the next Zope 2 release as we integrate 
the newer Five in it).


I'm  describing a pattern of working that has worked pretty well for 
Five for a while now.


Of course that doesn't mean I want experimental packages in Zope 2 that 
are not in a Zope 3 release. Five is about exposing Zope 3 as released 
in Zope 2, it shouldn't expose *more* functionality than Zope 3 does. :)


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Michael Dunstan
On 1/20/06, Tim Peters [EMAIL PROTECTED] wrote:
 In all, zope.testing is a poster child for the value of package
 development outside of a Zope tree.

I've been very happy using zope.testing with several non zope
projects. Including how easy it is to follow and distribute that
package as needed for those projects.

Same goes for zdaemon. And of course ZConfig.

Michael
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope-dev] Re: [Zope3-dev] December release post-mortem

2006-01-19 Thread Chris Withers

Jim Fulton wrote:


I think we should investigate eggs.  Do I know they will work? No.  I
haven't done much with them yet. Do you know they won't? Obviously not.
I suggest we reserve jusdgement until we have had an opportunity for
some prototyping.  Based on what I've seen so far, I'm very hopeful.
And then there's the fact that they come from a much wider community
than just Zope.


I have to admit to being very interested in eggs myself. I like the idea 
of zope being a collection of independent packages with their own 
release schedules - breaking down the monolithic release problem.


I think Zope 3 has done extremely well with all this so far. Personally, 
I've used Zope 3s' ZPT and testbrowser packages in contexts that have 
nothing to do with Zope 3 (or even Zope sometimes) and liked the feel of it.


I wasn't away the same was true for zope.testing but I'm very glad to 
hear it.


On a side note, I see python now includes doctest.py, why are we still 
maintaining our own copy in zope.testing?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Sidnei da Silva
On Wed, Jan 18, 2006 at 07:36:35AM -0500, Jim Fulton wrote:
| And then there are the Windows releases.  Making Zope 2 windows releases
| is very painful and there don't seem to be many people willing to help.
| We've avoided the pain for Zope 3 by being less ambitious.  We let distutils
| do most of the work.  The result is that making a windows release takes 
| minutes
| and is highly automated, but the experience for the end user is less than
| ideal,  Many would rightfully argue that it is inadequate.  What we need
| is a release process that is as easy as the Zope 3 windows release process
| and produces a result as usable as the Zope 2 windows release.  I'm not sure
| exactly what the answer is, but I am sure we need to take a fresh approach.
| Whatever approach we take needs to be highly automated and must not require
| a lot of specialized Windows expertise.

The installers do not require much Windows expertise. In fact, they
require a lot of 'makefile' expertise right now, and some Inno Setup
expertise, not much else.

At Enfold Systems we are using our own home-grown python-based process
to cobble together all the dependencies for building installers. We
haven't switched to Zope 2.9 though.

When the time comes around for a switch, our goal is to switch from
Inno Setup to Wix [1], at which point we hope to contribute this work
to Zope. That might take another 6 months though and sure we don't
want to hold back the Zope Windows installers that long.

[1] http://blogs.msdn.com/robmen/archive/2004/04/05/107709.aspx

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Lennart Regebro
On 1/18/06, Jim Fulton [EMAIL PROTECTED] wrote:
 These were some of my reactions to this first attempt at time-based releases.
 What do other folks think?

I think early January is an understandable delay, considering that
midwinter celebrations came in the way. Great work everyone!

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Jim Fulton

Sidnei da Silva wrote:

On Wed, Jan 18, 2006 at 07:36:35AM -0500, Jim Fulton wrote:
| And then there are the Windows releases.  Making Zope 2 windows releases
| is very painful and there don't seem to be many people willing to help.
| We've avoided the pain for Zope 3 by being less ambitious.  We let distutils
| do most of the work.  The result is that making a windows release takes 
| minutes

| and is highly automated, but the experience for the end user is less than
| ideal,  Many would rightfully argue that it is inadequate.  What we need
| is a release process that is as easy as the Zope 3 windows release process
| and produces a result as usable as the Zope 2 windows release.  I'm not sure
| exactly what the answer is, but I am sure we need to take a fresh approach.
| Whatever approach we take needs to be highly automated and must not require
| a lot of specialized Windows expertise.

The installers do not require much Windows expertise. In fact, they
require a lot of 'makefile' expertise right now, and some Inno Setup
expertise, not much else.


Sorry, Inno Setup is a windows installation builder.  I consider this
windows expertise.


At Enfold Systems we are using our own home-grown python-based process
to cobble together all the dependencies for building installers. We
haven't switched to Zope 2.9 though.


I consider switching build languages from make to Python a definate
step forward.


When the time comes around for a switch, our goal is to switch from
Inno Setup to Wix [1], at which point we hope to contribute this work
to Zope. That might take another 6 months though and sure we don't
want to hold back the Zope Windows installers that long.


Unless the process is automated enough that *I* can do it,
whoever suggests a new system needs to be prepared to
operate it reliably as well.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Sidnei da Silva
On Wed, Jan 18, 2006 at 11:24:20AM -0500, Jim Fulton wrote:
| Sidnei da Silva wrote:
| On Wed, Jan 18, 2006 at 10:45:20AM -0500, Jim Fulton wrote:
| | People up to now have come up with systems like this that they thought 
| were
| | automated enough.  That's why we don't have a 2.9 release for windows.
| 
| What about we turn that around. How would you describe a 'automated
| enough' build environment? I suspect you consider:
| 
|   python setup.py bdist_wininst
| 
| to be pretty close to that.
| 
| I think
| 
| 
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease
| 
| Is pretty close.  Note that this has a number os steps, but there are few
| and they are well documented, so I don't have to think.

Not that much different from what already exists for Zope 2:

http://svn.zope.org/Zope/trunk/inst/WinBuilders/README.txt?rev=39675view=auto

| As I said before, the fact that we don't have a windows release
| is proof that the process isn't automated enough.

That's not a proof that the process is not automated enough. The
transition from python2.3 to 2.4 *is* non-trivial because python
changed from distutils to MSI.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Jim Fulton

Sidnei da Silva wrote:
...

| As I said before, the fact that we don't have a windows release
| is proof that the process isn't automated enough.

That's not a proof that the process is not automated enough. The
transition from python2.3 to 2.4 *is* non-trivial because python
changed from distutils to MSI.


Except that the same sort of problems occurred with 2.8.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Stephan Richter
On Wednesday 18 January 2006 11:27, Martijn Faassen wrote:
 How do you assemble releases 'from releases'? I'm not sure I understand
 that. You mean make a Zope 2 release using a Zope 3 release?

I'll note that SchoolTool greatly benefits from the current release building. 
We simply include all the Zope 3 dependencies in our dependency list and 
build the release. We can decide to include Zope 3 dependencies or not. 
Overall I think zpkg is a great win and whatever we do next should not remove 
those features.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Jim Fulton

Martijn Faassen wrote:
...

How do you assemble releases 'from releases'? I'm not sure I understand 
that. You mean make a Zope 2 release using a Zope 3 release?


No, I mean using eggs.  Zope should be broken into separate projects
with their own eggs.  A Zope release might just be an egg with dependencies.
Or it might just be a collection of eggs.

You know my position concerning the repository and the release; I'd 
prefer them to be kept as similar as possible to simplify the release 
process. I hope we can go in that direction. It also makes things more 
predictable to developers. We noticed that some Zope 3 packages weren't 
packaged into Zope 2 after the release, even though in a developer's 
sandbox of Zope 2 they were there.


Right. If eggs work out, then a respository check out will be a lot smaller,
but will download needed eggs.  This would be a replacement of the
use of externals we have now.

As a side issue: From the perspective of Five, it is beneficial to have 
as much Zope 3 code included into Zope 2 releases, as that gives us an 
opportunity to start using this functionality right away, exposing it to 
Zope 2, without waiting for a new release.


Understand though that there is nothing like a backward compatibility
promise for something that hasn't been released.


[snip]


We have begun to see Zope 3 decomposed into separate projects knit
together via svn:externals.  I'd like to see that trend continue and
to perhaps switch to making the knitting process use eggs,  I'd like
to leverage eggs to make the release process much simpler.  It should
be easy for people to make releases so that there could easily be
multiple distributions aimed at different needs and expectations.



I'll repeat here that I think there's much value in trying to keep the 
mapping of the SVN repository very similar to what is actually released. 


I think I understand where you are coming from.

  (If you're interested I can try to explain some of my thinking a bit 
deeply.) Eggs are a nice distribution mechanism, but I'd also want the 
knitting process to work for a SVN checkout -- developers working with 
SVN need to be very easily work with a 'knitted' version, so perhaps 
svn:externals will remain a valuable tool.


Assuming that eggs fullfill their promise, I think I'd
rather use eggs than externals.


As part of this decomposition, we need to make zope.app much smaller.
 Early in Zope 3 development, I proposed a simple rule for
organization of the repository: Anything that depended on zope.app
went in zope.app. Anything else went in zope.  If there was doubt,
put it in zope.app.  I think that served us well at the time, but I
think we've moved beyond that,  I'd like to migrate most of zope.app
elsewhere.  Zope 2.10 should not include zope.app.



This worries me; Five is currently using massive quantities of code in 
zope.app, and as expressed above, I value Five having access to 
potentially all Zope 3 code that's in a Zope 3 release.


The code that Five is using will still be available, but it will be
somewhere else (with necessary backward compatibility hacks).

Jim
--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Jim Fulton

Stephan Richter wrote:

On Wednesday 18 January 2006 11:27, Martijn Faassen wrote:


How do you assemble releases 'from releases'? I'm not sure I understand
that. You mean make a Zope 2 release using a Zope 3 release?



I'll note that SchoolTool greatly benefits from the current release building. 
We simply include all the Zope 3 dependencies in our dependency list and 
build the release. We can decide to include Zope 3 dependencies or not. 
Overall I think zpkg is a great win and whatever we do next should not remove 
those features.


I agree that dependency based releases -- and development is great.  I think
eggs are a lot farther along that zpkg. (Eggs weren't around when we started
zpkg.)  If eggs work out, as I hope they will, I'd like to stop work on
zpkg and just use eggs.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Fred Drake
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
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] December release post-mortem

2006-01-18 Thread Stephan Richter
On Wednesday 18 January 2006 19:09, Jim Fulton wrote:
  You know my position concerning the repository and the release; I'd
  prefer them to be kept as similar as possible to simplify the release
  process. I hope we can go in that direction. It also makes things more
  predictable to developers. We noticed that some Zope 3 packages weren't
  packaged into Zope 2 after the release, even though in a developer's
  sandbox of Zope 2 they were there.

 Right. If eggs work out, then a respository check out will be a lot
 smaller, but will download needed eggs.  This would be a replacement of the
 use of externals we have now.

Oh, this will make development so much more tedious. Let's say 
zope.testbrowser is an egg and I discover a bug in zope.textbrowser while 
doing some other Zope 3 development, I have to check out zope.testbrowser, 
fix the bug, check it in, download the new egg and hope it fixed my Zope 3 
problem. Honestly this is far too much and I will at most make a bug report.

I have seen you take a similar approach to zope.testing and I found that 
painful just by watching the checkins. I feel like an old record, but please 
let's keep the development process as simple as possible. I rather make some 
concessions to the packaging and dependency system than spending more time 
developing.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com