From Vexira at email.beaufortco.com Fri Mar 11 02:55:36 2005 From: Vexira at email.beaufortco.com (Vexira@email.beaufortco.com) Date: Fri Mar 11 02:55:34 2005 Subject: [Distutils] Vexira ALERT [your mail: "Mail Delivery (failure leonacline@hydecounty.net)"] Message-ID: <200503110155.j2B1tamE026643@email.beaufortco.com> * * * * * * * * * * * * * * * Vexira ALERT * * * * * * * * * * * * * * * This version of Vexira MailArmor is licensed and full featured. Vexira has detected the following in a mail from your address: Worm/NetSky.P.ExplWorm/NetSky.P, Worm/NetSky.P.Expl The mail was not delivered. Your computer may be infected with a virus! Please visit Central Command at http://www.centralcommand.com and obtain a copy of Vexira AntiVirus now. Mail-Info: --8<-- From: distutils-sig@python.org To: leonacline@hydecounty.net Date: Thu, 10 Mar 2005 20:55:35 -0500 Subject: Mail Delivery (failure leonacline@hydecounty.net) --8<-- From jao at geophile.com Tue Mar 15 16:06:39 2005 From: jao at geophile.com (jao@geophile.com) Date: Tue Mar 15 16:06:30 2005 Subject: [Distutils] distutils setup ignoring scripts Message-ID: <1110899199.4236f9ffd44bc@geophile.com> I'm using Python 2.2 on RH9. I have a set of Python modules organized into a root package and one other package named foobar. setup.py looks like this: from distutils.core import setup setup( name = 'foobar', version = '0.3', description = 'Foo Bar', author = 'Jack Orenstein', author_email = 'jao@geophile.com', packages = ['', 'xyz'], scripts = ['bin/foobar'] ) The resulting package has everything in the specified directories, but does not include the script. I've tried making the path bin/foobar absolute, but that doesn't help. I've googled for known bugs of this sort but have come up emtpy. (The first line of bin/foobar is #!/usr/bin/python.) I've also tried using DISTUTIL_DEBUG, which has been uninformative, (e.g. no mention of bin/foobar at all). Can anyone see what I'm doing wrong? Jack Orenstein ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From timothy.williams at nvl.army.mil Wed Mar 16 19:25:23 2005 From: timothy.williams at nvl.army.mil (Williams, Timothy J Mr RDECOM CERDEC NVESD) Date: Wed Mar 16 19:26:40 2005 Subject: [Distutils] How do I modify the swig options in my setup.py Message-ID: <455B166AFCACA9439FA3704E2320C9AB40D5EA@nvlex01.nvl.army.mil> I'm trying to use SWIG to create an extension to access some third party libraries I want to be able to change the options to include possible '-includeall', '-c++'. I'm using distutils, but I don't know how to change from the default options. Also, a SWIG question: i build my _module.so and module_wrap.o, but when I try to call one of the functions, I get and error saying that the last argument was expected to be a pointer, but it isn't. I tried calling a couple of functions and both times SWIG is expecting the last arg to be a pointer. Any ideas? Thanks. ---- Tim Williams From lars at ibp.de Wed Mar 16 20:46:01 2005 From: lars at ibp.de (Lars Immisch) Date: Wed Mar 16 20:45:48 2005 Subject: [Distutils] How do I modify the swig options in my setup.py In-Reply-To: <455B166AFCACA9439FA3704E2320C9AB40D5EA@nvlex01.nvl.army.mil> References: <455B166AFCACA9439FA3704E2320C9AB40D5EA@nvlex01.nvl.army.mil> Message-ID: <42388CF9.9060701@ibp.de> > I'm trying to use SWIG to create an extension to access some third party > libraries I want to be able to change the options to include possible > '-includeall', '-c++'. I'm using distutils, but I don't know how to change > from the default options. From inside setup.py, use swig_opts. See the following example: import sys from distutils.core import setup,Extension setup (name = "sai", version = "2.0", description = "SAI Python wrapper", author = "Lars Immisch", author_email = "lars@ibp.de", ext_modules = [Extension("_sai", ["sai.i", "errorobject.c", "symname.c"], swig_opts = [ "-modern", "-new_repr", "-I..", "-I../../include"], include_dirs=["..", "../../include"], library_dirs=["."], libraries=["nsl", "pthread", "cSARU-genappl-api", "saru"])], py_modules = ['sai'] ) > Also, a SWIG question: i build my _module.so and module_wrap.o, but when I > try to call one of the functions, I get and error saying that the last > argument was expected to be a pointer, but it isn't. I tried calling a > couple of functions and both times SWIG is expecting the last arg to be a > pointer. Any ideas? Wrong typemaps ;-) This sort of question is best asked with a minimal example on the swig mailing list, but do have a look into typemaps in the documentation. A lot of useful typemaps are in python/typemaps.i. - Lars From timothy.williams at nvl.army.mil Wed Mar 16 21:20:37 2005 From: timothy.williams at nvl.army.mil (timothy.williams@nvl.army.mil) Date: Wed Mar 16 21:22:03 2005 Subject: [Distutils] How do I modify the swig options in my setup.py Message-ID: <455B166AFCACA9439FA3704E2320C9AB40D5EC@nvlex01.nvl.army.mil> I tried using swig_opts, but it didn't recognize it. I'm using python 2.3.2, SWIG 1.3.21 if that matters. #!/bin/env python import sys, os from distutils.core import setup, Extension py_version='python%d.%d' % (sys.version_info[0],sys.version_info[1]) OTB_HOME='/vps/otbknox/williams/OTB_2.0' OTB_INCLDIR=[ os.path.join(OTB_HOME, 'include', 'global'), os.path.join(OTB_HOME, 'include', 'libinc'), os.path.join(sys.prefix,'include',py_version), OTB_HOME ] OTB_LIBDIR=[os.path.join(OTB_HOME,'lib')] setup (name = 'OTB_libs', version='1.0', author="Tim Williams", packages=['OTB_libs'], ext_package='OTB_libs', ext_modules=[Extension('_cmdline', sources=['OTB_libs/cmdline.i'], include_dirs=OTB_INCLDIR, library_dirs=OTB_LIBDIR, libraries=['cmdline'], swig_opts=['-includeall'] ) ], py_modules=['OTB_libs.cmdline'] ) ###################### /project/c4i/Users_Share/williams/Linux/lib/python2.3/distutils/extension.py :128: UserWarning: Unknown Extension options: 'swig_opts' warnings.warn(msg) running build running build_py copying OTB_libs/__init__.py -> build/lib.linux-i686-2.3/OTB_libs copying OTB_libs/cmdline.py -> build/lib.linux-i686-2.3/OTB_libs copying OTB_libs/cmdline.py -> build/lib.linux-i686-2.3/OTB_libs copying OTB_libs/__init__.py -> build/lib.linux-i686-2.3/OTB_libs running build_ext building '_cmdline' extension swigging OTB_libs/cmdline.i to OTB_libs/cmdline_wrap.c swig -python -o OTB_libs/cmdline_wrap.c OTB_libs/cmdline.i /usr/bin/g++33 -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/vps/otbknox/williams/OTB_2.0/include/global -I/vps/otbknox/williams/OTB_2.0/include/libinc -I/project/c4i/Users_Share/williams/Linux/include/python2.3 -I/vps/otbknox/williams/OTB_2.0 -I/project/c4i/Users_Share/williams/Linux/include/python2.3 -c OTB_libs/cmdline_wrap.c -o build/temp.linux-i686-2.3/OTB_libs/cmdline_wrap.o gcc -pthread -shared build/temp.linux-i686-2.3/OTB_libs/cmdline_wrap.o -L/vps/otbknox/williams/OTB_2.0/lib -lcmdline -o build/lib.linux-i686-2.3/OTB_libs/_cmdline.so ################### I read over the typemaps some, but the libraries I'm trying to use have gobs of typedefs in them, and I was hoping that the #include files for the library would take care of it. (Beside me just not understanding enough about typemaps to be comfortable using them.) -----Original Message----- From: Lars Immisch [mailto:lars@ibp.de] Sent: Wednesday, March 16, 2005 2:46 PM To: Williams, Timothy J Mr RDECOM CERDEC NVESD Cc: 'distutils-sig@python.org' Subject: Re: [Distutils] How do I modify the swig options in my setup.py > I'm trying to use SWIG to create an extension to access some third party > libraries I want to be able to change the options to include possible > '-includeall', '-c++'. I'm using distutils, but I don't know how to change > from the default options. From inside setup.py, use swig_opts. See the following example: import sys from distutils.core import setup,Extension setup (name = "sai", version = "2.0", description = "SAI Python wrapper", author = "Lars Immisch", author_email = "lars@ibp.de", ext_modules = [Extension("_sai", ["sai.i", "errorobject.c", "symname.c"], swig_opts = [ "-modern", "-new_repr", "-I..", "-I../../include"], include_dirs=["..", "../../include"], library_dirs=["."], libraries=["nsl", "pthread", "cSARU-genappl-api", "saru"])], py_modules = ['sai'] ) > Also, a SWIG question: i build my _module.so and module_wrap.o, but when I > try to call one of the functions, I get and error saying that the last > argument was expected to be a pointer, but it isn't. I tried calling a > couple of functions and both times SWIG is expecting the last arg to be a > pointer. Any ideas? Wrong typemaps ;-) This sort of question is best asked with a minimal example on the swig mailing list, but do have a look into typemaps in the documentation. A lot of useful typemaps are in python/typemaps.i. - Lars From anthony at interlink.com.au Thu Mar 17 07:45:08 2005 From: anthony at interlink.com.au (Anthony Baxter) Date: Thu Mar 17 07:45:26 2005 Subject: [Distutils] How do I modify the swig options in my setup.py In-Reply-To: <455B166AFCACA9439FA3704E2320C9AB40D5EC@nvlex01.nvl.army.mil> References: <455B166AFCACA9439FA3704E2320C9AB40D5EC@nvlex01.nvl.army.mil> Message-ID: <200503171745.09674.anthony@interlink.com.au> On Thursday 17 March 2005 07:20, timothy.williams@nvl.army.mil wrote: > I tried using swig_opts, but it didn't recognize it. I'm using python > 2.3.2, SWIG 1.3.21 if that matters. Pretty sure that option only got added in Python 2.4 (I vaguely recall being the one who checked it in). Since it's a new feature, it didn't get backported to 2.3 (and in any case, 2.3.5 is the end of the line for 2.3). You could copy the new code from 2.4 back to your local repository - or maybe someone's already done a backport... Anthony -- Anthony Baxter It's never too late to have a happy childhood. From timothy.williams at nvl.army.mil Thu Mar 17 14:09:03 2005 From: timothy.williams at nvl.army.mil (timothy.williams@nvl.army.mil) Date: Thu Mar 17 14:11:42 2005 Subject: [Distutils] How do I modify the swig options in my setup.py Message-ID: <455B166AFCACA9439FA3704E2320C9AB40D5ED@nvlex01.nvl.army.mil> Thanks. I had installed python 2.4, but went back to 2.3.2 for a reason I can't remember now. I think some other module I was using wasn't built for it yet (MySQLdb maybe?) I'll reinstall and try again. I looked at the python/typemaps.i file. I may be able to use that to redefine the functions I'm calling after I include the libraries header files to define everything else. -----Original Message----- From: Lars Immisch [mailto:lars@ibp.de] Sent: Wednesday, March 16, 2005 4:27 PM To: timothy.williams@nvl.army.mil Subject: Re: [Distutils] How do I modify the swig options in my setup.py > I tried using swig_opts, but it didn't recognize it. I'm using python 2.3.2, > SWIG 1.3.21 if that matters. Sorry. I should have mentioned that from the start: The swig_opts extension only made it into Python 2.4b1, so you either need to upgrade Python or at least the version of distutils. > I read over the typemaps some, but the libraries I'm trying to use have gobs > of typedefs in them, and I was hoping that the #include files for the > library would take care of it. (Beside me just not understanding enough > about typemaps to be comfortable using them.) There are no hard and fast recommendations I would want to give, except reading typemap code, experimenting, and reading the resulting C code to get a feel how swig works. Failing that, do create a minimal example of an entire interface file that shows your problem and send it to the swig mailing list. I am sure that someone will help you there. - Lars From timothy.williams at nvl.army.mil Thu Mar 17 16:05:39 2005 From: timothy.williams at nvl.army.mil (timothy.williams@nvl.army.mil) Date: Thu Mar 17 16:08:10 2005 Subject: [Distutils] How do I modify the swig options in my setup.py Message-ID: <455B166AFCACA9439FA3704E2320C9AB40D5EE@nvlex01.nvl.army.mil> I installed Python 2.4. Now I can use swig_opts, but now I'm having a problem with compiling my cmdline_wrap.c file ########## cmdline.i ################# %module cmdline %{ #include %} %include ########## setup.py #################### #!/bin/env python import sys, os import pprint from distutils.core import setup, Extension py_version='python%d.%d' % (sys.version_info[0],sys.version_info[1]) OTB_HOME='/vps/otbknox/williams/OTB_2.0' OTB_INCLDIR=[ os.path.join(sys.prefix,'include',py_version), os.path.join(OTB_HOME, 'include', 'global'), os.path.join(OTB_HOME, 'include', 'libinc'), OTB_HOME ] OTB_LIBDIR=[os.path.join(OTB_HOME,'lib')] swig_opts=['-includeall','-I/usr/include'] for d in OTB_INCLDIR: swig_opts.append('-I%s' % d) ##pprint.pprint(swig_opts) setup (name = 'OTB_libs', version='1.0', author="Tim Williams", packages=['OTB_libs'], ext_package='OTB_libs', ext_modules=[Extension('_cmdline', sources=['OTB_libs/cmdline.i'], include_dirs=OTB_INCLDIR, library_dirs=OTB_LIBDIR, libraries=['cmdline'], swig_opts=swig_opts ) ], py_modules=['OTB_libs.cmdline'] ) ############### running build_ext building '_cmdline' extension swigging OTB_libs/cmdline.i to OTB_libs/cmdline_wrap.c swig -python -includeall -I/usr/include -I/project/c4i/Users_Share/williams/Linux/include/python2.4 -I/vps/otbknox/williams/OTB_2.0/include/global -I/vps/otbknox/williams/OTB_2.0/include/libinc -I/vps/otbknox/williams/OTB_2.0 -o OTB_libs/cmdline_wrap.c OTB_libs/cmdline.i OTB_libs/config.h:413: Warning(302): Identifier 'HAVE_UNISTD_H' redeclared (ignored). OTB_libs/config.h:15: Previous declaration of 'HAVE_UNISTD_H' /usr/include/sys/cdefs.h:147: Warning(305): Bad constant value (ignored). /usr/bin/gcc33 -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/project/c4i/Users_Share/williams/Linux/include/python2.4 -I/vps/otbknox/williams/OTB_2.0/include/global -I/vps/otbknox/williams/OTB_2.0/include/libinc -I/vps/otbknox/williams/OTB_2.0 -I/project/c4i/Users_Share/williams/Linux/include/python2.4 -c OTB_libs/cmdline_wrap.c -o build/temp.linux-i686-2.4/OTB_libs/cmdline_wrap.o OTB_libs/cmdline_wrap.c: In function `_wrap_mtx32vec64_vec_set': OTB_libs/cmdline_wrap.c:742: error: structure has no member named `vec_size' OTB_libs/cmdline_wrap.c:742: error: incompatible types in assignment OTB_libs/cmdline_wrap.c: In function `_wrap_mtx32vec64_rot_set': OTB_libs/cmdline_wrap.c:781: error: structure has no member named `rot_size' OTB_libs/cmdline_wrap.c:781: error: incompatible types in assignment OTB_libs/cmdline_wrap.c: In function `_wrap_gcs_rmatrix64_rot_set': OTB_libs/cmdline_wrap.c:1150: error: structure has no member named `rot_size' OTB_libs/cmdline_wrap.c:1150: error: incompatible types in assignment OTB_libs/cmdline_wrap.c: In function `_wrap_gcs_rmatrix32_rot_set': OTB_libs/cmdline_wrap.c:1260: error: structure has no member named `rot_size' OTB_libs/cmdline_wrap.c:1260: error: incompatible types in assignment OTB_libs/cmdline_wrap.c: At top level: OTB_libs/cmdline_wrap.c:187: warning: `SWIG_Python_TypeDynamicCast' defined but not used OTB_libs/cmdline_wrap.c:199: warning: `SWIG_Python_TypeName' defined but not used OTB_libs/cmdline_wrap.c:205: warning: `SWIG_Python_TypeQuery' defined but not used OTB_libs/cmdline_wrap.c:444: warning: `SWIG_Python_addvarlink' defined but notused OTB_libs/cmdline_wrap.c:551: warning: `SWIG_Python_MustGetPtr' defined but notused OTB_libs/cmdline_wrap.c:559: warning: `SWIG_Python_ConvertPacked' defined but not used error: command '/usr/bin/gcc33' failed with exit status 1 ############## I think this is coming from the typedefs in stdtypes.h: (#include'd by libcmdline.h) /* The following are vector definitions */ typedef float32 vec3d32[3]; typedef float64 vec3d64[3]; typedef float32 vec2d32[2]; typedef float64 vec2d64[2]; typedef float32 rmatrix32[3][3]; typedef float64 rmatrix64[3][3]; typedef float32 rtmatrix32[4][3]; typedef float64 rtmatrix64[4][3]; typedef struct { vec3d64 vec; /* Placed before single-precision to assure alignment */ rmatrix32 rot; } mtx32vec64; I'm starting to think that this library I'm trying to write an extension for has just too many nested typedefs for SWIG to handle. (And this is one of the simpler libraries that don't have dependencies on other libraries!) If I take out the -includeall switch, the _cmdline.so library builds, but when I try to import the module I get: Python 2.4 (#2, Feb 23 2005, 11:35:23) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import OTB_libs.cmdline Traceback (most recent call last): File "", line 1, in ? File "/project/c4i/Users_Share/williams/Linux/lib/python2.4/site-packages/OTB_lib s/cmdline.py", line 5, in ? import _cmdline ImportError: /project/c4i/Users_Share/williams/Linux/lib/python2.4/site-packages/OTB_libs /_cmdline.so: undefined symbol: cmd_aggregate This is a function in the libcmdline.a (static, I know) that I'm trying to use. From timothy.williams at nvl.army.mil Thu Mar 17 16:10:57 2005 From: timothy.williams at nvl.army.mil (Williams, Timothy J Mr RDECOM CERDEC NVESD) Date: Thu Mar 17 16:12:11 2005 Subject: [Distutils] How do I modify the swig options in my setup.py Message-ID: <455B166AFCACA9439FA3704E2320C9AB40D5EF@nvlex01.nvl.army.mil> I just realized that I need to post this to the SWIG list. Sorry. Thanks for the distutils help (swig_opts). From bob at redivi.com Fri Mar 18 03:55:38 2005 From: bob at redivi.com (Bob Ippolito) Date: Fri Mar 18 03:55:45 2005 Subject: [Distutils] ANN: py2app 0.1.8 Message-ID: (see also: ) `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.8 will be included in the installer for `PyObjC`_ 1.3. If you have installed `PyObjC`_ 1.3, then you already have `py2app`_ 0.1.8 installed. Download and related links are here: http://undefined.org/python/#py2app py2app 0.1.8 is a major enhancements release: Bugs fixed: - Symlinks in included frameworks should be preserved correctly (fixes Tcl/Tk) - Fixes some minor issues with alias bundles - Removed implicit SpiderImagePlugin -> ImageTk reference in PIL recipe - The ``--optimize`` option should work now - ``weakref`` is now included by default - ``anydbm``'s dynamic dependencies are now in the standard implies list - Errors on app launch are brought to the front so the user does not miss them - bdist_mpkg now compatible with pychecker (data_files had issues) Options changed: - deprecated ``--strip``, it is now on by default - new ``--no-strip`` option to turn off stripping of executables New features: - Looks for a hacked version of the PyOpenGL __init__.py so that it doesn't have to include the whole package in order to get at the stupid version file. - New ``loader_files`` key that a recipe can return in order to ensure that non-code ends up in the .zip (the pygame recipe uses this) - Now scans all files in the bundle and normalizes Mach-O load commands, not just extensions. This helps out when using the ``--package`` option, when including frameworks that have plugins, etc. - An embedded Python interpreter is now included in the executable bundle (``sys.executable`` points to it), this currently only works for framework builds of Python - New ``macho_standalone`` tool - New ``macho_find`` tool - Major enhancements to the way plugins are built - bdist_mpkg now has a ``--zipdist`` option to build zip files from the built package - The bdist_mpkg "Installed to:" description is now based on the package install root, rather than the build root .. _`py2app`: http://undefined.org/python/#py2app .. _`pyobjc`: http://pyobjc.sourceforge.net/ .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/ From vivian at vdesmedt.com Tue Mar 29 12:02:20 2005 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Tue Mar 29 12:02:22 2005 Subject: [Distutils] small improvement of the script functionality under win32 Message-ID: <424927AC.60401@vdesmedt.com> Dear disutils devloppers, First I would like to thank you for the nice job you did. I like distutils it is a very nice and powerfull way to install package. I finally found a pretext to thank you. Distutils have a script functionality that copy the corresponding file into a common script folder (that could be on the path) and sligthly modify the first line of the script to reflect the path of the python executable. It is very nice but for the window platform I think it could be improved. First the extention of the script could be .cmd such that they will be accessible as commands as soon as the script folder is in the path. Second the first line adaptation could be slightly different and take advantage of the -x option of the python executable #!python foo bar could become: @C:\Python24\python.exe -x "%~f0" foo bar & exit /b instead of: #!C:\Python24\python.exe -x "%~f0" foo bar & exit /b Follows a proposition of modification of the copy_scripts function of the build_scripts.py that reflect these changes for script in self.scripts: adjust = 0 script = convert_path(script) outfile = os.path.join(self.build_dir, os.path.basename(script)) *if os.name == "nt": outfile += ".cmd"* outfiles.append(outfile) if not self.force and not newer(script, outfile): log.debug("not copying %s (up-to-date)", script) continue # Always open the file, but ignore failures in dry-run mode -- # that way, we'll get accurate feedback if we can read the # script. try: f = open(script, "r") except IOError: if not self.dry_run: raise f = None else: first_line = f.readline() if not first_line: self.warn("%s is an empty file (skipping)" % script) continue match = first_line_re.match(first_line) if match: adjust = 1 post_interp = match.group(1) or '' if adjust: log.info("copying and adjusting %s -> %s", script, self.build_dir) if not self.dry_run: outf = open(outfile, "w") * if not sysconfig.python_build: python_path = os.path.normpath(sys.executable) else: python_path = os.path.join( sysconfig.get_config_var("BINDIR"), "python" + sysconfig.get_config_var("EXE")) if os.name == "nt": outf.write('@%s -x "%%~f0" %s & exit /b\n' % (python_path, post_interp)) else: outf.write("#!%s%s\n" % (python_path, post_interp))* outf.writelines(f.readlines()) outf.close() if f: f.close() else: f.close() self.copy_file(script, outfile) Tell me what you think about this proposition and what I should do to have a chance to integrate it into your module. Vivian. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20050329/95513853/attachment.htm From mal at egenix.com Wed Mar 30 09:51:32 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Mar 30 09:51:35 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <424927AC.60401@vdesmedt.com> References: <424927AC.60401@vdesmedt.com> Message-ID: <424A5A84.1020401@egenix.com> Vivian De Smedt wrote: > Distutils have a script functionality that copy the corresponding file > into a common script folder (that could be on the path) and sligthly > modify the first line of the script to reflect the path of the python > executable. > It is very nice but for the window platform I think it could be improved. > > First the extention of the script could be .cmd such that they will be > accessible as commands as soon as the script folder is in the path. > > Second the first line adaptation could be slightly different and take > advantage of the -x option of the python executable > > #!python foo bar > > could become: > > @C:\Python24\python.exe -x "%~f0" foo bar & exit /b > > instead of: > > #!C:\Python24\python.exe -x "%~f0" foo bar & exit /b Sounds like a good idea. The only thing I don't understand is why you'd want to use ".cmd" instead of the more common ".bat". > Follows a proposition of modification of the copy_scripts function of > the build_scripts.py that reflect these changes Please submit this as patch on SourceForge (http://python.sf.net). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 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 pje at telecommunity.com Wed Mar 30 18:41:23 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 30 18:37:31 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <424A5A84.1020401@egenix.com> References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> Message-ID: <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> At 09:51 AM 3/30/05 +0200, M.-A. Lemburg wrote: > > > #!C:\Python24\python.exe -x "%~f0" foo bar & exit /b > >Sounds like a good idea. The only thing I don't understand is >why you'd want to use ".cmd" instead of the more common ".bat". This doesn't work on Windows 98 at *all*: * 98 doesn't support .cmd files * 98 doesn't have a /b option for 'exit' * 98 doesn't pay attention to the '&' * 98 doesn't have a way to get the filename being executed (as opposed to argument 0) The closest I was able to get this to working was to use a .bat, at which point the Python part runs, but then Windows tries to execute the Python script as a batch file. Maybe somebody smarter than me can come up with a way to fix that. The following is the closest I got to a working .bat: @c:\python23\python.exe -x "%0" rem = """ @goto exit """ print "hello world" # this is the script """ :exit @rem""" This still has some important flaws; first the %0 is fragile, because it has to be the actual filename, so it's not really going to work unless Python searches PATH and PATHEXT. Second, it outputs the 'rem = """' line, and I don't know any way around that. Third, you can't have a docstring or 'from __future__'. Anyway, I guess my point is that the patch should *not* be accepted unless it actually checks whether the Windows version is high enough to support these features. From trentm at ActiveState.com Wed Mar 30 19:30:14 2005 From: trentm at ActiveState.com (Trent Mick) Date: Wed Mar 30 19:34:36 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> Message-ID: <20050330173014.GA11558@ActiveState.com> [Phillip J. Eby wrote] > Anyway, I guess my point is that the patch should *not* be accepted unless > it actually checks whether the Windows version is high enough to support > these features. If that is done, the check should be on the shell being used, i.e. command.com (which is the limited one) vs. cmd.exe. Generally this can be done by looking at the COMSPEC environment variable. For example, if one goes through Microsoft's upgrade process to upgrade from a Win9x flavour to, say, Win2k, then one's COMSPEC will still (unfortunately) be command.com. Cheers, Trent -- Trent Mick TrentM@ActiveState.com From vivian at vdesmedt.com Wed Mar 30 22:54:07 2005 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Wed Mar 30 22:54:09 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> Message-ID: <424B11EF.8000502@vdesmedt.com> Could we say that if: os.environ["os"] == "Windows_NT" the patch improve the existing situation? Vivian. From trentm at ActiveState.com Wed Mar 30 23:28:23 2005 From: trentm at ActiveState.com (Trent Mick) Date: Wed Mar 30 23:32:40 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <424B11EF.8000502@vdesmedt.com> References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> <424B11EF.8000502@vdesmedt.com> Message-ID: <20050330212823.GB21128@ActiveState.com> [Vivian De Smedt wrote] > Could we say that if: > > os.environ["os"] == "Windows_NT" > > the patch improve the existing situation? I didn't really read the patch, so I can't give an opinion, but there is no standard OS environment variable on, e.g. Win98, so that would (at the least) have to be: os.environ.get("OS") == "Windows_NT" Still, as I said, the differentiate is more proper on what shell is being used. Trent -- Trent Mick TrentM@ActiveState.com From bob at redivi.com Wed Mar 30 23:48:27 2005 From: bob at redivi.com (Bob Ippolito) Date: Wed Mar 30 23:48:35 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <20050330212823.GB21128@ActiveState.com> References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> <424B11EF.8000502@vdesmedt.com> <20050330212823.GB21128@ActiveState.com> Message-ID: On Mar 30, 2005, at 4:28 PM, Trent Mick wrote: > [Vivian De Smedt wrote] >> Could we say that if: >> >> os.environ["os"] == "Windows_NT" >> >> the patch improve the existing situation? > > I didn't really read the patch, so I can't give an opinion, but there > is > no standard OS environment variable on, e.g. Win98, so that would (at > the least) have to be: > > os.environ.get("OS") == "Windows_NT" > > Still, as I said, the differentiate is more proper on what shell is > being used. Also important to consider: what happens to COMSPEC when you're using a cygwin shell? Will a cygwin shell run .cmd files? (I don't really use Windows anymore...) -bob From trentm at ActiveState.com Wed Mar 30 23:52:17 2005 From: trentm at ActiveState.com (Trent Mick) Date: Wed Mar 30 23:56:35 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> <424B11EF.8000502@vdesmedt.com> <20050330212823.GB21128@ActiveState.com> Message-ID: <20050330215217.GB25721@ActiveState.com> [Bob Ippolito wrote] > Also important to consider: what happens to COMSPEC when you're using a > cygwin shell? Will a cygwin shell run .cmd files? > > (I don't really use Windows anymore...) I don't know. Trying... Under the cygwin bash shell there *is* a TERM=cygwin environment variable that, I suppose, could be checked. I don't use the cygwin bash shell at all (and I don't think that people should, for various reasons including http://trentm.com/blog/?p=10). You *can* run .bat files (and I presume .cmd files as well) under Cygwin bash, but you have the specify the extension: i.e. the PATHEXT stuff doesn't work. As I said: > >I didn't really read the patch, so I can't give an opinion, but there I'm now worried that I am giving bad advice. :) Cheers, Trent -- Trent Mick TrentM@ActiveState.com From pje at telecommunity.com Thu Mar 31 00:37:54 2005 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Mar 31 00:34:02 2005 Subject: [Distutils] small improvement of the script functionality under win32 In-Reply-To: <20050330215217.GB25721@ActiveState.com> References: <424927AC.60401@vdesmedt.com> <424927AC.60401@vdesmedt.com> <5.1.1.6.0.20050330112736.03920450@mail.telecommunity.com> <424B11EF.8000502@vdesmedt.com> <20050330212823.GB21128@ActiveState.com> Message-ID: <5.1.1.6.0.20050330173712.032e82f0@mail.telecommunity.com> At 01:52 PM 3/30/05 -0800, Trent Mick wrote: >[Bob Ippolito wrote] > > Also important to consider: what happens to COMSPEC when you're using a > > cygwin shell? Will a cygwin shell run .cmd files? > > > > (I don't really use Windows anymore...) > >I don't know. Trying... >Under the cygwin bash shell there *is* a TERM=cygwin environment >variable that, I suppose, could be checked. I don't use the cygwin bash >shell at all (and I don't think that people should, for various reasons >including http://trentm.com/blog/?p=10). You *can* run .bat files (and I >presume .cmd files as well) under Cygwin bash, but you have the specify >the extension: i.e. the PATHEXT stuff doesn't work. Also, Cygwin under 98 won't execute .cmd files, or at least I couldn't get it to. From bob at redivi.com Thu Mar 31 18:02:23 2005 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 31 18:02:34 2005 Subject: [Distutils] ANN: py2app 0.1.9 Message-ID: <7d074a36c208bc55f96eba9ed5369003@redivi.com> (see also: ) `py2app`_ is the bundlebuilder replacement we've all been waiting for. It is implemented as a distutils command, similar to `py2exe`_, that builds Mac OS X applications from Python scripts, extensions, and related data files. It tries very hard to include all dependencies it can find so that your application can be distributed standalone, as Mac OS X applications should be. `py2app`_ 0.1.9 is included in the installer for `PyObjC`_ 1.3. If you have installed `PyObjC`_ 1.3, then you already have `py2app`_ 0.1.9 installed. Download and related links are here: http://undefined.org/python/#py2app py2app 0.1.9 is a minor bug fix release: Bugs fixed: - bdist_mpkg now builds zip files that are correctly unzipped by all known tools. - The behavior of the bootstrap has changed slightly such that ``__file__`` should now point to your main script, rather than the bootstrap. The main script has also moved to ``Resources``, from ``Resources/Python``, so that ``__file__`` relative resource paths should still work. .. _`py2app`: http://undefined.org/python/#py2app .. _`pyobjc`: http://pyobjc.sourceforge.net/ .. _`py2exe`: http://starship.python.net/crew/theller/py2exe/