Sorry if this has been asked hundreds of times before — I couldn't find any info on this apart from the Summer of Code project related to Zope 3. Will Zope 2 ever run on Python 2.5, or is that postponed indefinitely? We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default. -- Alexander Limi · http://limi.net
Hi Limi, Alexander Limi wrote:
Sorry if this has been asked hundreds of times before — I couldn't find any info on this apart from the Summer of Code project related to Zope 3.
Now only the packages under `zope` & `zope.app` packages works using Python 2.5 . I don't know the status of packages in `zc`, `z3c` and other namespaces. I also heard Grok is working fine with Python 2.5, but not yet officially blessed/supported.
Will Zope 2 ever run on Python 2.5, or is that postponed indefinitely? We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default.
Nikhil, who worked on Python 2.5 porting of Zope 3, told me that he will be working Zope 2 porting after his exams. Nikhil, can you send the status to this list ? Well, now you are not a GSoC student, so, this question is not official ;) Regards, Baiju M
Baiju M wrote:
Hi Limi,
Alexander Limi wrote:
Sorry if this has been asked hundreds of times before — I couldn't find any info on this apart from the Summer of Code project related to Zope 3.
Now only the packages under `zope` & `zope.app` packages works using Python 2.5 . I don't know the status of packages in `zc`, `z3c` and other namespaces. I also heard Grok is working fine with Python 2.5, but not yet officially blessed/supported.
Indeed. The biggest problem that's preventing us from officially blessing Python 2.5 as *a* supported platform is a MemoryError on 64 bit Linux systems. Possibly https://bugs.edge.launchpad.net/zodb/+bug/153316 is related to this as well (another issue that's only a problem on 64 bit).
Will Zope 2 ever run on Python 2.5, or is that postponed indefinitely? We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default.
Nikhil, who worked on Python 2.5 porting of Zope 3, told me that he will be working Zope 2 porting after his exams.
That's great news. -- http://worldcookery.com -- Professional Zope documentation and training
Hi all, On 11/1/07, Baiju M <mbaiju@zeomega.com> wrote:
Alexander Limi wrote:
Will Zope 2 ever run on Python 2.5, or is that postponed indefinitely? We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default.
Nikhil, who worked on Python 2.5 porting of Zope 3, told me that he will be working Zope 2 porting after his exams. Nikhil, can you send the status to this list ?
I was busy with my exams for some time. Now I will be continuing the porting of Zope2 which I have started earlier. Along with this the Restricted Python part (as replied to Tres earlier) and issues in C API will also be looked after. Regards, Nikhil
--On 31. Oktober 2007 20:26:11 -0700 Alexander Limi <limi@plone.org> wrote:
Sorry if this has been asked hundreds of times before — I couldn't find any info on this apart from the Summer of Code project related to Zope 3.
Will Zope 2 ever run on Python 2.5, or is that postponed indefinitely?
Still RestrictedPython does not work with Python 2.5+ afaik. I think this is the most important blocker.
We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default.
The recommendation is still "System python is evil, evil, evil" (quoting Jim). -aj
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do: easy_install plone to get their Plone site, it's a necessary evil evil evil. ;) We generally encourage not to use the system Python in everything we ship (Windows, Mac and Unified installers all ship their own Python) — but I really hope we won't be stuck with Python 2.4 after the world has moved on to Python 2.5 and 2.6. I agree that for proper deployments, you shouldn't use the system Python, but there's the case of letting people get started with Plone easily from their Ubuntu or Mac OS X (Leopard ships with Python 2.5 and easy_install by default) — we should be able to let them do that too. -- Alexander Limi · http://limi.net
--On 31. Oktober 2007 22:00:46 -0700 Alexander Limi <limi@plone.org> wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
Would be fine but as long as several distros contain brain-dead or castrated Python installations there is little we can do - even if we would support Python 2.5.
to get their Plone site, it's a necessary evil evil evil. ;)
We generally encourage not to use the system Python in everything we ship (Windows, Mac and Unified installers all ship their own Python) — but I really hope we won't be stuck with Python 2.4 after the world has moved on to Python 2.5 and 2.6.
Bring the word to the Python packagers.
I agree that for proper deployments, you shouldn't use the system Python, but there's the case of letting people get started with Plone easily from their Ubuntu or Mac OS X (Leopard ships with Python 2.5 and easy_install by default) — we should be able to let them do that too.
See above. Stepping forward with Python 2.5/2.6 support would be fine but it basically does not solve the problem that system python installation are often broken. Installation a Python from the sources is usually much more faster than trying to figure out why a system python is broken once more.
On Thursday 01 November 2007 06:18:18 Andreas Jung wrote:
--On 31. Oktober 2007 22:00:46 -0700 Alexander Limi <limi@plone.org> wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
Would be fine but as long as several distros contain brain-dead or castrated Python installations there is little we can do - even if we would support Python 2.5.
I always wondered -- I never had any trouble with the system Pythons, or at least not a problem that I could attribute to a system Python (Debian Stable and Ubuntu LTS) Its just so damn convenient if you have to maintain a few dozen VServers to manage the Pythons including add-on libraries exclusively via "apt-get" Which system Pythons do you think are brain dead, and why? Thanks, peter.
to get their Plone site, it's a necessary evil evil evil. ;)
We generally encourage not to use the system Python in everything we ship (Windows, Mac and Unified installers all ship their own Python) — but I really hope we won't be stuck with Python 2.4 after the world has moved on to Python 2.5 and 2.6.
Bring the word to the Python packagers.
I agree that for proper deployments, you shouldn't use the system Python, but there's the case of letting people get started with Plone easily from their Ubuntu or Mac OS X (Leopard ships with Python 2.5 and easy_install by default) — we should be able to let them do that too.
See above. Stepping forward with Python 2.5/2.6 support would be fine but it basically does not solve the problem that system python installation are often broken. Installation a Python from the sources is usually much more faster than trying to figure out why a system python is broken once more.
On 11/1/07, Peter Sabaini <peter@sabaini.at> wrote:
I always wondered -- I never had any trouble with the system Pythons, or at least not a problem that I could attribute to a system Python (Debian Stable and Ubuntu LTS)
Well, try and easy_install i18ndude, and see all your Zope2 instances explode. :-) Even if the system python is nice, as on Ubuntu, you may end up in the situation where you need different versions of modules for the Zope pythons and the system pythons. And although it's fixable after the fact, remeber, you wont see the problem until you restart the zope, and then you forgot what you did, and don't understand suddenly why nothing works. And in worse case, you might after a server restart notice that all of your Zope instances suddenly do not work. And it takes a couple of hours to figure out why and fix it. Downtime you don't want.
Its just so damn convenient if you have to maintain a few dozen VServers to manage the Pythons including add-on libraries exclusively via "apt-get"
Yeah, I haven't found a good solution for that yet. I those libraries should be available as eggs, that solves it. But not all are... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
--On 31. Oktober 2007 22:00:46 -0700 Alexander Limi <limi@plone.org> wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
One other point: "easy_install plone" make only sense if the underlying machinery generates an isolated environment for your Plone instance. You really don't want to mess up your system python with a hundred Zope or Plone eggs. This is definitely the road to disaster. On distributions that depends on Python for their internal processing/administration (I think Fedora does) you might break the functionality of your system installation significantly in case of broken or misbehaving eggs. So we must be careful about the story we're telling the users. The obviously easiest way is possibly not the best way (in the long term). Andreas
On Nov 1, 2007, at 1:28 AM, Andreas Jung wrote:
--On 31. Oktober 2007 22:00:46 -0700 Alexander Limi <limi@plone.org> wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
One other point: "easy_install plone" make only sense if the underlying machinery generates an isolated environment for your Plone instance. You really don't want to mess up your system python with a hundred Zope or Plone eggs. This is definitely the road to disaster. On distributions that depends on Python for their internal processing/administration (I think Fedora does) you might break the functionality of your system installation significantly in case of broken or misbehaving eggs. So we must be careful about the story we're telling the users. The obviously easiest way is possibly not the best way (in the long term).
I think installing into a virtualenv created by a system Python is at least 50% less evil than installing packages directly into the system Python, and reasonable for a development environment, at least in semi- controlled situations (like Apple's Python). - C
Would it be possible to have a non-system python installed (by default into /opt/python24) by the system python easy_install? I think it would be useful to have eggs that provide commands on the path such as easy_install_nonsystem24, virtualenv_nonsystem24, python_nonsystem24. With a better spelling, of course. Perhaps if non-system pythons were packaged in a way that setuptools could install them, they might become ordinary dependencies of Zope/Plone eggs, which could detect and configure to use them in a virtualenv at setup time. I don't know if setuptools is currently capable of installing packages completely separate from the running environment, or executing another python during setup. However, It seems to me that the most expedient way to encourage widespread use of non-system python is to make them available as a dependency for applications and frameworks that prefer them. After my distribution (Gentoo) updated to python2.5, I made the overdue switch to a buildout-based non-system python. I greatly appreciate the fact that it has no packages installed and never changes, obliging me to use buildout or virtualenv always. I'd like to have the best-practice setup available as an easy_installable package. On my distribution, tools are already available to package complete/correct PyPI entries. Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Kowalczyk wrote:
Would it be possible to have a non-system python installed (by default into /opt/python24) by the system python easy_install? I think it would be useful to have eggs that provide commands on the path such as easy_install_nonsystem24, virtualenv_nonsystem24, python_nonsystem24. With a better spelling, of course.
Perhaps if non-system pythons were packaged in a way that setuptools could install them, they might become ordinary dependencies of Zope/Plone eggs, which could detect and configure to use them in a virtualenv at setup time.
I don't know if setuptools is currently capable of installing packages completely separate from the running environment, or executing another python during setup. However, It seems to me that the most expedient way to encourage widespread use of non-system python is to make them available as a dependency for applications and frameworks that prefer them.
After my distribution (Gentoo) updated to python2.5, I made the overdue switch to a buildout-based non-system python. I greatly appreciate the fact that it has no packages installed and never changes, obliging me to use buildout or virtualenv always.
I'd like to have the best-practice setup available as an easy_installable package. On my distribution, tools are already available to package complete/correct PyPI entries.
'virtualenv' installs setuptools (and therefore 'easy_install') into the newly-created environment, which means that you don't use the "system" easy_install at all (except perhaps to bootstrap 'virtualenv' itself). E.g.: $ sudo /usr/bin/easy_install virtualenv ... $ /usr/bin/virtualenv /path/to/my/app $ /path/to/my/app/bin/easy_install foobar Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHK1SC+gerLs4ltQ4RArEdAKC8kI7GqL9/xfs2eEQlBzrp37oN0gCfTqtq YDjBHcqqh+Z3YUAUz6eNnOc= =dJzs -----END PGP SIGNATURE-----
--On 1. November 2007 23:47:28 -0400 Chris McDonough <chrism@plope.com> wrote:
On Nov 1, 2007, at 1:28 AM, Andreas Jung wrote:
--On 31. Oktober 2007 22:00:46 -0700 Alexander Limi <limi@plone.org> wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
One other point: "easy_install plone" make only sense if the underlying machinery generates an isolated environment for your Plone instance. You really don't want to mess up your system python with a hundred Zope or Plone eggs. This is definitely the road to disaster. On distributions that depends on Python for their internal processing/administration (I think Fedora does) you might break the functionality of your system installation significantly in case of broken or misbehaving eggs. So we must be careful about the story we're telling the users. The obviously easiest way is possibly not the best way (in the long term).
I think installing into a virtualenv created by a system Python is at least 50% less evil than installing packages directly into the system Python, and reasonable for a development environment, at least in semi-controlled situations (like Apple's Python).
Sure, but users that don't know about virtualenv might run into such problems. Andreas
Alexander Limi wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
to get their Plone site, it's a necessary evil evil evil. ;)
I don't think the System Python argument is the most important here. It's more important that Python 2.4 will start looking unsupported and third party libraries will start depending on Python 2.5 before long, if not already. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Nov 1, 2007, at 1:00 AM, Alexander Limi wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
to get their Plone site, it's a necessary evil evil evil. ;)
So don't do that. Plone is an application (afaik) not a library. I thought Plone had an installer that installed a local Python.
We generally encourage not to use the system Python in everything we ship (Windows, Mac and Unified installers all ship their own Python)
Cool. Note that I think this problem will get worse as system packages include more and more of the packages we use. I read yesterday that the Python in Mac OS X Leopard includes zope.interface.
— but I really hope we won't be stuck with Python 2.4 after the world has moved on to Python 2.5 and 2.6.
This is really a separate issue. I hope we won't either. Unfortunately, supporting them is non-trivial, I think we've made a lot of progress.
I agree that for proper deployments, you shouldn't use the system Python, but there's the case of letting people get started with Plone easily from their Ubuntu or Mac OS X (Leopard ships with Python 2.5 and easy_install by default) — we should be able to let them do that too.
I don't agree. easy_install is really not well suited to installing applications IMO. I think an installer is a better idea for installing applications, for lots of reasons. Jim -- Jim Fulton Zope Corporation
On Nov 1, 2007, at 14:17 , Jim Fulton wrote:
We generally encourage not to use the system Python in everything we ship (Windows, Mac and Unified installers all ship their own Python)
Cool. Note that I think this problem will get worse as system packages include more and more of the packages we use. I read yesterday that the Python in Mac OS X Leopard includes zope.interface.
Yes, that's true. It's included (version 3.3.0) because Twisted needs it, which is also part of the standard OS X 10.5 Python installation. From what I heard Twisted is used for the OS X Server CalDAV service. From a sysadmin view I'd be afraid that careless use of easy_install for the system Python has the potential to break such built-in OS X applications. Another reason not to use the system Python. jens
I would like to point out that on this thread people are getting too tied up with restrictions about *installing* stuff on the system Python and forgetting that for example, buildout will not install stuff on the system Python, but people might want to run a Zope (2) buildout on Python 2.5 just because it's the Python they have installed. Now, putting Limi's proven incapability to start a discussion without causing major commotion from our fellow developers, let's rephrase the question: Will Zope 2 be supported on Python 2.5, regardless of whether it's a system-installed Python or not? I think we are closely approaching the EOL for Python 2.4. Supposedly when Python 2.6 comes out next year Python 2.4 will be officially discouraged and will not receive any more fixes other than security fixes. I believe this is a critical issue and the interested parts need to work together on it. Maybe the Plone Foundation and the Zope Foundation can work together and setup a bounty to fund some developer to do this work? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
On Nov 1, 2007, at 9:50 AM, Sidnei da Silva wrote:
I would like to point out that on this thread people are getting too tied up with restrictions about *installing* stuff on the system Python and forgetting that for example, buildout will not install stuff on the system Python, but people might want to run a Zope (2) buildout on Python 2.5 just because it's the Python they have installed.
Agreed. I almost mentioned this as an "otoh" in one of my previous posts. I think buildout should work harder to get along with system Python. I intent to spend some effort on this. Martijn has suggested an option to ignore site-packages which may go a long way. Of course, this has nothing to do with 2.5. :) Jim -- Jim Fulton Zope Corporation
On Thursday 01 November 2007, Jim Fulton wrote:
I think buildout should work harder to get along with system Python. I intent to spend some effort on this. Martijn has suggested an option to ignore site-packages which may go a long way.
Yeah, one of my clients uses workingenv to use system python without all the additional site-packages and then uses this workingenv's python executable for buildout. It would be great, if he would not need to use workingenv in this case. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote:
On Thursday 01 November 2007, Jim Fulton wrote:
I think buildout should work harder to get along with system Python. I intent to spend some effort on this. Martijn has suggested an option to ignore site-packages which may go a long way.
Yeah, one of my clients uses workingenv to use system python without all the additional site-packages and then uses this workingenv's python executable for buildout. It would be great, if he would not need to use workingenv in this case.
I think that virtualenv is the right answer for folks who need to reuse the system python, but be insulated from its site-packages (and be able to install their own packages without touching the system environment. Ian Bicking, who authored workingenv, has basically dropped further development on it in favor of virtualenv. repoze.project uses virtualenv to create "sandboxed" Python environments, into which the custom packages are then installed, followed by the installation of scripts, config files, etc. to make the environment ready to run the given application (Zope2, Plone, Grok to date). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKgjv+gerLs4ltQ4RAvxcAKDHpgsyLkDDupW2JrIQvkZ2KM0mqwCfUEqA 47SlPfsBg62jXGKJ3ubSn64= =qKXa -----END PGP SIGNATURE-----
Hey, [making Zope 2 work on Python 2.5] Sidnei da Silva wrote: [snip]
I believe this is a critical issue and the interested parts need to work together on it. Maybe the Plone Foundation and the Zope Foundation can work together and setup a bounty to fund some developer to do this work?
That's an idea that certainly deserves some exploration! The Zope Foundation awaits the Plone Foundation's proposals for something like this with great anticipation! Note that I explicitly put the ball to initiate these discussions in their court, as it appears that the Plone project feels a particular urgency here, Alexander Limi having kicked off this discussion. This could finally start some cooperation between the two foundations, something I've been hoping would happen for a long time now. Now we have something concrete. Note that the Zope Foundation indirectly has supported topic a bit, thanks to the summer of code. Nikhil, the summer of code student, worked on supporting the Zope (3) libraries on Python 2.5 already. Nikhil apparently already wants to work on this project. Regards, Martijn
On 11/1/07, Sidnei da Silva <sidnei@enfoldsystems.com> wrote:
I think we are closely approaching the EOL for Python 2.4. Supposedly when Python 2.6 comes out next year Python 2.4 will be officially discouraged and will not receive any more fixes other than security fixes.
This seems to be a common misconception; I'm not sure why. Python 2.4 has *already* hit EOL. There will only be security fixes released in source form. When a new Python 2.X is released, a final 2.X-1 bugfix release is made and 2.X becomes the maintenance release. 2.X-1 gets critical security fixes only. The unreleased trunk becomes the development version. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On 11/1/07, Fred Drake <fdrake@gmail.com> wrote:
This seems to be a common misconception; I'm not sure why.
Python 2.4 has *already* hit EOL. There will only be security fixes released in source form.
When a new Python 2.X is released, a final 2.X-1 bugfix release is made and 2.X becomes the maintenance release. 2.X-1 gets critical security fixes only. The unreleased trunk becomes the development version.
Ouch. I guess we should skip 2.5 and target 2.6 then to save some time :) -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
Alexander Limi wrote:
On Wed, 31 Oct 2007 21:29:36 -0700, Andreas Jung <lists@zopyx.com> wrote:
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Sure, but if you ever want to be able to tell users to do:
easy_install plone
to get their Plone site, it's a necessary evil evil evil. ;)
We generally encourage not to use the system Python in everything we ship (Windows, Mac and Unified installers all ship their own Python) — but I really hope we won't be stuck with Python 2.4 after the world has moved on to Python 2.5 and 2.6.
Agreed. Of course we'll still be stuck on Python 2.x for what amounts to indefinitely when Python 3.x comes out, but that is another problem for the future. I agree that something like this is a necessary evil. I don't think easy_install plone should ever be the way to install it, unless this installs a 'ploneproject' that creates buildouts for you and then installs everything non-globally. Nonetheless, this should be possible with the system Python, just so people can try things out easily. Anyway, perhaps some of the Plone people could volunteer in fixing up Zope 2 for Python 2.5 then? Regards, Martijn
On Nov 1, 2007, at 12:29 AM, Andreas Jung wrote: ....
We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default.
The recommendation is still "System python is evil, evil, evil" (quoting Jim).
Noooo, that's "evil evil evil evil". Geez. ;) Or maybe it should be "stupid stupid ....". Jim -- Jim Fulton Zope Corporation
Alexander Limi wrote:
Will Zope 2 ever run on Python 2.5, or is that postponed indefinitely?
It will run on Python 2.5 when somebody makes it run.
We see an increasing amount of users trying to use Zope 2 with their systems that have Python 2.5 as default.
Then I suggest you do something about it. Making it a sprint topic on one of the numerous Plone sprints would help, for instance. As far as I can remember, Nikhil (our GSoC student) looked at making RestrictedPython work on Python 2.5. Somebody should review this. Moreover, there are lots C extension that -- last time I checked -- just failed to compile on Python 2.5. Though I'm sure most of these problems could be fixed by applying suggested replacements in the Python 2.5 release notes. -- http://worldcookery.com -- Professional Zope documentation and training
participants (17)
-
Alexander Limi -
Andreas Jung -
Baiju M -
Chris McDonough -
Fred Drake -
Jeff Kowalczyk -
Jens Vagelpohl -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Nikhil N -
Peter Sabaini -
Philipp von Weitershausen -
Sidnei da Silva -
Stephan Richter -
Tres Seaver