From mcarey at osoft.com Wed Feb 2 18:15:50 2005 From: mcarey at osoft.com (Mark D. Carey) Date: Wed Feb 2 18:15:59 2005 Subject: [Distutils] Python Documentation in ThoutReader format Message-ID: <20050202171557.1BAFF1E4003@bag.python.org> Dear Fred, Guido, and the rest of the Python Documentation Team, I am part of a small group of developers that distributes the ThoutReader?, an open source documentation platform that allows developers to browse, search, bookmark, and append their open source documentation as well as favorite reference books, at the same time, in one format, even off line. The ThoutReader? is a cross-platform application written in Java, licensed under GPL 2.0, and hosted on SourceForge. A large international web hosting company asked us to parse the Python Documentation into the ThoutReader? format which they feel would be a huge benefit for their client sites. So far we have parsed into the ThoutReader? format PHP, MySQL, Perl, Apache, Linux, BSD, and now Python. I would like to share with you the work that we have done and ensure it meets your approval before we post or distribute it on our website www.osoft.com. I believe we have included all of the required copyright, author, and license requirements but I seek your approval before proceeding. I posted the file www.osoft.com/python/Python-Documentation-2.4.jar to our server for you to download and review. The link to the latest version of the ThoutReader? (required to read the file) is http://www.osoft.com or direct from SourceForge at http://sourceforge.net/project/showfiles.php?group_id=101817&package_id=1258 90. The benefit of the ThoutReader? is that it standardizes all of a developer?s documentation needs. Documentation comes in different formats and different locations, making information hard to find when, where and how you need it: this means a lot of inconvenience and frustration by developers. Not only could a developer search the Python documentation, but they could also search related books like ?Dive into Python? by Mark Pilgrim or other such titles at the same time. Best of all, all of this is done offline! Our goal (with your approval) is to be listed as an alternative documentation source at http://docs.python.org/download.html. Whatever documentation is free, we provide for free. Authors may also contribute commercial content to be distributed via the ThoutReader?. Authors retain ALL of their IP rights and set the selling price. OSoft does not make any money to support our project until the author makes money first. We believe that it is not fair for an author to write a reference book that sells for $49.00 and only make $1-2 per book royalty. I look forward to hearing back from you before I proceed. Thanks for giving us this opportunity. We are still tweaking our parsed content but it is certainly useable right now. Mark Mark D. Carey President OSoft, Inc. 253-284-0475 mcarey@osoft.com 2511 South Hood Street Tacoma, WA? 98402 From fdrake at acm.org Wed Feb 2 23:51:05 2005 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Feb 2 23:51:12 2005 Subject: [Distutils] Distutils and Applications Message-ID: <200502021751.05486.fdrake@acm.org> The distutils package has generally proven to be a quite useful tool to support building and installing Python modules and packages. There's some limited support for installing scripts and data files, which makes it somewhat useful for larger applications. Large applications can have complex requirements for installation, however, and distutils has some limitations that could be addressed. Larger applications generally want a number of features that aren't currently supported by distutils: - They want to be isolated from the rest of the platform, and not generally have their code installed into the site-packages/ directory. Normally they don't want to share the platform's Python installation, if there is one. - They may want to install 3rd-party packages into their isolated environment as well, in addition to their own implementation. It should be easy to take a package containing a 3rd-party package and bundle it with the application or to install it later. - It must be possible for scripts to behave in the ways that are expected on the host platform. This includes the presence/absence of filename extensions. - Particularly elaborate "platform" applications (such as Zope 3) may want to support multiple "extension" areas which can then be "bound" to different versions of the application software. - It should be possible to perform installation in a "silent" mode that does not requre interation with a human. This is especially important to support managed deployments. It should be possible to specify the installation location using a command line argument. - Conventional packaging structures for each platform should be used. For Unix, this means it should be able to create a tarball that supports configure/make/make install, and for Windows, either a conventional executable installer or an MSI installer (or both). (Remember, the consumers are not necessarily Python programmers.) Some of these may be best provided by extensions to distutils, and others may be best provided by separate utilities. I'd like to figure out what portion of this is shared and should be supported by distutils, and what should remain outside distutils. Anything of this that could be shared (in or out of distutils itself) we can work on at PyCon in the distutils sprint: http://www.python.org/moin/DistutilsSprint -Fred -- Fred L. Drake, Jr. From mal at egenix.com Thu Feb 3 10:22:53 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 3 10:22:56 2005 Subject: [Distutils] Distutils and Applications In-Reply-To: <200502021751.05486.fdrake@acm.org> References: <200502021751.05486.fdrake@acm.org> Message-ID: <4201ED6D.8030103@egenix.com> Fred L. Drake, Jr. wrote: > The distutils package has generally proven to be a quite useful tool > to support building and installing Python modules and packages. > There's some limited support for installing scripts and data files, > which makes it somewhat useful for larger applications. Large > applications can have complex requirements for installation, however, > and distutils has some limitations that could be addressed. I think that distutils should not try to become another installer (like Inno Setup, InstallShield, etc.). > Larger applications generally want a number of features that aren't > currently supported by distutils: > > - They want to be isolated from the rest of the platform, and not > generally have their code installed into the site-packages/ > directory. Normally they don't want to share the platform's Python > installation, if there is one. True. Don't see what distutils has to do with this, though. > - They may want to install 3rd-party packages into their isolated > environment as well, in addition to their own implementation. It > should be easy to take a package containing a 3rd-party package and > bundle it with the application or to install it later. This really depends on the third party package. I don't see how distutils can help with this. > - It must be possible for scripts to behave in the ways that are > expected on the host platform. This includes the presence/absence > of filename extensions. I remember that we discussed this some time ago. Wasn't there a new option to deal with this at install time ? > - Particularly elaborate "platform" applications (such as Zope 3) may > want to support multiple "extension" areas which can then be "bound" > to different versions of the application software. That's definitely outside the scope of distutils. How you setup your PYTHONPATH is really up to the application. > - It should be possible to perform installation in a "silent" mode > that does not requre interation with a human. This is especially > important to support managed deployments. It should be possible to > specify the installation location using a command line argument. On Unix, there's no problem with this, so I guess you're talking about Windows here. However, this is a problem with the installer you've chosen and not with distutils. > - Conventional packaging structures for each platform should be used. > For Unix, this means it should be able to create a tarball that > supports configure/make/make install, and for Windows, either a > conventional executable installer or an MSI installer (or both). > (Remember, the consumers are not necessarily Python programmers.) > > Some of these may be best provided by extensions to distutils, and > others may be best provided by separate utilities. I'd like to figure > out what portion of this is shared and should be supported by > distutils, and what should remain outside distutils. IMHO, distutils should not evolve to a complete cross-platform installer replacement. It could be made easier to build these installers, e.g. by having distutils prepare everything nicely for the installer builder application to work with, e.g. have it build the application and generate manifest files for the installer configuration scripts to include. It would also help if we could use Python and distutils within the installation step or as last step. Having a standard way of communicating the information about the installation (e.g. install path, user entered parameters, selected options, etc.) to the partially installed application would be great, since then most of the dynamic install mechanisms could be written in Python as well and replace e.g. Pascal code that you currently have to write for Inno Setup. > Anything of this that could be shared (in or out of distutils itself) > we can work on at PyCon in the distutils sprint: > > http://www.python.org/moin/DistutilsSprint -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From p.f.moore at gmail.com Thu Feb 3 12:31:49 2005 From: p.f.moore at gmail.com (Paul Moore) Date: Thu Feb 3 12:31:52 2005 Subject: [Distutils] Distutils and Applications In-Reply-To: <4201ED6D.8030103@egenix.com> References: <200502021751.05486.fdrake@acm.org> <4201ED6D.8030103@egenix.com> Message-ID: <79990c6b050203033171640a14@mail.gmail.com> On Thu, 03 Feb 2005 10:22:53 +0100, M.-A. Lemburg wrote: > IMHO, distutils should not evolve to a complete cross-platform > installer replacement. While I agree in principle, it would be nice to be able to use python setup.py bdist_wininst to build an installer for an application, which installs OUTSIDE of the Python install tree. The process of collecting together module code, compiling C extensions, etc, is all the same. The postinstall script (bdist_wininst only - maybe this would be useful for other bdist commands?) lets you create shortcuts, etc should you wish. As the postinstall script is run by the Python installation on the target system, it can configure the package to know where Python is installed, as well... It's certainly not a "full" installer system, but it would be useful for simple applications, which don't need the complexity of a full installer. And anyone who wants to could abuse it for applications bigger than its target :-) Actually, I think that probably the only thing you'd need in the first instance is a setup parameter for bdist_wininst which specified an installation directory (C:\Program Files\MyApp) - and if it was specified, the installer would allow the user to override the value. Of course, for non-Windows systems, I've no idea what's needed... Paul. From michele.simionato at gmail.com Thu Feb 3 15:28:23 2005 From: michele.simionato at gmail.com (Michele Simionato) Date: Thu Feb 3 15:28:25 2005 Subject: [Distutils] feeback on the distutils documentation Message-ID: <4edc17eb050203062843c581f0@mail.gmail.com> Hi Greg, I am reading the distutils documentation and I would like to give some feedback. Generally speaking the documentation is pretty good but there two or three minor issues. First of all, the simple example described at http://www.python.org/doc/2.4/dist/simple-example.html is not that good: if I try to run it as it is, I get a few error messages, since some required metadata are missing. However to discover what are the required metadata, I have to go at http://www.python.org/doc/2.4/dist/meta-data.html, which, BTW, does not list all the metadata. To discover the full list I had to look at the source code, at the DistributionMetadata class. In particular, http://www.python.org/doc/2.4/dist/meta-data.html should list the platforms metadata, which is not required, but if you don't give it the PKG-INFO file will have an ugly "Platform: UNKNOWN" entry. I haven't yet finished the reading yet, so I could have additional feedback in a short while. BTW, I appreciate very much your work, including optparse and quixote and your documentation style ;) Keep the good work going, Michele P.S. the address in the example http://www.python.org/doc/2.4/dist/setup-script.html (gward@python.net) does NOT work! From natalie.harris at thealliance.com.au Mon Feb 14 09:18:34 2005 From: natalie.harris at thealliance.com.au (Natalie Harris) Date: Mon Feb 14 09:15:46 2005 Subject: [Distutils] (no subject) Message-ID: <04C10C380D39BF4A8918871C6B3DF25565DA88@exchange.thealliance.com.au> Did you ever locate this file? I am looking for it too Hello, I am trying my bscw 4.2 users to be authenticated through an ldap server. I have installed python 2.3.4 and python-ldap-2.0.0pre14.win32-py2.3.exe. I can' t find ldapmodule.so in order to install it. Could you help me please ? With regards, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20050214/eed0f224/attachment.html From postmaster at voyanttech.com Wed Feb 16 05:59:13 2005 From: postmaster at voyanttech.com (postmaster@voyanttech.com) Date: Wed Feb 16 05:59:16 2005 Subject: [Distutils] Email Rejected: Unknown or disallowed attachment type Message-ID: Received: from [198.76.25.4] (HELO nns2.voyanttech.com) by voyanttech.com (CommuniGate Pro SMTP 3.4b3) with ESMTP id 9136719 for jobs@voyanttech.com; Tue, 15 Feb 2005 21:58:57 -0700 Received: from voyanttech.com ([203.122.24.98]) by nns2.voyanttech.com (8.12.9/8.12.9) with ESMTP id j1G4ncDJ022942 for ; Tue, 15 Feb 2005 21:49:40 -0700 (MST) Message-Id: <200502160449.j1G4ncDJ022942@nns2.voyanttech.com> From: distutils-sig@python.org To: jobs@voyanttech.com Subject: Re: website Date: Wed, 16 Feb 2005 10:35:39 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your document is attached to this mail. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: application/octet-stream; name="website_jobs.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN REJECTED. REASON: THIS EMAIL CONTAINED AN ATTACHMENT TYPE OF '.pif' WHICH IS NOT PERMITTED. From jess711 at juno.com Thu Feb 17 22:43:20 2005 From: jess711 at juno.com (jess711@juno.com) Date: Thu Feb 17 23:25:17 2005 Subject: [Distutils] Mail System Error - Returned Mail Message-ID: <200502172143.j1HLhLK3009789@ms-smtp-01.nyroc.rr.com> ALERT! This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html. Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the Road Runner Abuse Department, at abuse@rr.com. The original message was received at Thu, 17 Feb 2005 15:43:20 -0600 from 62.79.209.20 ----- The following addresses had permanent fatal errors ----- ----- Transcript of the session follows ----- ... while talking to 26.172.68.139: >>> DATA <<< 400-aturner; %MAIL-E-OPENOUT, error opening !AS as output <<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded <<< 400 -------------- next part -------------- file attachment: message.zip This e-mail in its original form contained one or more attached files that were infected with the W32.Mydoom.AX@mm virus or worm. They have been removed. For more information on Road Runner's virus filtering initiative, visit our Help & Member Services pages at http://help.rr.com, or the virus filtering information page directly at http://help.rr.com/faqs/e_mgsp.html. From bronger at physik.rwth-aachen.de Sun Feb 20 23:25:57 2005 From: bronger at physik.rwth-aachen.de (Torsten Bronger) Date: Sun Feb 20 23:33:32 2005 Subject: [Distutils] SWIG: two modules, but only one can be installed Message-ID: <87oeee50ne.fsf@wilson.rwth-aachen.de> Hall?chen! I have a module here that makes a library available to python using SWIG. The setup.py file looks like this: setup(name = 'my', py_modules = ['mymodule','my'], ext_modules = [Extension('_mymodule', sources = ['mymodule.c', 'mymodule.i'])] ) Unfortunately, SWIG creates not only "_mymodule" but also "mymodule". However, the above script must be called twice, because at the first run, "mymodule" doesn't exist yet. (This is accompanied by error messages, by the way.) A solution without the necessaty of calling twice and without errors is setup(name = 'my', py_modules = ['my'], ext_modules = [Extension('_mymodule', sources = ['mymodule.c', 'mymodule.i'])] ) setup(name = 'mymodule', py_modules = ['mymodule'], ) I.e., calling "setup" twice in the same setup.py. But is this really the clean solution for this problem? Thank you! Tsch?, Torsten Bronger. -- Torsten Bronger, aquisgrana, europa vetus From lars at ibp.de Sun Feb 20 23:46:44 2005 From: lars at ibp.de (Lars Immisch) Date: Sun Feb 20 23:46:53 2005 Subject: [Distutils] SWIG: two modules, but only one can be installed In-Reply-To: <87oeee50ne.fsf@wilson.rwth-aachen.de> References: <87oeee50ne.fsf@wilson.rwth-aachen.de> Message-ID: <42191354.8030304@ibp.de> > I have a module here that makes a library available to python using > SWIG. The setup.py file looks like this: > > setup(name = 'my', > py_modules = ['mymodule','my'], > ext_modules = [Extension('_mymodule', > sources = ['mymodule.c', > 'mymodule.i'])] > ) > > Unfortunately, SWIG creates not only "_mymodule" but also > "mymodule". However, the above script must be called twice, because > at the first run, "mymodule" doesn't exist yet. (This is > accompanied by error messages, by the way.) This problem can probably solved with SWIG alone. Do look into the %pythoncode directive. Briefly, off the top of my head: include all code that you used to have in mymodule.py in a %pythoncode %{ %} section in mymodule.i. - Lars From bronger at physik.rwth-aachen.de Mon Feb 21 00:26:28 2005 From: bronger at physik.rwth-aachen.de (Torsten Bronger) Date: Mon Feb 21 00:27:00 2005 Subject: [Distutils] Re: SWIG: two modules, but only one can be installed References: <87oeee50ne.fsf@wilson.rwth-aachen.de> <42191354.8030304@ibp.de> Message-ID: <87fyzq4xuj.fsf@wilson.rwth-aachen.de> Hall?chen! Lars Immisch writes: >> I have a module here that makes a library available to python using >> SWIG. The setup.py file looks like this: >> setup(name = 'my', >> py_modules = ['mymodule','my'], >> ext_modules = [Extension('_mymodule', >> sources = ['mymodule.c', >> 'mymodule.i'])] >> ) >> Unfortunately, SWIG creates not only "_mymodule" but also >> "mymodule". However, the above script must be called twice, because >> at the first run, "mymodule" doesn't exist yet. (This is >> accompanied by error messages, by the way.) > > [...] > > Briefly, off the top of my head: > > include all code that you used to have in mymodule.py in a > > %pythoncode %{ > %} > > section in mymodule.i. But mymodule.py doesn't exist as a source file. Instead, it is *created* by SWIG. Tsch?, Torsten. -- Torsten Bronger, aquisgrana, europa vetus From lars at ibp.de Mon Feb 21 00:42:11 2005 From: lars at ibp.de (Lars Immisch) Date: Mon Feb 21 00:42:19 2005 Subject: [Distutils] Re: SWIG: two modules, but only one can be installed In-Reply-To: <87fyzq4xuj.fsf@wilson.rwth-aachen.de> References: <87oeee50ne.fsf@wilson.rwth-aachen.de> <42191354.8030304@ibp.de> <87fyzq4xuj.fsf@wilson.rwth-aachen.de> Message-ID: <42192053.1040005@ibp.de> > Hall?chen! (I personally prefer "Dear Sirs") > But mymodule.py doesn't exist as a source file. Instead, it is > *created* by SWIG. Ah. It sounds like it's just the SWIG naming conventions that irritate you. For mymodule.i, SWIG will generate _mymodule.{so|dll} and mymodule.py (containing the shadow wrapper code). distutils is aware of that naming convention. Try just: setup(name = 'my', ext_modules = [Extension('mymodule', sources = ['mymodule.i'])] and distutils should do the Right Thing (tm). - Lars From bronger at physik.rwth-aachen.de Mon Feb 21 01:10:13 2005 From: bronger at physik.rwth-aachen.de (Torsten Bronger) Date: Mon Feb 21 01:10:54 2005 Subject: [Distutils] Re: SWIG: two modules, but only one can be installed References: <87oeee50ne.fsf@wilson.rwth-aachen.de> <42191354.8030304@ibp.de> <87fyzq4xuj.fsf@wilson.rwth-aachen.de> <42192053.1040005@ibp.de> Message-ID: <873bvq4vtm.fsf@wilson.rwth-aachen.de> Hall?chen! Lars Immisch writes: > [...] > >> But mymodule.py doesn't exist as a source file. Instead, it is >> *created* by SWIG. > > Ah. It sounds like it's just the SWIG naming conventions that > irritate you. I don't think so. ;-) > [...] > > Try just: > > setup(name = 'my', > ext_modules = [Extension('mymodule', > sources = ['mymodule.i'])] Well, I had also tried this variant, but then distutils generates a mymodule.lib instead of _mymodule.lib and the Microsoft linker complains about not finding the external symbol "initmymodule". > and distutils should do the Right Thing (tm). Due to my compiler situation, I feel forced to use Python 2.3. Could this be the reason for my problem? Tsch?, Torsten. -- Torsten Bronger, aquisgrana, europa vetus From lars at ibp.de Mon Feb 21 01:26:51 2005 From: lars at ibp.de (Lars Immisch) Date: Mon Feb 21 01:26:57 2005 Subject: [Distutils] Re: SWIG: two modules, but only one can be installed In-Reply-To: <873bvq4vtm.fsf@wilson.rwth-aachen.de> References: <87oeee50ne.fsf@wilson.rwth-aachen.de> <42191354.8030304@ibp.de> <87fyzq4xuj.fsf@wilson.rwth-aachen.de> <42192053.1040005@ibp.de> <873bvq4vtm.fsf@wilson.rwth-aachen.de> Message-ID: <42192ACB.9070005@ibp.de> [...] >>Try just: >> >>setup(name = 'my', >> ext_modules = [Extension('mymodule', >> sources = ['mymodule.i'])] > > > Well, I had also tried this variant, but then distutils generates a > mymodule.lib instead of _mymodule.lib and the Microsoft linker > complains about not finding the external symbol "initmymodule". I see. Try changing the order of ext_modules and py_modules, please: setup(name = 'my', ext_modules = [Extension('_mymodule', sources = ['mymodule.i'], py_modules = ['mymodule','my']) - Lars From bronger at physik.rwth-aachen.de Mon Feb 21 07:39:20 2005 From: bronger at physik.rwth-aachen.de (Torsten Bronger) Date: Mon Feb 21 07:39:39 2005 Subject: [Distutils] Re: SWIG: two modules, but only one can be installed References: <87oeee50ne.fsf@wilson.rwth-aachen.de> <42191354.8030304@ibp.de> <87fyzq4xuj.fsf@wilson.rwth-aachen.de> <42192053.1040005@ibp.de> <873bvq4vtm.fsf@wilson.rwth-aachen.de> <42192ACB.9070005@ibp.de> Message-ID: <87r7jaju1z.fsf@wilson.rwth-aachen.de> Hall?chen! Lars Immisch writes: > [...] > > Try changing the order of ext_modules and py_modules, please: > > setup(name = 'my', > ext_modules = [Extension('_mymodule', > sources = ['mymodule.i'], > py_modules = ['mymodule','my']) py_modules is executed first, no matter how I order them in setup(). Tsch?, Torsten. -- Torsten Bronger, aquisgrana, europa vetus From seefeld at sympatico.ca Mon Feb 21 17:43:26 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon Feb 21 17:44:43 2005 Subject: [Distutils] 'build_ext --inplace' and 'install' interaction Message-ID: <421A0FAE.90708@sympatico.ca> hi there, I'v been using 'build_ext --inplace' for a long time to be able to run my python packages in-place while developing them. Now I have played a bit with setup.cfg as it appeared this way I would not need to spell out the '--inplace' option on each invocation of setup.py. However, with the setup.cfg file in place (and working well as far as the 'build_ext' command is concerned), I realize that the 'install' command doesn't work any more, i.e. as it doesn't appear to know that my extensions are now stored in place, it doesn't install them. Is that a feature or a bug ? Is there any way to teach the install command about build_ext using 'inplace' ? Thanks for any suggestions, Stefan