Re: [Zope3-dev] Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases
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 3.4.0 releases. It's all there in Subversion. Someone who wants a final 3.4.0 release is welcome to make one. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases
On Oct 6, 2007, at 5:06 AM, Martijn Faassen wrote: 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 distributions should be backward compatible. After we fixed a bunch of errors in them, they're backward compatible, yes. With deprecation warnings. The code moved to zope.error so zope.app.error is now empty. I really don't think going from zope.app.applicationcontrol 3.4 beta whatever, going to final 3.4.1 suddenly means a whole new package should appear with new deprecation warnings. Agreed. 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 start relying on a new feature release of something else (or in this case, an entirely new release). I think I agree with the spirit of the above, but not the specifics. You restate the specifics below in a way I whole-heartedly agree with. There isn't a 3.4 line of eggs. There could be a set of projects versions associated with a 3.4 release of Zope3, but the individual version number could be almost anything. Anyway, I think the rule should be: When you do a final or bugfix release of a package, you can't start requiring a new feature release of another package. +1 Translated to version numbers: If X.Y.x has been relying on A.B.x, X.Y.x + 1 cannot start relying on A.B + n, only on new A.B.x + n releases, where x is one of (b0, b1, 1, 2, 3, ...) and n is one of (1, 2, 3 ...) Exactly. Jim -- Jim Fulton 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] Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases
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 think part of the problem is that we no longer have a clear vision for what Zope 3 is. I don't think this is entirely bad, as the vision has been evolving to match reality. I think most of us are settling on the idea of Zope 3 as library, but we're still figuring out how to articulate and implement this vision. Zope 3 the code isn't animate, but the open source community better be. Right. I consider you to be a part of this community. Several of the major players in the community have been highly engaged in the discussions over the past several days. I think it's safe to say that we're trying to make things better. We actually care about a Grok version as it's the main way to get people to actually use Zope 3 stuff. We noticed this while we were going through egg dependencies by the way, not using a Zope 3 version. I don't know what you are trying to say. Fred expressed he (and many of us) are happy he doesn't have to think about a Zope 3 version anymore. The result is, as far as I can see, that *everybody* has to think about versions. If there'd been some release of 3.4, we'd be able to use the versions that release is using, but instead, everybody is making their own collections of eggs and hoping for the best. I understand that eggs can evolve at different rates, but having to determine the base from which to start ourselves wasn't exactly a pleasant exercise. Since everybody will have to come up with their own list I imagine others aren't exactly thrilled either. That's why I like the idea of managed indexes, similar to the package repositories managed for linux distributions. I'm hopeful that this approach will bear fruit soon. ... But if nobody in the Zope 3 community steps up and starts to clearly point out what people *should* be doing, the situation will continue to be unworkable. New users will not be able to adopt Zope 3 at all anymore. Agreed. Of course, before we can point out what people should be doing, we have to figure out what that is. To do that, people have to remain engaged. I do care about getting new users to adopt Zope 3 technologies. I don't see the Zope 3 community think much about new user adoption. Lots of people care. Of course, most of us also have day jobs. Many of us are doing the best we can. The only way the eggified Zope can be used reliably currently is with a lot of upfront knowledge most people don't have, and a lot of work to sort through the eggs. There are scripts floating around to extract a list of versions from a buildout run, which helps some, but initially the answer I got on #zope3-dev when asking about such things was write your own script, it's easy. I thought open source communities were about sharing solutions for problems, not just sharing the problems themselves. Again, we have to have the solutions before we can share them. Sometimes, we arrive at these solutions through experimentation. As always, too, we have to understand the different problem sets we have and the perspectives that gives us. Many of us are building applications with Zope 3. Others, like you, are building platforms. Solutions that work for single applications, like nailing versions in meta egg or buildout configuration don't work so well for platforms, as I think you've discovered. I think in order to get new users to adopt the system, besides clearly documenting quite involved instructions on what they should be doing, there should be a way to use Zope 3 reliably *without* having to have all this knowledge and doing all this work. Agreed. Anyway, I know you personally are concerned with this issue, and I realize that buildout has been attempting to grow features that help here. I appreciate the help. Thanks. Note that buildout has very much an application focus. The Grok project is trying to solve these issues. We published a document that tells users what to do. We now publish lists of eggs on a HTTP server (one per grok release). We have adjusted grokproject so that a versions list will be used automatically when you create a new grok project. We attempt to reach a situation where users can install and use Grok and build their own applications without having to spend too much thought on dependencies. We aim for a situation where the community manages the list of dependencies, instead of everyone for themselves. Sounds great. I suspect that the same or similar effort could server the broader Zope 3 community. Why did this have to happen within the Grok project? I have the impression that too much, people in the Zope 3 community think that
Re: [Zope3-dev] Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases
On Oct 5, 2007, at 1:59 PM, Martijn Faassen wrote: 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. The satellite projects have version #s that are independent from the Zope version #s. Any similarity is a hysterical accident. :) I don't understand. Probably because you didn't provide specifics so My answer is to a different question than you may have been asking. :) zope.error is zope.app.error, I don't know what this means. 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 distributions should be backward compatible. zope.error 3.5 is needed by: required by zope.app.applicationcontrol 3.4.1. required by zope.app.appsetup 3.4.1. required by zope.app.publication 3.4.2. OK. I'm not sure what the issue is here. Are these satellite projects? What is a satellite project? Yes. These are satellite projects. We use the word satallite project for the new individual egg projects to distinguish them from the classic Zope 3 tree. Jim -- Jim Fulton 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] Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases
On Oct 5, 2007, at 1:55 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? We actually care about a Grok version as it's the main way to get people to actually use Zope 3 stuff. We noticed this while we were going through egg dependencies by the way, not using a Zope 3 version. I don't know what you are trying to say. ... Anyway, I personally don't care much that Zope 3.4 is unusuable without a massive investment in time sorting through eggs, It's a shame that you are taking this view. as we have fixed the problem with Grok. If non-Grok users are interested in our fixes, please let us know though. We've just made this massive investment. I'd suggest people to switch to Grok anyway, as we actually think about this stuff and care about having our house in order. Are you suggesting that other people aren't thinking about this and don't care? I hope that the proposal for setting up a known-good-set index will be helpful. I'm sure Stephan would like to know the versions you chose. I imagine he'll be able to get those by looking at Grok. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
