Re: [Zope3-dev] Re: AW: relying on win32api in windows support ofzc.zope3recipes
Hey, On 8/17/07, Sidnei da Silva <[EMAIL PROTECTED]> wrote: > On 8/17/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: > > > If an egg is the only way to install dependencies, then I would say > > > that buildout needs more work. From what I understand it would be > > > extremely hard to eggify pywin32. > > > > It's not the only way, but it's definitely the preferred way. A > > click-through windows installer is definitely *not* the preferred way. > > My guess is that you don't have much of a clue about how distutils > work, more below. :) Huh? > > Is there way to install pywin32 by grabbing some .dlls online and them > > in the right place? (wherever that would be, I guess we'd have a > > custom part). We can write a recipe that does that. > > PyWin32 does use distutils, but it has a ton custom code. I haven't > tried to build an egg, but my guess is that it might work > out-of-the-box actually. > As for the result of distutils 'bdist_wininst' which is what PyWin32 > and many other things out there that provide a installer for Windows > use, it is basically a ZIP file with a executable header, just like > those self-extracting files created by WinZip and similar apps. So you > can unzip the PyWin32 installer and copy the binary files and .py > files to the right locations, then it should Just Work (TM). And PyWin32's installer is the result of a bdist_wininst? I didn't know the pywin32 installer was created using bdist_wininst, and I didn't know that bdist_wininst creates a zipfile. Is this what makes you guess I don't have a clue about how distutils works in general? Anyway, that's good news. > > Why is it extremely hard to eggify pywin32? I guess it doesn't use > > distutils? If it's such a useful if not essential requirement on > > windows, why doesn't it work with the python installation > > infrastructure? > > The python installation infrastructure is still distutils, not eggs. > > PyWin32 creates entries in the Start Menu for the documentation and > PythonWin for example. I don't think that would work with eggs. But in > the case of just getting the binaries in place, then an egg might > actually be feasible. We're just talking about Zope here, and installing Zope into its own buildout (possibly sharing eggs with another). This means we don't care much about installing the documentation anyway, just having the libraries importable so that Zope can do its work on windows. Of course it's possible just having the dlls on the path might not be good enough - perhaps some (say) registry manipulation is needed in order to make them work properly. Do you know whether such might be the case? You're giving me the impression here that it might be less than extremely hard to eggify pywin32 for our particular use cases. Anyway, even if it turns out too hard to get an egg going, the zipfile-ish nature of the installer gives me hope that we can at least write a custom recipe that installs the dlls into a part. Of course we'd need some logic that manipulated the environment in buildout-generated scrips so that these dlls can be accessed from them.. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AW: relying on win32api in windows support ofzc.zope3recipes
On 8/17/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: > > If an egg is the only way to install dependencies, then I would say > > that buildout needs more work. From what I understand it would be > > extremely hard to eggify pywin32. > > It's not the only way, but it's definitely the preferred way. A > click-through windows installer is definitely *not* the preferred way. My guess is that you don't have much of a clue about how distutils work, more below. :) > Is there way to install pywin32 by grabbing some .dlls online and them > in the right place? (wherever that would be, I guess we'd have a > custom part). We can write a recipe that does that. PyWin32 does use distutils, but it has a ton custom code. I haven't tried to build an egg, but my guess is that it might work out-of-the-box actually. As for the result of distutils 'bdist_wininst' which is what PyWin32 and many other things out there that provide a installer for Windows use, it is basically a ZIP file with a executable header, just like those self-extracting files created by WinZip and similar apps. So you can unzip the PyWin32 installer and copy the binary files and .py files to the right locations, then it should Just Work (TM). > Why is it extremely hard to eggify pywin32? I guess it doesn't use > distutils? If it's such a useful if not essential requirement on > windows, why doesn't it work with the python installation > infrastructure? The python installation infrastructure is still distutils, not eggs. PyWin32 creates entries in the Start Menu for the documentation and PythonWin for example. I don't think that would work with eggs. But in the case of just getting the binaries in place, then an egg might actually be feasible. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AW: relying on win32api in windows support ofzc.zope3recipes
Hey, On 8/17/07, Sidnei da Silva <[EMAIL PROTECTED]> wrote: > On 8/17/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: > > I am fine with requiring win32api, though it'd be better if it were > > indeed installable from the python package index. Otherwise you need to > > tell people to install two things (Python and win32api) instead of one > > thing on Windows in order to be able to install Zope 3. Who will > > volunteer to bug Mark Hammond? Perhaps Sidnei can, he's a Windows native. :) > > I would say pywin32 is a requirement for anyone that wants to do > anything useful on Windows. I've programmed a game using pygame and it works in Windows. Perhaps games aren't "useful"? :) > If an egg is the only way to install dependencies, then I would say > that buildout needs more work. From what I understand it would be > extremely hard to eggify pywin32. It's not the only way, but it's definitely the preferred way. A click-through windows installer is definitely *not* the preferred way. Is there way to install pywin32 by grabbing some .dlls online and them in the right place? (wherever that would be, I guess we'd have a custom part). We can write a recipe that does that. Why is it extremely hard to eggify pywin32? I guess it doesn't use distutils? If it's such a useful if not essential requirement on windows, why doesn't it work with the python installation infrastructure? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AW: relying on win32api in windows support ofzc.zope3recipes
On 8/17/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: > I am fine with requiring win32api, though it'd be better if it were > indeed installable from the python package index. Otherwise you need to > tell people to install two things (Python and win32api) instead of one > thing on Windows in order to be able to install Zope 3. Who will > volunteer to bug Mark Hammond? Perhaps Sidnei can, he's a Windows native. :) I would say pywin32 is a requirement for anyone that wants to do anything useful on Windows. If an egg is the only way to install dependencies, then I would say that buildout needs more work. From what I understand it would be extremely hard to eggify pywin32. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: relying on win32api in windows support ofzc.zope3recipes
Hey Roger,
Roger Ineichen wrote:
[snip]
Was the original way to run Zope 3 trunk dependent on win32api?
I guess, but I'm not sure;
Python 2.5 includes ctypes which could be used as a
replacement for the win32 part.
I am fine with requiring win32api, though it'd be better if it were
indeed installable from the python package index. Otherwise you need to
tell people to install two things (Python and win32api) instead of one
thing on Windows in order to be able to install Zope 3. Who will
volunteer to bug Mark Hammond? Perhaps Sidnei can, he's a Windows native. :)
To some previous questions in this thread.
I'm fine with any improvements and doctest cleanup. My
problem was, that I couldn't really merge the linux tests
into one document because I didn't had a linux box
when I wrote the implementation for testing.
Right, testing on multiple platforms isn't easy. I had the same problem
but in reverse - trouble getting it set up in Windows.
I agree with the maintainance overhead. That's bad.
I also recognized the buildout difference in the tests. I guess
the egg version is older then the version then I used from the
trunk. I guess again, I think Jim did some improvments in
buildout and didn't change the tests in zope3recipe.
Could this be the case?
The more I look into it, the less I understand. I've just confirmed that
on Linux and Windows both, the test runner is using zc.buildout-1.0.0b28
- the same version.
The Windows tests run successfully for me with that buildout version. So
do the Linux tests!
On Windows I do get a lot of output involving import errors of 'tests'
modules from various eggs (zdaemon, zope.testing, zconfig, etc,
basically it seems any package on the path). I already reported this
behavior to Jim. Did you see this too? Anyway, this did not appear to
have affected the finding or running of the tests themselves on Windows.
It isn't some other egg either, you'd think: the sys.path setting in the
'test' script points to the exact same versions of the eggs on both
platforms:
sys.path[0:0] = [
'/home/faassen/buildout/zc.zope3recipes',
'/home/faassen/buildout-eggs/zope.testing-3.5.1-py2.4.egg',
'/home/faassen/bin/eggs/setuptools-0.6c6-py2.4.egg',
'/home/faassen/buildout-eggs/zc.recipe.filestorage-1.0a5-py2.4.egg',
'/home/faassen/buildout-eggs/zdaemon-2.0.0-py2.4.egg',
'/home/faassen/buildout-eggs/ZConfig-2.4a6-py2.4.egg',
'/home/faassen/buildout-eggs/zc.recipe.egg-1.0.0b6-py2.4.egg',
'/home/faassen/bin/eggs/zc.buildout-1.0.0b28-py2.4.egg',
]
This is very mysterious. The Linux tests expect lines like this:
Generated script '/sample-buildout/bin/instance'.
And the Windows tests expect that line not to be there.
Also, the Linux tests have this sequence:
>>> print system(join('bin', 'buildout')),
Develop: '/sample-buildout/demo1'
Develop: '/sample-buildout/demo2'
Updating database.
Updating myapp.
Updating instance.
Installing instance2.
Generated script '/root/etc/init.d/myapp-run-instance2'.
And the Windows tests expect this:
>>> print system(join('bin', 'buildout')),
Develop: '/sample-buildout/demo1'
Develop: '/sample-buildout/demo2'
Uninstalling instance.
Updating database.
Updating myapp.
Installing instance.
Installing instance2.
Generated script '/root/etc/init.d/myapp-run-instance2'.
Where Linux has "Updating instance", Windows has "Uninstalling instance"
and then following it "Installing instance".
Oddly enough the "Generated script" bit *is* expected in Windows here
(as in many other places).
I really don't understand what's going on here at all and it's no wonder
you also had issues.
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
