Re: SVN: Zope/trunk/ Merge philikon-zope32-integration branch. Basically, this branch entails:
Hi Philipp! Philipp von Weitershausen wrote:
Log message for revision 39848: Merge philikon-zope32-integration branch.
Great! This is a big step forward.
* Moved to a zpkgutils-based build system, as the Zope 3.2 extension modules require to be built with it. If everything goes ahead as planned, the release tarball will also be built with zpkgutils (some work has also been done in that direction).
That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox. And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up. Similar problems are reported here: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/12/... Is anybody working on resolving these issues? Cheers, Yuppie
yuppie wrote:
* Moved to a zpkgutils-based build system, as the Zope 3.2 extension modules require to be built with it. If everything goes ahead as planned, the release tarball will also be built with zpkgutils (some work has also been done in that direction).
That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox.
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did: $ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure $ make That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it. We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
Similar problems are reported here: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/12/...
Is anybody working on resolving these issues?
Well, problem is that I don't *see* this issue, so I wouldn't know how to do solve it. Philipp
Philipp von Weitershausen wrote:
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
Sorry, I meant $ python setup.py build_ext -i That's what "make all" does on Zope 3 and now on Zope 2 as well, it seems. And it's enough for an in-place build and IMHO all we need for an SVN checkout. Philipp
Hi Philipp! Philipp von Weitershausen wrote:
That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox.
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did:
$ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure
This fails if Python 2.4.2 is installed, but this worked: $ ./configure --with-python=/usr/bin/python2.4 [I see this is meanwhile fixed :)]
$ make
works and returns this message: Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory). following those instructions: $ make instance printf "Zope 2.8.0-b1" >\ "/Zope-trunk/lib/python/version.txt" "/usr/bin/python2.4" "/Zope-trunk/setup.py" \ build_ext -i \ install --skip-build --home="/Zope-trunk" running build_ext running build_headers running install running install_lib warning: install_lib: 'build/lib.linux-i686-2.4' does not exist -- no Python modules to install running install_headers [...] running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1 Same problems as reported by the buildbot. Renaming build/temp.linux-i686-2.4 to build/lib.linux-i686-2.4 and adding build/scripts-2.4 by hand made 'make instance' run.
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
Using $ python2.4 setup.py build_ext -i 'works', but doesn't create a complete instance. Did you try to start bin/zopectl? I don't even have a bin directory.
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it.
We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
Thanks for clarifying. Cheers, Yuppie
yuppie wrote:
Hi Philipp!
Philipp von Weitershausen wrote:
That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox.
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did:
$ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure
This fails if Python 2.4.2 is installed, but this worked:
$ ./configure --with-python=/usr/bin/python2.4
[I see this is meanwhile fixed :)]
$ make
works and returns this message:
Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory).
following those instructions:
$ make instance printf "Zope 2.8.0-b1" >\ "/Zope-trunk/lib/python/version.txt" "/usr/bin/python2.4" "/Zope-trunk/setup.py" \ build_ext -i \ install --skip-build --home="/Zope-trunk" running build_ext running build_headers running install running install_lib warning: install_lib: 'build/lib.linux-i686-2.4' does not exist -- no Python modules to install running install_headers [...] running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1
Same problems as reported by the buildbot.
I seem to remember that if you remove the --skip-build in that generated command line it works. I know it took me a while too, and that I was too busy trying to fix tests afterward to record what I did exactly. Anyway at least a build_scripts is missing somewhere. Florent
Renaming build/temp.linux-i686-2.4 to build/lib.linux-i686-2.4 and adding build/scripts-2.4 by hand made 'make instance' run.
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
Using
$ python2.4 setup.py build_ext -i
'works', but doesn't create a complete instance. Did you try to start bin/zopectl? I don't even have a bin directory.
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it.
We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
Thanks for clarifying.
Cheers,
Yuppie
-- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Philipp von Weitershausen wrote:
yuppie wrote:
* Moved to a zpkgutils-based build system, as the Zope 3.2 extension modules require to be built with it. If everything goes ahead as planned, the release tarball will also be built with zpkgutils (some work has also been done in that direction).
That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox.
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did:
$ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure $ make
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
You used to have to use "make instance" or "make inplace" to run the tests. These make commands no longer work. make inplace could probably be fixed by making it an alias for make build, since builds now seem to be in place.
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it.
I don't think that you or I have the authority to decide this. I'm not fond of configure/make myself, but the Community decided they wanted this a while ago. Of course they can change their mind.
We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways.
At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
It also lets you specify an install prefix. More importantly, it is a familiar model for unix systems.
Similar problems are reported here: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/12/...
Is anybody working on resolving these issues?
Well, problem is that I don't *see* this issue, so I wouldn't know how to do solve it.
If you looked carefully at the log, you would have seen that it was doing "make inplace", which you could easily verify doesn't work anymore. :) Anyway, I've changed the buildbot setup to use just "make" and we are now getting successful builds and tests. BTW, in case the tone of this message comes accross as negative, as others have said, we all really appreciate all of the great work you've done on getting Five 1.3 done and on getting Z3.2 into Z2! 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:
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did:
$ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure $ make
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
You used to have to use "make instance" or "make inplace" to run the tests. These make commands no longer work.
make inplace could probably be fixed by making it an alias for make build, since builds now seem to be in place.
Good idea.
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it.
I don't think that you or I have the authority to decide this.
You're quite right, I don't. I don't know what made me write this in indicative. Sorry for that. When Fred and I brainstormed about which implications a zpkg-based build for Zope 2 had, not being able to install out-of-place was one. Therefore the above paragraph should rather be read as a fact description, not an edict. IOW, rather than saying we're not going to support it anymore, I should really have said that the *current setup* doesn't support it which doesn't mean we can't bring it back.
We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways.
At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
It also lets you specify an install prefix.
python setup.py install --home=prefix let's you do that too.
More importantly, it is a familiar model for unix systems.
True. It is an unfamiliar model for Python software, though. Anyways, I don't think the ./configure script is the issue right now and I certainly don't feel strongly about it.
If you looked carefully at the log, you would have seen that it was doing "make inplace", which you could easily verify doesn't work anymore. :)
Ah, now I see it. I wasn't looking at the blue stuff on the top ;).
Anyway, I've changed the buildbot setup to use just "make" and we are now getting successful builds and tests.
Great!
BTW, in case the tone of this message comes accross as negative, as others have said, we all really appreciate all of the great work you've done on getting Five 1.3 done and on getting Z3.2 into Z2!
Thanks. I have to apologize for landing these features on the trunk without giving people a heads-up, though. I was eager to meet the feature-freeze deadline and didn't think about all the implications. Philipp
Philipp von Weitershausen wrote:
Jim Fulton wrote:
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did:
$ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure $ make
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
You used to have to use "make instance" or "make inplace" to run the tests. These make commands no longer work.
make inplace could probably be fixed by making it an alias for make build, since builds now seem to be in place.
Good idea.
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it.
I don't think that you or I have the authority to decide this.
You're quite right, I don't. I don't know what made me write this in indicative. Sorry for that. When Fred and I brainstormed about which implications a zpkg-based build for Zope 2 had, not being able to install out-of-place was one. Therefore the above paragraph should rather be read as a fact description, not an edict. IOW, rather than saying we're not going to support it anymore, I should really have said that the *current setup* doesn't support it which doesn't mean we can't bring it back.
We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways.
At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
It also lets you specify an install prefix.
python setup.py install --home=prefix let's you do that too.
More importantly, it is a familiar model for unix systems.
True. It is an unfamiliar model for Python software, though. Anyways, I don't think the ./configure script is the issue right now and I certainly don't feel strongly about it.
Most people who download Zope 2 are not Python programmers. Many of them become Python programmers later. I think this is a big part of Zope 2's value proposition that we haven't matched in Zope 3 yet. Having said that, I don't really like the configure/make farce myself. I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :) 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 11/4/05, Jim Fulton <jim@zope.com> wrote:
Having said that, I don't really like the configure/make farce myself.
Farce?
I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :)
I read through this post and I don't grok what the suggested alternative is. Could someone summarize? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Am Samstag, den 05.11.2005, 13:23 +0100 schrieb Lennart Regebro:
On 11/4/05, Jim Fulton <jim@zope.com> wrote:
Having said that, I don't really like the configure/make farce myself.
Farce?
I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :)
I read through this post and I don't grok what the suggested alternative is. Could someone summarize?
The usual setup.py from distutils to make it more pythonic. --Tino.
On 11/5/05, Tino Wildenhain <tino@wildenhain.de> wrote:
The usual setup.py from distutils to make it more pythonic.
The install.py in the root of the distribution is actually a conventional setup.py. Would it be helpful to keep the setup.py name? We renamed it to encourage the configure/make dance, but that doesn't seem particularly helpful to me. (It would also simplify the zpkg implementation just a tiny bit to use the setup.py. name.) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Society attacks early, when the individual is helpless." --B.F. Skinner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tino Wildenhain wrote:
Am Samstag, den 05.11.2005, 13:23 +0100 schrieb Lennart Regebro:
On 11/4/05, Jim Fulton <jim@zope.com> wrote:
Having said that, I don't really like the configure/make farce myself.
Farce?
I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :)
I read through this post and I don't grok what the suggested alternative is. Could someone summarize?
The usual setup.py from distutils to make it more pythonic.
distutils' support for applications, as opposed to libraries, is (still) pathetic. Sysadmins are the target audience for the installer, not Python programmers; './configure && make && sudo make install" is the classic pattern for them (which is why we do Zope2 this way now). - -1 to removing './configure'. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDbP/L+gerLs4ltQ4RAsz8AJ95axaWcLLWPMth0YMGybvBtNyGxACg07JQ wGjbN7v9/Xobabbap6vN9qQ= =Z9xs -----END PGP SIGNATURE-----
Tres Seaver wrote:
Sysadmins are the target audience for the installer, not Python programmers; './configure && make && sudo make install" is the classic pattern for them (which is why we do Zope2 this way now).
-1 to removing './configure'.
I agree with Tres and others. -1 on removing ./configure and the Makefile. It's expected by all sysadmins. And if setup.py works, then the Makefile should be just a few lines invoking it, so it's no real burden. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Lennart Regebro wrote:
On 11/4/05, Jim Fulton <jim@zope.com> wrote:
Having said that, I don't really like the configure/make farce myself.
Farce?
We aren't running the real configure. We aren't really using make. We're just using make as a wrapper around setup.py.
I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :)
I read through this post and I don't grok what the suggested alternative is.
Use the standard Python mechanism for installing things, for example, in a checkout: python setup.py build_ext -i 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 Sat, 2005-11-05 at 12:14 -0500, Jim Fulton wrote:
Lennart Regebro wrote:
On 11/4/05, Jim Fulton <jim@zope.com> wrote:
Having said that, I don't really like the configure/make farce myself.
Farce?
We aren't running the real configure.
If you mean autotools, that's right, but only because we don't really need it. Compiling Python has already done all the dirty work for us, so configure's main job is to find a suitable Python, which it does. Configure also checks the Python it finds for large file support and Python's zlib module, which is required by some bits of Zope but not in every system-shipped Python. These things might seem silly to developers but they've saved a lot of new users from pain. "configure" also allows you to install multiple times from a "pristine" source directory without changing the source directory, which I (and others, because they've told me they do) make use of.
We aren't really using make.
Actually we are. We create a makefile, which is run by make when you type "make" (no different than if autotools had created the makefile).
We're just using make as a wrapper around setup.py.
The makefile is a wrapper around setup.py as well as mkzopeinstance. It is also capable of creating release tarballs. -1 on removing configure / make / make install dance unless there is some reason to do so other than not being "pythonic". - C
--On 5. November 2005 21:41:54 -0500 Chris McDonough <chrism@plope.com> wrote:
The makefile is a wrapper around setup.py as well as mkzopeinstance. It is also capable of creating release tarballs.
-1 on removing configure / make / make install dance unless there is some reason to do so other than not being "pythonic".
Also -1 from me. There was little need in the past to touch the script so it not a big burden from the maintenance point of view. It would be nice to have something similar Python-based as a replacement but that's nice2have. I can live perfectly with current solution. Andreas
On 6 Nov 2005, at 03:41, Chris McDonough wrote:
"configure" also allows you to install multiple times from a "pristine" source directory without changing the source directory, which I (and others, because they've told me they do) make use of.
I use that a lot myself. -1 for removing it from me as well. jens
--On 4. November 2005 11:27:10 -0500 Jim Fulton <jim@zope.com> wrote:
Most people who download Zope 2 are not Python programmers. Many of them become Python programmers later. I think this is a big part of Zope 2's value proposition that we haven't matched in Zope 3 yet.
Having said that, I don't really like the configure/make farce myself. I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :)
Unless you have time enough I would keep it :-) From my experience using configure was never a problem - neither for newbies nor advanced Zope users. People unable to run "configure; make" are also likely unable to run any other kind of command to perform the same task. -aj
Andreas Jung wrote:
--On 4. November 2005 11:27:10 -0500 Jim Fulton <jim@zope.com> wrote:
Most people who download Zope 2 are not Python programmers. Many of them become Python programmers later. I think this is a big part of Zope 2's value proposition that we haven't matched in Zope 3 yet.
Having said that, I don't really like the configure/make farce myself. I'd be happy to get rid of it. I'm also happy to defer to the vocal majority. Maybe it's worth revisiting this, which is why the provocative subject. :)
Unless you have time enough I would keep it :-)
Time enough for what? configure/make is just extra maintenance burden.
From my experience using configure was never a problem
It was a problem this week. :)
- neither for newbies nor advanced Zope users. People unable to run "configure; make" are also likely unable to run any other kind of command to perform the same task.
I wasn't arguing that configure/make was hard to use. I'm arguing that it's something extra to maintain and is just silly. It's main benefit is that it leverages a familiar pattern, but I'm not convinced that it's worth it. Also, as tools like rpm and deb become more widely used, I'm not sure how familar the configure/make dance is. Other than Python and Zope, I never use configure/make anymore. 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 11/5/05, Jim Fulton <jim@zope.com> wrote:
It's main benefit is that it leverages a familiar pattern, but I'm not convinced that it's worth it. Also, as tools like rpm and deb become more widely used, I'm not sure how familar the configure/make dance is. Other than Python and Zope, I never use configure/make anymore.
I think more and more people never have to build from source. There's little I build from source these days, and I'm generally happy to build myself. I think the only things I build are things I'm actually contributing to myself, whether it be for work or volunteering on open source projects. I don't even build my own TeX tools any more. :-) Also, configure/make is only familiar in the Unix world; most installations appearantly are on Windows boxes using the binary installer. The importance of the familiar dance just isn't very significant any more. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Society attacks early, when the individual is helpless." --B.F. Skinner
I wasn't arguing that configure/make was hard to use. I'm arguing that it's something extra to maintain and is just silly.
It's main benefit is that it leverages a familiar pattern, but I'm not convinced that it's worth it. Also, as tools like rpm and deb become more widely used, I'm not sure how familar the configure/make dance is. Other than Python and Zope, I never use configure/make anymore.
My experience is that .rpm and .deb packages are poorly maintained, so if someone is serious about using Zope and related products, downloading and installing from source is the only way to go. We also have tools internally that depend on the configure/make dance, and I'm sure others who put up a lot of Zope instances do as well.. :) -Morten
participants (12)
-
Andreas Jung -
Chris McDonough -
Florent Guillaume -
Fred Drake -
Jens Vagelpohl -
Jim Fulton -
Lennart Regebro -
Morten W. Petersen -
Philipp von Weitershausen -
Tino Wildenhain -
Tres Seaver -
yuppie