zope-2.9 r40780 make install doesn't finish, files missing from bin
I didn't receive any feedback on zope-general, but it could just be a problem with my environment that fails silently. Can anyone confirm that this isn't pilot error before I file a bug? Thanks. --- I'm having some trouble with the 'make install' stage of Zope-2.9 svn. Using python-2.4.2 on Gentoo linux. Zope-2.9.0b1 installed fine, but I needed the fix for get_transaction() ASAP. URL: svn://svn.zope.org/repos/main/Zope/branches/2.9 Revision: 40853 # ./configure --prefix=/usr/lib/zope-2.9.0 # make # make install (...) copying lib/python/zope/app/recorder/zope.app.recorder-configure.zcml -> /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/app/pluggableauth/zope.app.pluggableauth-configure.zcml -> /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/app/securitypolicy/securitypolicy-meta.zcml -> /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/testbrowser/testbrowser-ftesting.zcml -> /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/formlib/formlib-configure.zcml -> /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/app/securitypolicy/securitypolicy.zcml -> /usr/lib/zope-2.9.0/zopeskel/etc [ -f /usr/lib/zope-2.9.0/bin/python ] || ln -sfn "/usr/bin/python" /usr/lib/zope-2.9.0/bin/python Zope binaries installed successfully. Now run '/usr/lib/zope-2.9.0/bin/mkzopeinstance.py' This leaves (most visibly) many missing files in /usr/lib/zope-2.9.0/bin/. Only the 'python' symlink, and 'zconfig zconfig_schema2html zdctl.py zdrun.py' are installed there. Other files may be missing if they came afterwards, I don't have information on that. Is this line indicating a terminating error in make install? [ -f /usr/lib/zope-2.9.0/bin/python ] || ln -sfn "/usr/bin/python" /usr/lib/zope-2.9.0/bin/python Subsequent runs don't resume installing the remaining files: # make install "/usr/bin/python" "/home/jtk/software/svn/Zope/setup.py" \ build_ext -i \ install --home="/usr/lib/zope-2.9.0" running build_ext running build_headers running install running build running build_py running build_scripts running install_lib running install_headers running install_scripts changing mode of /usr/lib/zope-2.9.0/bin/zconfig to 755 changing mode of /usr/lib/zope-2.9.0/bin/zconfig_schema2html to 755 changing mode of /usr/lib/zope-2.9.0/bin/zdctl.py to 755 changing mode of /usr/lib/zope-2.9.0/bin/zdrun.py to 755 running install_data [ -f /usr/lib/zope-2.9.0/bin/python ] || ln -sfn "/usr/bin/python" /usr/lib/zope-2.9.0/bin/python Zope binaries installed successfully. Now run '/usr/lib/zope-2.9.0/bin/mkzopeinstance.py' Thanks for any insight on the issue. I don't think I want to run Zope in-place from the working copy.
"make install" does currently not work on 2.9 branch and trunk. I am told that this is because "zpkg cannot do it". I am also told that the tarball would support make install, just not the checkout. I never use tarballs, so I don't know for sure. I'd very much like to see the canonical "./configure; make; make install" continue to work as it did in 2.7 and 2.8. Sysadmins go crazy if Zope's installation procedure changes with every other release. Stefan On 17. Dez 2005, at 20:46, Jeff Kowalczyk wrote:
I'm having some trouble with the 'make install' stage of Zope-2.9 svn. Using python-2.4.2 on Gentoo linux. Zope-2.9.0b1 installed fine, but I needed the fix for get_transaction() ASAP.
URL: svn://svn.zope.org/repos/main/Zope/branches/2.9 Revision: 40853
# ./configure --prefix=/usr/lib/zope-2.9.0 # make # make install
-- Anything that happens, happens. --Douglas Adams
--On 18. Dezember 2005 10:40:32 +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
"make install" does currently not work on 2.9 branch and trunk. I am told that this is because "zpkg cannot do it". I am also told that the tarball would support make install, just not the checkout. I never use tarballs, so I don't know for sure.
I'd very much like to see the canonical "./configure; make; make install" continue to work as it did in 2.7 and 2.8. Sysadmins go crazy if Zope's installation procedure changes with every other release.
I agree. I am also not happy with that. Unfortunately I have currently no clue how to solve this issue (no idea about zpkg). WHat you can do is the following: - copy the checkout to the location where your software home should be - run "configure; make inplace; make instance" -aj
Andreas Jung wrote:
I agree. I am also not happy with that. Unfortunately I have currently no clue how to solve this issue (no idea about zpkg). WHat you can do is the following:
- copy the checkout to the location where your software home should be
- run "configure; make inplace; make instance"
Doesn't work for me; I don't have a bin/mkzopeinstance after this procedure so I still cannot create instances. Sigh. Regards, Martijn
Martijn Faassen wrote:
Andreas Jung wrote:
I agree. I am also not happy with that. Unfortunately I have currently no clue how to solve this issue (no idea about zpkg). WHat you can do is the following:
- copy the checkout to the location where your software home should be
- run "configure; make inplace; make instance"
Doesn't work for me; I don't have a bin/mkzopeinstance after this procedure so I still cannot create instances. Sigh.
I use utilities/mkzopeinstance.py (until moves again...) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
Martijn Faassen wrote:
Andreas Jung wrote:
I agree. I am also not happy with that. Unfortunately I have currently no clue how to solve this issue (no idea about zpkg). WHat you can do is the following:
- copy the checkout to the location where your software home should be
- run "configure; make inplace; make instance"
Doesn't work for me; I don't have a bin/mkzopeinstance after this procedure so I still cannot create instances. Sigh.
I use utilities/mkzopeinstance.py (until moves again...)
Florent and others who pointed it out. Useful to know about, thanks! Regards, Martijn
On 18 Dec 2005, at 09:40, Stefan H. Holek wrote:
"make install" does currently not work on 2.9 branch and trunk. I am told that this is because "zpkg cannot do it". I am also told that the tarball would support make install, just not the checkout. I never use tarballs, so I don't know for sure.
I'd very much like to see the canonical "./configure; make; make install" continue to work as it did in 2.7 and 2.8. Sysadmins go crazy if Zope's installation procedure changes with every other release.
Yes, I'm also severely frustrated by this change. Not just sysadmins go crazy, it seems like a change without any good reason whatsoever. I believe having it simplified to "./configure; make; make install" has eliminated a ton of whining from the mailing lists from people who (rightfully so) found the previous "wo_pcgi.py" buildout odd. We're risking a lot of confusion and bad feelings again if "./ configure; make; make install" does not work as expected. jens
[Stefan H. Holek]
"make install" does currently not work on 2.9 branch and trunk. I am told that this is because "zpkg cannot do it". I am also told that the tarball would support make install, just not the checkout. I never use tarballs, so I don't know for sure.
There's no longer any necessary relationship between the shape or contents of a checkout tree and the shape or contents of a distribution tree (tarball). How the two relate now is defined by input to zpkgtools, and it's possible to create multiple kinds of distributions from the same checkout tree now (by giving zpkgtools different input). Plain "setup.py build" no longer necessarily works from a checkout tree either, BTW. This is all in line with zpkgtools's goals: <http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/Zope3PackagingProposal> I guess that the process for making a Zope3 release applies to Zope 2.9 now too: <http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MakingARelease> ZODB's release process also had to change similarly when it moved to zpkgtools.
I'd very much like to see the canonical "./configure; make; make install" continue to work as it did in 2.7 and 2.8. Sysadmins go crazy if Zope's installation procedure changes with every other release.
Nobody should be installing from a checkout to begin with, right? The comfortable old dance should continue to work from a distribution. checkout != distribution. Arguments about zpkgtools design probably need to involve Jim.
On 18. Dez 2005, at 17:58, Tim Peters wrote:
Nobody should be installing from a checkout to begin with, right?
Ok, so that's probably where we disagree then ;-) I almost exclusively work with checkouts, and I would think many developers (as opposed to "users") do. Is there really no way to allow "make install" to work from a sandbox? Stefan -- Anything that happens, happens. --Douglas Adams
On 20 Dec 2005, at 08:51, Stefan H. Holek wrote:
On 18. Dez 2005, at 17:58, Tim Peters wrote:
Nobody should be installing from a checkout to begin with, right?
Ok, so that's probably where we disagree then ;-)
I almost exclusively work with checkouts, and I would think many developers (as opposed to "users") do. Is there really no way to allow "make install" to work from a sandbox?
I strongly disagree as well. I believe it is normal practice to grab a tag or branch tip from subversion and install that. Why would I ever grab some tarball when I'm at the command line already and use svn for everything else, anyway? jens
--On 20. Dezember 2005 09:59:36 +0000 Jens Vagelpohl <jens@dataflake.org> wrote:
I strongly disagree as well. I believe it is normal practice to grab a tag or branch tip from subversion and install that. Why would I ever grab some tarball when I'm at the command line already and use svn for everything else, anyway?
What is wrong with: ./configure make inplace ? -aj
Jens Vagelpohl wrote:
On 20 Dec 2005, at 08:51, Stefan H. Holek wrote:
On 18. Dez 2005, at 17:58, Tim Peters wrote:
Nobody should be installing from a checkout to begin with, right?
Ok, so that's probably where we disagree then ;-)
I almost exclusively work with checkouts, and I would think many developers (as opposed to "users") do. Is there really no way to allow "make install" to work from a sandbox?
I strongly disagree as well. I believe it is normal practice to grab a tag or branch tip from subversion and install that. Why would I ever grab some tarball when I'm at the command line already and use svn for everything else, anyway?
I'm not happy about this change either -- I just ran into it. I did the 'configure; make; make install' dance, and suddenly I run into an error. I like working with release tarballs but I don't like the experience to be different when I do a checkout. The least I expect is to run into an error message that doesn't tell me anything. Regards, Martijn
Martijn Faassen wrote:
Jens Vagelpohl wrote:
On 20 Dec 2005, at 08:51, Stefan H. Holek wrote:
On 18. Dez 2005, at 17:58, Tim Peters wrote:
Nobody should be installing from a checkout to begin with, right?
Ok, so that's probably where we disagree then ;-)
I almost exclusively work with checkouts, and I would think many developers (as opposed to "users") do. Is there really no way to allow "make install" to work from a sandbox?
I strongly disagree as well. I believe it is normal practice to grab a tag or branch tip from subversion and install that. Why would I ever grab some tarball when I'm at the command line already and use svn for everything else, anyway?
I'm not happy about this change either -- I just ran into it. I did the 'configure; make; make install' dance, and suddenly I run into an error. I like working with release tarballs but I don't like the experience to be different when I do a checkout. The least I expect is to run into an error message that doesn't tell me anything.
I'll note, FWIW, that we don't do installs from Zope 3 checkouts. I think it's worth asking whether this is an important requirement. If it is, then we should make it work. Question is, is it worth delaying the release? I don't know. If we did stay with the current situation, we'd need to cleanup the documentation so that a developer can easily reminder herself what she can do and how to do it. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wed, 2005-12-21 at 13:47 -0500, Jim Fulton wrote:
I'll note, FWIW, that we don't do installs from Zope 3 checkouts. I think it's worth asking whether this is an important requirement. If it is, then we should make it work. Question is, is it worth delaying the release? I don't know.
I think it's an important requirement; many of us have done this dance for years. The reason I'd suspect this got done by Chris M was to ease our pains we'd had to work around over time and make it easier for people coming into the Zope Community - or their support staff (i.e. Admins) I can't answer the last question, but it seems to apparent that it's important and expected behavior by lots of people in the community.
If we did stay with the current situation, we'd need to cleanup the documentation so that a developer can easily reminder herself what she can do and how to do it.
If it's indeed *easy* and clear, that should be ok. It just needs to work sensibly :) So many of us are used to the ./configure; make; make install dance.
Jim
Andrew
Andrew Sawyers wrote:
On Wed, 2005-12-21 at 13:47 -0500, Jim Fulton wrote:
I'll note, FWIW, that we don't do installs from Zope 3 checkouts. I think it's worth asking whether this is an important requirement. If it is, then we should make it work. Question is, is it worth delaying the release? I don't know.
I think it's an important requirement; many of us have done this dance for years. The reason I'd suspect this got done by Chris M was to ease our pains we'd had to work around over time and make it easier for people coming into the Zope Community - or their support staff (i.e. Admins)
But those people use releases, not checkouts AFAIK. ...
If we did stay with the current situation, we'd need to cleanup the documentation so that a developer can easily reminder herself what she can do and how to do it.
If it's indeed *easy* and clear, that should be ok. It just needs to work sensibly :) So many of us are used to the ./configure; make; make install dance.
I'll note that, as a developer, I have never done this and probably never would want to do this. The only use case for this is a deployer of Zope that wants to install an unreleased revision of Zope. If this use case is driving this, a better solution might be to build automatic snapshot releases. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
I'll note that, as a developer, I have never done this and probably never would want to do this.
How do you test 'mkzopeinstance' then? Build a release first? That's rather cumbersome. Anyway, small point.
The only use case for this is a deployer of Zope that wants to install an unreleased revision of Zope. If this use case is driving this, a better solution might be to build automatic snapshot releases.
I want to be able to work in zope instances, no matter what version of zope, released or unreleased, I'm dealing with. I don't see how I should do this right now. I think there's a broader use case than this, however: I think it's important to make the transition between the repository world and the released version world as small as possible. This is an expectation that people have from other projects, and in my opinion Zope should strive to let that expectation work for Zope. Zope may have special distribution requirements indeed, but are they special enough to raise the barrier for people who want to become developers? I realize that there is more than one distribution from the same repository, but if we just stick to the philosophy that there's one 'default' experience that you get when you use an svn checkout, then it makes sense for that experience to be as similar to a Zope 2 release tarball as possible. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
I'll note that, as a developer, I have never done this and probably never would want to do this.
How do you test 'mkzopeinstance' then? Build a release first? That's rather cumbersome. Anyway, small point.
In Zope3, I use bin/mkzopeinstance. In Zope 2 I have always (since the advent of the configure/make dance) use make instance to make my checkout into an instance. I'm told that in the current world, you can also use utilities/mkzopeinstance.
The only use case for this is a deployer of Zope that wants to install an unreleased revision of Zope. If this use case is driving this, a better solution might be to build automatic snapshot releases.
I want to be able to work in zope instances, no matter what version of zope, released or unreleased, I'm dealing with. I don't see how I should do this right now.
See above. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On 21 Dec 2005, at 18:47, Jim Fulton wrote:
I'll note, FWIW, that we don't do installs from Zope 3 checkouts. I think it's worth asking whether this is an important requirement. If it is, then we should make it work. Question is, is it worth delaying the release? I don't know.
IMHO it is an important requirement. We're inviting a hailstorm of questions and annoyed users by breaking this well-known routine for checkouts. I really think there is not a single good reason for having a different experience for checkouts vs tarballs. It would even lead to major annoyance where I work right now, just to give a real life example. For us, building out a development sandbox is the same process as building out a production instance, and for development buildouts we routinely want to just substitute checkous from a different tag/branch of Zope. jens
--On 21. Dezember 2005 19:35:35 +0000 Jens Vagelpohl <jens@dataflake.org> wrote:
I really think there is not a single good reason for having a different experience for checkouts vs tarballs. It would even lead to major annoyance where I work right now, just to give a real life example. For us, building out a development sandbox is the same process as building out a production instance, and for development buildouts we routinely want to just substitute checkous from a different tag/branch of Zope.
Who has the knowledge and time to fix this? -aj
Andreas Jung wrote:
Who has the knowledge and time to fix this?
I think we need to have some philosophical agreement on what is going to be done before we figure out who has time to "fix" this. I think the issue is a bit deeper than just a bug people want fix, even though it presents itself that way. The requirements that zpkg tries to fulfill, primarily multiple distributions from the same repository, have given us this situation. Perhaps we should revisit zpkg and add the requirement that the state of the repository should be as similar as possible to that of at least *one* of those distributions, and see what happens to its design. Fixing this should be part of the Zope 2.10 cycle, hopefully. I can interpret your question another way, as a count against zpkg: zpkg is so peculiar to Zope that even most Zope core developers don't know how to fix this. That sucks and in my book is a very serious negative point against zpkg. The simplicity of "repository *is* distribution" has a very important benefit in its favor there, as that's trivial to understand. Regards, Martijn
r --On 22. Dezember 2005 12:06:09 +0100 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote:
Who has the knowledge and time to fix this?
I think we need to have some philosophical agreement on what is going to be done before we figure out who has time to "fix" this. I think the issue is a bit deeper than just a bug people want fix, even though it presents itself that way.
Of course the issue is deeper but I have no idea how deep :-)
The requirements that zpkg tries to fulfill, primarily multiple distributions from the same repository, have given us this situation. Perhaps we should revisit zpkg and add the requirement that the state of the repository should be as similar as possible to that of at least *one* of those distributions, and see what happens to its design.
Fixing this should be part of the Zope 2.10 cycle, hopefully.
Jup, I don't consider it is blocker for 2.9.0 although it might/will cause some trouble.
I can interpret your question another way, as a count against zpkg: zpkg is so peculiar to Zope that even most Zope core developers don't know how to fix this. That sucks and in my book is a very serious negative point against zpkg. The simplicity of "repository *is* distribution" has a very important benefit in its favor there, as that's trivial to understand.
I am not against zpkg but I have really no idea how it works, what is does for me and how it causes the particular trouble in this case..at the moment zpkg is just a magic black box with some esoteric functionality....to make it short: I need to learn what zpkg is and how it works. Until then ppl with some zpkg skills need to care about the problem. Andreas
Andreas Jung wrote: ...
I am not against zpkg but I have really no idea how it works, what is does for me and how it causes the particular trouble in this case..at the moment zpkg is just a magic black box with some esoteric functionality....to make it short: I need to learn what zpkg is and how it works. Until then ppl with some zpkg skills need to care about the problem.
zpkg has reasonable extensive documentation. I'll note that zpkg is providing us 2 benefits: - Making the release possible by excluding bits of Zope 3 that are not ready for release. - Allowing us to avoid one monster setup.py file in the root of Zope that has to be changed any time we add or remove an extension module. The later is a significant benefit. Unfortunately though, it is a mixed benefit. We are bending zpkg to do something it wasn't intended to do. Originally, it was designed just to make releases. It hasn't really been adequately rethought to support checkouts. As a result we've had to make some compromises. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Martijn Faassen wrote:
Andreas Jung wrote:
Who has the knowledge and time to fix this?
I think we need to have some philosophical agreement on what is going to be done before we figure out who has time to "fix" this. I think the issue is a bit deeper than just a bug people want fix, even though it presents itself that way.
The requirements that zpkg tries to fulfill, primarily multiple distributions from the same repository, have given us this situation.
No, a lack of time and agreement on goals have given us this situation. If we'd had more time for this release, or for that matter, if people had eleveted this issue sooner (better?) we could have solved it with zpkg.
Perhaps we should revisit zpkg and add the requirement that the state of the repository should be as similar as possible to that of at least *one* of those distributions, and see what happens to its design.
If we agree on that goal, then I'm sure we can fix it if we wish.
Fixing this should be part of the Zope 2.10 cycle, hopefully.
Yup.
I can interpret your question another way, as a count against zpkg: zpkg is so peculiar to Zope that even most Zope core developers don't know how to fix this. That sucks and in my book is a very serious negative point against zpkg.
That would count as a serious negative point for any new technology.
The simplicity of "repository *is* distribution" has a very important benefit in its favor there, as that's trivial to understand.
And would have made including Zope 3 in Zope 2 a real mess. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
And would have made including Zope 3 in Zope 2 a real mess.
I realize that zpkg has important benefits and use cases. My point with trying to point out weaknesses is not to argue against the existence of zpkg - something like that needs to exist given the use case of one repository multiple distributions. I want to create awareness of other use cases that perhaps need to be fixed as well. Part of this is due to learning curve issues. Part of this is because this can be seen as a non-essential difference between Zope and the rest of the world -- I wonder whether other Python projects have dealt with one repository multiple distributions before, or whether Zope is the first. I suspect it is...; it's just that we're trailblazing an area is not related to web applications directly, which makes it harder to do, and is also something we as Zope should be very careful about. Regards, Martijn
This has been my approach also. Not surprisingly, many of us worked on these processes together and have 'sanitized them' over time. :) There has always been 'another side' who either hasn't liked this procedure or the 'make' voodoo and have come up with their own, or just haven't had to do this at all. Andrew
I really think there is not a single good reason for having a different experience for checkouts vs tarballs. It would even lead to major annoyance where I work right now, just to give a real life example. For us, building out a development sandbox is the same process as building out a production instance, and for development buildouts we routinely want to just substitute checkous from a different tag/branch of Zope.
jens
Jens Vagelpohl wrote:
IMHO it is an important requirement. We're inviting a hailstorm of questions and annoyed users by breaking this well-known routine for checkouts.
I really think there is not a single good reason for having a different experience for checkouts vs tarballs. It would even lead to major annoyance where I work right now, just to give a real life example. For us, building out a development sandbox is the same process as building out a production instance, and for development buildouts we routinely want to just substitute checkous from a different tag/branch of Zope.
Big +1, and that's not just 'cos I work with Jens ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jens Vagelpohl wrote:
On 21 Dec 2005, at 18:47, Jim Fulton wrote:
I'll note, FWIW, that we don't do installs from Zope 3 checkouts. I think it's worth asking whether this is an important requirement. If it is, then we should make it work. Question is, is it worth delaying the release? I don't know.
IMHO it is an important requirement. We're inviting a hailstorm of questions and annoyed users by breaking this well-known routine for checkouts.
I really think there is not a single good reason for having a different experience for checkouts vs tarballs. It would even lead to major annoyance where I work right now, just to give a real life example. For us, building out a development sandbox is the same process as building out a production instance, and for development buildouts we routinely want to just substitute checkous from a different tag/branch of Zope.
+1 on this. It is important for us in the "forced to be both developer and deployer by evil sysadmins" camp. /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
On Thu, Dec 22, 2005 at 08:37:22AM +0100, Dario Lopez-K?sten wrote:
+1 on this. It is important for us in the "forced to be both developer and deployer by evil sysadmins" camp.
I'm one of those guys too. I'm sure I can learn to live with the 2.9 release layout but right now it's just confusing. I think one reason people are just now starting to complain is that we had no idea this change was coming. Checkouts don't look any different, so it was a bit of a surprise to see such a big change in the tarball. I'm sure this was discussed in some thread somewhere but it evidently didn't register for me. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Thu, Dec 22, 2005 at 08:37:22AM +0100, Dario Lopez-K?sten wrote:
+1 on this. It is important for us in the "forced to be both developer and deployer by evil sysadmins" camp.
I'm one of those guys too. I'm sure I can learn to live with the 2.9 release layout but right now it's just confusing.
I think one reason people are just now starting to complain is that we had no idea this change was coming. Checkouts don't look any different, so it was a bit of a surprise to see such a big change in the tarball. I'm sure this was discussed in some thread somewhere but it evidently didn't register for me.
The tar ball looks the same (wrt configure/make/make install). It's the checkout that has changed. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Thu, Dec 22, 2005 at 01:51:40PM -0500, Jim Fulton wrote:
The tar ball looks the same (wrt configure/make/make install). It's the checkout that has changed.
Ah, sorry, I was talking about directory layout, and that's a different question (and not really a big deal). Didn't mean to go off on a tangent. As you were.... -- Paul Winkler http://www.slinkp.com
[Paul Winkler]
I think one reason people are just now starting to complain is that we had no idea this change was coming. Checkouts don't look any different, so it was a bit of a surprise to see such a big change in the tarball.
... [Jim Fulton]
The tar ball looks the same (wrt configure/make/make install). It's the checkout that has changed.
I'm sure Paul meant that the content of the tarball _looks_ very different now. Change is always disconcerting. I vividly recall that when ZODB switched to zpkgtools-based releases, we had messages from people staring at the tarball wondering where the ZODB code was -- including one from Jeremy ;-): http://mail.zope.org/pipermail/zodb-dev/2004-June/007483.html ... Also (and I say this realizing that I haven't followed zpkg development at all) is there any chance of getting a ZODB release where the code is in some obvious looking place? I'm sure I'm just confused because I'm used to the old way of doing things, but I initially thought I had grabbed the wrong thing because I couldn't find the source code. The better news is that those kinds of messages died out quickly, but it was certainly a shock at the start
Tim Peters wrote:
I'm sure Paul meant that the content of the tarball _looks_ very different now. Change is always disconcerting. I vividly recall that when ZODB switched to zpkgtools-based releases, we had messages from people staring at the tarball wondering where the ZODB code was --
[snip] I think it'd be nice to have the code in a more obvious place in the tarball. The current layout makes it a lot harder to inspect a release's source code without installing. I realize that after installation it looks like Python packages again, but perhaps it's a difference we can minimize somehow, as it is an place Zope stuff looks 'special' to the world, and not in our core business, which is web application framework stuff. Regards, Martijn
Jim Fulton wrote:
Martijn Faassen wrote: [snip] I'll note, FWIW, that we don't do installs from Zope 3 checkouts.
Yes, this is understood.
I think it's worth asking whether this is an important requirement.
Perhaps more generally, how important is it that the repository reflects the released version of the software, and how close can we get? First we'd need to agree on at least the principle that a checkout is ideally equivalent to a kind of 'sumo release' of Zope that includes everything, and builds as such, and acts like such a release. I realize that reaching such a point practically may be hard, just wondering if we can at least get some agreement on the ideal situation.
If it is, then we should make it work. Question is, is it worth delaying the release? I don't know.
It's not worth delaying the release, if at least in the release the dance continues to work, which I understand it does (and certainly did for the beta). I do think it's important though, but nothing is worth delaying the release and I expect fixing this would shake up things.
If we did stay with the current situation, we'd need to cleanup the documentation so that a developer can easily reminder herself what she can do and how to do it.
Yes, an obscure error is not very helpful, and I already know of several people who ran into it independently. Now there's this thread that people can find, but that won't be the case in the future... It'd be best the error message was a bit more clear, if at all possible, though I can imagine reaching that would also be hard. People won't be looking into the docs very quickly when they run into an obscure error, as this works with a release and you'd expect it to work with a checkout too -- this is an expectation people get from other projects. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
I'll note, FWIW, that we don't do installs from Zope 3 checkouts.
Yes, this is understood.
I think it's worth asking whether this is an important requirement.
Perhaps more generally, how important is it that the repository reflects the released version of the software, and how close can we get?
It was not a goal for Zope 3. I have often wondered if it should be.
First we'd need to agree on at least the principle that a checkout is ideally equivalent to a kind of 'sumo release' of Zope that includes everything, and builds as such, and acts like such a release.
Right. I don't have an opinion. I'd be interested to hear from others.
I realize that reaching such a point practically may be hard,
Maybe, don't know. I'll note that, at lease for Zope 3, I'd like to put a lot of this on the table. I'd like to revisit how we package and collect things, both for releases and for checkouts.
just wondering if we can at least get some agreement on the ideal situation.
That would be a good starting point.
If it is, then we should make it work. Question is, is it worth delaying the release? I don't know.
It's not worth delaying the release, if at least in the release the dance continues to work, which I understand it does (and certainly did for the beta).
I do think it's important though, but nothing is worth delaying the release and I expect fixing this would shake up things.
Are other OK with this approach?
If we did stay with the current situation, we'd need to cleanup the documentation so that a developer can easily reminder herself what she can do and how to do it.
Yes, an obscure error is not very helpful, and I already know of several people who ran into it independently.
Including me. I even submitted a collector issue. :)
Now there's this thread that people can find, but that won't be the case in the future...
It'd be best the error message was a bit more clear, if at all possible, though I can imagine reaching that would also be hard. People won't be looking into the docs very quickly when they run into an obscure error, as this works with a release and you'd expect it to work with a checkout too -- this is an expectation people get from other projects.
My suggestion is to have different README and INSTALL files for the checkout that tell people what they can do and how to do it and to change the install target to simply tell people that install isn't currently supported in a checkout and to read the appropriate text files. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
My suggestion is to have different README and INSTALL files for the checkout that tell people what they can do and how to do it and to change the install target to simply tell people that install isn't currently supported in a checkout and to read the appropriate text files.
Sounds like a reasonable idea. The bit of the install target pointing this out is essential, otherwise people will have no clue that the README and INSTALL are *different* in the checkout. On the longer term I hope we can work towards making them less different again. Regards, Martijn
Jeff Kowalczyk wrote:
I didn't receive any feedback on zope-general, but it could just be a problem with my environment that fails silently. Can anyone confirm that this isn't pilot error before I file a bug? Thanks.
From the thread, it's not a pilot error, so could you please file a bug if you haven't already? I at least consider commands that simply fail to work in development checkouts with obscure errors as a bug. I ran into this independently, and found this thread. If I had come by a few weeks later, I would likely not have found this thread, and I'd have asked the question again. If it at least said "hey, this doesn't work, try this instead" when you go 'make install', it'd be at least be something, though ideally any command that works in a release should also work in a development checkout. I understand that the reason for this is zpkg. It's not the first time that zpkg slams me right into the head for various reasons. Going into the wider story of packaging philosophy, I suspect there are arguments to be made in favor of making the difference between the repository and the distribution small. A distribution could be *smaller* than a repository, i.e. a profile of what's in the repository, but it'd be nice if structurally what's actually included in a distribution was the same as much as possible as what's in the repository. Regards, Martijn
participants (12)
-
Andreas Jung -
Andrew Sawyers -
Chris Withers -
Dario Lopez-Kästen -
Florent Guillaume -
Jeff Kowalczyk -
Jens Vagelpohl -
Jim Fulton -
Martijn Faassen -
Paul Winkler -
Stefan H. Holek -
Tim Peters