From Andrew.MacIntyre@aba.gov.au Mon Apr 1 19:04:02 2002 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Mon Apr 1 19:04:02 2002 Subject: [Fwd: [Distutils] Automatic creation of .pyc files] Message-ID: > -----Original Message----- > From: Andy Todd [mailto:andy47@halfcooked.com] > Sent: Tuesday, 26 March 2002 2:29 PM {...} > When packaging a Python module is it possible to stop the automatic > creation of .pyc on installation? > > I ask because in PythonCard we currently store our > configuration data in > files that are imported but never executed (i.e. they just contain a > list). When I package up the prototype and make it available I would > like to be able to stop .pyc versions of these files being created. Perhaps I'm missing something, but just importing the module will force recompilation and creation of the .pyc file anyway (unless the directory containing it is not writeable) so I don't see what the real issue is. If the .py file gets updated, the .pyc file will then get updated (file/directory permissions permitting) on the next import. If this really bugs you, perhaps eval() is a more attractive solution. ----------------------------------------------------------------------- Andrew MacIntyre \ E-mail: andrew.macintyre@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- From distutils-sig@python.org Fri Apr 5 12:40:01 2002 From: distutils-sig@python.org (Albert Chin) Date: Fri Apr 5 12:40:01 2002 Subject: [Distutils] Adding compiler-options during build Message-ID: <20020405113927.A4129@oolong.il.thewrittenword.com> How do I add options for the compiler in setup.py? I'd like to add the -qlanglvl=extended option on AIX for a particular Python extension. -- albert chin (china@thewrittenword.com) From Nicolas.Chauvat@logilab.fr Sat Apr 6 08:39:02 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Sat Apr 6 08:39:02 2002 Subject: [Distutils] Re: PEP 262: Database of Installed Python Packages In-Reply-To: Message-ID: On Wed, 27 Mar 2002, A.M. Kuchling wrote: > A package database is a necessary prequisite for managing the Python > packages installed on a system. PEP 262 lists the requirements for > such a database and specifies a storage format for it. > > I'd like to get this into Python 2.3, hopefully with a > still-to-be-specified package management tool. Assuming no one points > out some requirement or use case missing from this draft of the PEP, > my next step will be to write a proposed interface, post that draft, > and then implement the PEP and integrate it with the Distutils. > > Comments can be posted to comp.lang.python or to the Distutils SIG. Here is an item for the wishlist: Installing a new package and recording its name and file-list in a database is one thing. RPM does that. Easily maintaining a package-based system is another. APT+DPKG does that thanks to all the features it has over RPM (downloading the list of available packages from a mirror of the unified repository, checking integrity, calculating dependencies, etc.), but also thanks to the work of hundreds of debian developers that take care of all the dependencies between packages and upload their packages to a central coherent repository. I would be cool to have the equivalent for Python. We more or less already have that with Debian, for Python extension packages are packaged as Debian packages and can be upgraded on one debian host with a single ATP command. To my knowledge, APT has nothing DPKG-specific. If what we are after is to let people manage and upgrade their installed python packages. What about replacing DPKG with its Python couterpart and let APT handle the rest of the trouble? Is it really needed to fully implement yet another packaging system? Or is the proposal just about a DPKG-replacement for Python packages and did the mention of APT at the beginning of the PEP lead me to a misunderstanding? My last question: why should we have package management system "internal" to a Python installation. Isn't it the role of the distro to handle packages and should't we focus on helping out the existing distro tools deal with Python extensions instead? My 2 Eurocents. -- Nicolas Chauvat http://www.logilab.com - "Mais oł est donc Ornicar ?" - LOGILAB, Paris (France) From thomas.heller@ion-tof.com Mon Apr 8 05:15:03 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Apr 8 04:15:03 2002 Subject: [Distutils] Re: Help with --with-pydebug installation of NumPy on Windows? References: Message-ID: <039a01c1ded5$6ed75290$e000a8c0@thomasnotebook> [CC to distutils-sig. The context is: distutils doesn't work with source distributions on windows] David, Tim, Here is a patch which allows distutils on windows to work with the source distribution. I've tested it with Numeric, but nothing else so far: Index: build_ext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v retrieving revision 1.79 diff -c -r1.79 build_ext.py *** build_ext.py 31 Jan 2002 18:56:00 -0000 1.79 --- build_ext.py 8 Apr 2002 08:09:33 -0000 *************** *** 167,172 **** --- 167,176 ---- else: self.build_temp = os.path.join(self.build_temp, "Release") + # Append the source distribution include and library directories + self.include_dirs.append(os.path.join(sys.exec_prefix, 'PC')) + self.library_dirs.append(os.path.join(sys.exec_prefix, 'PCBuild')) + # OS/2 (EMX) doesn't support Debug vs Release builds, but has the # import libraries in its "Config" subdirectory if os.name == 'os2': And here is one which is also very useful for debug builds: it feeds absolute path names to MSVC, which has the advantage that the MSVC debugger finds the debugged files automatically, without asking the user to find them: Index: msvccompiler.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/msvccompiler.py,v retrieving revision 1.45 diff -c -r1.45 msvccompiler.py *** msvccompiler.py 8 Feb 2002 14:41:31 -0000 1.45 --- msvccompiler.py 8 Apr 2002 08:12:47 -0000 *************** *** 309,314 **** --- 309,316 ---- else: self.mkpath (os.path.dirname (obj)) + if debug: + src = os.path.abspath(src) if ext in self._c_extensions: input_opt = "/Tc" + src elif ext in self._cpp_extensions: IMO, both changes look innocent enough so that I could check them into CVS. Thomas From akuchlin@mems-exchange.org Mon Apr 8 14:32:02 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Apr 8 13:32:02 2002 Subject: [Distutils] Re: PEP 262: Database of Installed Python Packages In-Reply-To: References: Message-ID: <20020408173117.GA2616@crystal.mems-exchange.org> On Sat, Apr 06, 2002 at 03:38:08PM +0200, Nicolas Chauvat wrote: >Or is the proposal just about a DPKG-replacement for Python packages and >did the mention of APT at the beginning of the PEP lead me to a >misunderstanding? Long-term I would like to see a system which offers much of the same features as APT, so the underlying database needs to store enough information to make that possible, but the PEP only aims at specifying the DPKG-like level of things; a package maintenance interface is left for another PEP. >My last question: why should we have package management system "internal" >to a Python installation. Isn't it the role of the distro to handle >packages and should't we focus on helping out the existing distro tools >deal with Python extensions instead? What do we do for people on systems without packaging systems such as DPKG or RPM? --amk (www.amk.ca) There are, one presumes, tone-deaf readers. -- Robertson Davies, _A Voice from the Attic_ From pbienst@MIT.EDU Mon Apr 8 18:22:08 2002 From: pbienst@MIT.EDU (Peter Bienstman) Date: Mon Apr 8 17:22:08 2002 Subject: [Distutils] Non-typical scenario Message-ID: <1018299637.14832.24.camel@hunsmac.mit.edu> I'm trying to write a setup.py, but I'm having a few problems because of the following a-typical requirements: 1) I want all my extension modules ('e.so'), python scripts ('s1.py', 's2.py') and data files in a separate directory 'MyProject' under site-packages, but I want them to be available from the root package, so that I can type 'from e import *', rather than 'from MyProject.e import *'. Is there any way to do this with distutils? 2) the development versions of s1.py and s2.py live in completely different directories, but I still want distutils to copy them over to the same 'MyProject' directory, where they would be avaible from the root package. I haven't found a way to do this. 3) using data_files = [("MyProjects"), ...] copies the data files over to /usr/local/MyProjects, however, I want them to end up in /usr/local/lib/python-x.x/site-packages/MyProjects, where all my other stuff lives. If I have to explicitly specify a Python version number, my code won't be portable. Thanks for any help you can provide. Kind regards, Peter From David Abrahams" <039a01c1ded5$6ed75290$e000a8c0@thomasnotebook> Message-ID: <011301c1df83$0fab9f20$6601a8c0@boostconsulting.com> Thanks very much, Thomas! I would have done something like this myself, but I don't know the distutils internals very well. I hope you get this into the next release. Does it require any external stimulation (e.g. setup.py changes), or does it "just work"? -Dave ----- Original Message ----- From: "Thomas Heller" To: "Tim Peters" ; "David Abrahams" Cc: Sent: Monday, April 08, 2002 3:14 AM Subject: Re: Help with --with-pydebug installation of NumPy on Windows? > [CC to distutils-sig. The context is: distutils doesn't work > with source distributions on windows] > > David, Tim, > > Here is a patch which allows distutils on windows to work > with the source distribution. I've tested it with Numeric, > but nothing else so far: > > Index: build_ext.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v > retrieving revision 1.79 > diff -c -r1.79 build_ext.py > *** build_ext.py 31 Jan 2002 18:56:00 -0000 1.79 > --- build_ext.py 8 Apr 2002 08:09:33 -0000 > *************** > *** 167,172 **** > --- 167,176 ---- > else: > self.build_temp = os.path.join(self.build_temp, "Release") > > + # Append the source distribution include and library directories > + self.include_dirs.append(os.path.join(sys.exec_prefix, 'PC')) > + self.library_dirs.append(os.path.join(sys.exec_prefix, 'PCBuild')) > + > # OS/2 (EMX) doesn't support Debug vs Release builds, but has the > # import libraries in its "Config" subdirectory > if os.name == 'os2': > > And here is one which is also very useful for debug builds: it feeds > absolute path names to MSVC, which has the advantage that the MSVC debugger > finds the debugged files automatically, without asking the user to find them: > > Index: msvccompiler.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/distutils/msvccompiler.py,v > retrieving revision 1.45 > diff -c -r1.45 msvccompiler.py > *** msvccompiler.py 8 Feb 2002 14:41:31 -0000 1.45 > --- msvccompiler.py 8 Apr 2002 08:12:47 -0000 > *************** > *** 309,314 **** > --- 309,316 ---- > else: > self.mkpath (os.path.dirname (obj)) > > + if debug: > + src = os.path.abspath(src) > if ext in self._c_extensions: > input_opt = "/Tc" + src > elif ext in self._cpp_extensions: > > IMO, both changes look innocent enough so that I could check > them into CVS. > > Thomas > From thomas.heller@ion-tof.com Tue Apr 9 04:50:02 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Apr 9 03:50:02 2002 Subject: [Distutils] Re: Help with --with-pydebug installation of NumPy on Windows? References: <039a01c1ded5$6ed75290$e000a8c0@thomasnotebook> <011301c1df83$0fab9f20$6601a8c0@boostconsulting.com> Message-ID: <052401c1df9b$139b8a10$e000a8c0@thomasnotebook> From: "David Abrahams" > Thanks very much, Thomas! I would have done something like this myself, > but I don't know the distutils internals very well. > > I hope you get this into the next release. Does it require any external > stimulation (e.g. setup.py changes), or does it "just work"? > As far as I know, it does just work. *Does* it work for you? Thomas > -Dave From Taradino@subdimension.com Tue Apr 9 06:22:01 2002 From: Taradino@subdimension.com (Johannes L. Gijsbers) Date: Tue Apr 9 05:22:01 2002 Subject: [Distutils] Non-typical scenario Message-ID: <3cb2c0e9.8a4.1804289383@subdimension.com> > I'm trying to write a setup.py, but I'm having a few > problems because of the following a-typical requirements: > > 1) I want all my extension modules ('e.so'), python > scripts ('s1.py', 's2.py') and data files in a separate > directory 'MyProject' under site-packages, but I want them > to be available from the root package, so that I can type > 'from e import *', rather than 'from MyProject.e import > *'. Is there any way to do this with distutils? I don't think that's a distutils problem, it's just the way packages are set up. Would 'from MyProject import *' also be okay? Then you could write a __init__.py which imports everything from the 'e' module: 'from e import *', and place it in the package directory. Johannes Gijsbers _____________________________________________________________________ // free anonymous email || forums \\ subZINE || anonymous browsing subDIMENSION -- http://www.subdimension.com From David Abrahams" <039a01c1ded5$6ed75290$e000a8c0@thomasnotebook> <011301c1df83$0fab9f20$6601a8c0@boostconsulting.com> <052401c1df9b$139b8a10$e000a8c0@thomasnotebook> Message-ID: <016601c1dfbf$efb79ce0$6601a8c0@boostconsulting.com> Swamped right now, but when I get a chance I'll let you know. -D ----- Original Message ----- From: "Thomas Heller" > As far as I know, it does just work. *Does* it work for you? From slash@dotnetslash.net Tue Apr 9 12:28:03 2002 From: slash@dotnetslash.net (Mark W. Alexander) Date: Tue Apr 9 11:28:03 2002 Subject: [Distutils] Re: PEP 262: Database of Installed Python Packages In-Reply-To: <20020408173117.GA2616@crystal.mems-exchange.org> Message-ID: Nicolas Chauvat asked: > >My last question: why should we have package management system > >"internal" to a Python installation. Isn't it the role of the > >distro to handle packages and should't we focus on helping out the > >existing distro tools deal with Python extensions instead? Then Andrew asked: > What do we do for people on systems without packaging systems such > as DPKG or RPM? I did a bdist_pkgtool for Solaris and a bdist_sdux for HP. The advantage that distutils gives me is that I can get a module and run setup.py for each architecture. After that, everything is native for whatever package system the OS uses. All python packages show up when I list installed packages through the native package manager interface. IIRC, the bdist_wininst is the same. Once installed, packages on Windows show up in Add/Remove programs just like any other installed component. I think this is the way it should be. We don't want to create another layer for admins to manage python packages. For example, if I didn't use native packages on Solaris and HP, but did on Linux, in order to automagically maintain an inventory of installed software on all machines, I'd have to "know" that on certain OS'es to query both the native package manager and the distutils DB. This places an extra burden on administrators should they chose (or be coerced) to support python package users on their systems. If distutils is to help drive the growth of Python to other OS'es, then it needs to make package installation and maintence _exactly_ the same for any other packages on those OS'es. The way to do that is to grow the number of bdist commands until it equals the number of native package managers. By focusing on bdist commands, we don't have to have an "internal" python package management system, and we don't have to deal with non-Python oriented admins that don't care to deal with another way of installing and managing packages. ("Please install this package" is much more likely to be granted than "Can you build this binary for me?") mwa From mal@lemburg.com Tue Apr 9 12:45:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Apr 9 11:45:01 2002 Subject: [Distutils] Re: PEP 262: Database of Installed Python Packages References: Message-ID: <3CB30BE6.23121D21@lemburg.com> "Mark W. Alexander" wrote: > > Nicolas Chauvat asked: > > >My last question: why should we have package management system > > >"internal" to a Python installation. Isn't it the role of the > > >distro to handle packages and should't we focus on helping out the > > >existing distro tools deal with Python extensions instead? > > Then Andrew asked: > > What do we do for people on systems without packaging systems such > > as DPKG or RPM? > > I did a bdist_pkgtool for Solaris and a bdist_sdux for HP. The > advantage that distutils gives me is that I can get a module and run > setup.py for each architecture. After that, everything is native for > whatever package system the OS uses. All python packages show up when > I list installed packages through the native package manager > interface. IIRC, the bdist_wininst is the same. Once installed, > packages on Windows show up in Add/Remove programs just like any other > installed component. > > I think this is the way it should be. +1. Also +1 on adding more bdist_* package support e.g. bdist_deb and an extended version of bdist_rpm to accomodate specific settings for various RPM-based distros (if needed). > We don't want to create another > layer for admins to manage python packages. For example, if I didn't > use native packages on Solaris and HP, but did on Linux, in order to > automagically maintain an inventory of installed software on all > machines, I'd have to "know" that on certain OS'es to query both the > native package manager and the distutils DB. This places an extra > burden on administrators should they chose (or be coerced) to support > python package users on their systems. > > If distutils is to help drive the growth of Python to other OS'es, > then it needs to make package installation and maintence _exactly_ the > same for any other packages on those OS'es. The way to do that is to > grow the number of bdist commands until it equals the number of native > package managers. By focusing on bdist commands, we don't have to > have an "internal" python package management system, and we don't have > to deal with non-Python oriented admins that don't care to deal with > another way of installing and managing packages. ("Please install this > package" is much more likely to be granted than "Can you build this > binary for me?") Right. -- Marc-Andre Lemburg ________________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Tue Apr 9 13:42:02 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Apr 9 12:42:02 2002 Subject: [Distutils] Re: PEP 262: Database of Installed Python Packages In-Reply-To: <3CB30BE6.23121D21@lemburg.com> References: <3CB30BE6.23121D21@lemburg.com> Message-ID: <20020409164146.GC8520@crystal.mems-exchange.org> On Tue, Apr 09, 2002 at 05:42:30PM +0200, M.-A. Lemburg wrote: >Also +1 on adding more bdist_* package support e.g. bdist_deb >and an extended version of bdist_rpm to accomodate specific >settings for various RPM-based distros (if needed). Ironically bdist_deb is the most significant missing format; apparently it's really difficult to automatically build the right control file. (I don't remember the details; someone interested in taking this on should consult the distutil-sig archives.) --amk (www.amk.ca) Dots [...]: Small marks variously made to indicate infinity, hesitation, duplication, or lack of imagination. -- Peter Greenaway, _Rosa: The Death of a Composer_ From slash@dotnetslash.net Tue Apr 9 16:15:08 2002 From: slash@dotnetslash.net (Mark W. Alexander) Date: Tue Apr 9 15:15:08 2002 Subject: [Distutils] Re: PEP 262: Database of Installed Python Packages In-Reply-To: <20020409164146.GC8520@crystal.mems-exchange.org> Message-ID: On Tue, 9 Apr 2002, Andrew Kuchling wrote: > On Tue, Apr 09, 2002 at 05:42:30PM +0200, M.-A. Lemburg wrote: > >Also +1 on adding more bdist_* package support e.g. bdist_deb > >and an extended version of bdist_rpm to accomodate specific > >settings for various RPM-based distros (if needed). > > Ironically bdist_deb is the most significant missing format; > apparently it's really difficult to automatically build the right > control file. (I don't remember the details; someone interested in > taking this on should consult the distutil-sig archives.) There's always the functional and completely assinine method of wrapping bdist_rpm with a call to alien. I've considered bdist_deb, but frankly alien has served my needs well enough for the few Debian boxes I have..... ( ^ |____ obligitory dots to comply with amk's sig. Guess which category this proposal falls in) I simply don't have the time for the "right" way, but if an alien wrapper is an acceptable intermediate step, I'll take it on. > --amk (www.amk.ca) > Dots [...]: Small marks variously made to indicate infinity, > hesitation, duplication, or lack of imagination. > -- Peter Greenaway, _Rosa: The Death of a Composer_ mwa From DavidA@ActiveState.com Tue Apr 9 20:00:01 2002 From: DavidA@ActiveState.com (David Ascher) Date: Tue Apr 9 19:00:01 2002 Subject: [Distutils] Where should 'scripts' go... Message-ID: <3CB37225.35056682@activestate.com> Currently, scripts go somewhere in the "Scripts" directory (e.g. on Windows, something like C:\Python22\Scripts, on Unix somewhere in the bin/ directory. If people specify scripts that live in subdirectories in their source tree, using current distutils, those then get placed in subdirectories of the [bin|Scripts] directory. To my mind, this is somewhat wrong, since I expect scripts (those things which have a #! line, an executable bit set, etc.) to all be placed into a single directory. It means that I don't need to muck w/ my PATH if I install a package that has a script. Is my mind right or is my mind wrong? I'll help fix distutils if I'm right, and I'll fix ActivePython's current PPM behavior if I'm wrong. =) --david From slash@dotnetslash.net Tue Apr 9 20:37:01 2002 From: slash@dotnetslash.net (Mark W. Alexander) Date: Tue Apr 9 19:37:01 2002 Subject: [Distutils] Where should 'scripts' go... In-Reply-To: <3CB37225.35056682@activestate.com> Message-ID: On Tue, 9 Apr 2002, David Ascher wrote: > Currently, scripts go somewhere in the "Scripts" directory (e.g. on > Windows, something like C:\Python22\Scripts, on Unix somewhere in the > bin/ directory. > > If people specify scripts that live in subdirectories in their source > tree, using current distutils, those then get placed in subdirectories > of the [bin|Scripts] directory. > > To my mind, this is somewhat wrong, since I expect scripts (those things > which have a #! line, an executable bit set, etc.) to all be placed into > a single directory. It means that I don't need to muck w/ my PATH if I > install a package that has a script. > > Is my mind right or is my mind wrong? I'll help fix distutils if I'm > right, and I'll fix ActivePython's current PPM behavior if I'm wrong. =) Yes and no. User executed scripts should probably be on the default path, but some scripts are only executed by other scripts and can go anywhere as long as the primary scripts know where they are. For example a script to execute a user interface might go in /usr/bin. Support scripts invoked in response to user actions might be in /usr/lib/appname. Distutils should support whatever the package(r) needs. (I haven't used the "scripts" capability, so I can't speak as to how it's done.) mwa From DavidA@ActiveState.com Tue Apr 9 21:23:01 2002 From: DavidA@ActiveState.com (David Ascher) Date: Tue Apr 9 20:23:01 2002 Subject: [Distutils] Where should 'scripts' go... References: Message-ID: <3CB3858E.5D5E967B@activestate.com> > Yes and no. User executed scripts should probably be on the default > path, but some scripts are only executed by other scripts and can go > anywhere as long as the primary scripts know where they are. I don't know that anyone uses the latter kind. I would propose that a new mechanism be invented to deal with those. --da From markos@elite.org Wed Apr 10 02:37:01 2002 From: markos@elite.org (Marko Samastur) Date: Wed Apr 10 01:37:01 2002 Subject: [Distutils] distutils in Mandrake 8.2 Message-ID: <20020410053608.B5DB436E483@hydra.aufbix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a problem that I'm not able to solve on my own. I'm using python2.2 that comes with Mandrake Linux distribution 8.2. I have a tree of python sources that I'd like to package in more or less the same tree, which would be installed in site-packages under subdirectories pyortal and pyortal-modules. If I understand python documentation correctly, if I want those modules to be easily accessible for everyone, I need to have .pth file in site-packages that points to all subdirectories (and right, if I create it manually, it works). The problem I have is that if I run bdist_rpm, I can see a message that is telling me that .pth is being build, but the file is missing in the created rpm. If I build with bdist only, it creates and includes pyortal.pth (but it only lists pyortal directory in it without any subdirectory). So, what am I doing wrong? While I'm at it...is there an easy way to include normal text files in module distribution? Again, if I'm not mistaken, the current way to achieve this is to list every one of them in MANIFEST.in. Thank you for your help. Kind regards, Marko - -- HP: http://elite.org/~markos PGP:http://elite.org/~markos/markos.key Jabber: markos@aufbix.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8s89FkqL33r/UuYQRAqE8AJ9S0fHXskurhNaNJAZb6dozIaIp3wCgmp5H OKIbEEFDqmrFtgvsiGM/BO0= =GPH1 -----END PGP SIGNATURE----- From mal@lemburg.com Wed Apr 10 06:15:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Apr 10 05:15:01 2002 Subject: [Distutils] distutils in Mandrake 8.2 References: <20020410053608.B5DB436E483@hydra.aufbix.org> Message-ID: <3CB4029F.E709D2F9@lemburg.com> Marko Samastur wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have a problem that I'm not able to solve on my own. I'm using > python2.2 that comes with Mandrake Linux distribution 8.2. > > I have a tree of python sources that I'd like to package in more or > less the same tree, which would be installed in site-packages under > subdirectories pyortal and pyortal-modules. > > If I understand python documentation correctly, if I want those modules > to be easily accessible for everyone, I need to have .pth file in > site-packages that points to all subdirectories (and right, if I create > it manually, it works). The problem I have is that if I run bdist_rpm, > I can see a message that is telling me that .pth is being build, but > the file is missing in the created rpm. Why .pth files ? Why not simply *copy* the code to site-packages ? > If I build with bdist only, it creates and includes pyortal.pth (but it > only lists pyortal directory in it without any subdirectory). So, what > am I doing wrong? > > While I'm at it...is there an easy way to include normal text files in > module distribution? Again, if I'm not mistaken, the current way to > achieve this is to list every one of them in MANIFEST.in. I think you only need to put *.txt into MANIFEST.in (provided your text files use that extension). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From markos@elite.org Wed Apr 10 06:35:03 2002 From: markos@elite.org (Marko Samastur) Date: Wed Apr 10 05:35:03 2002 Subject: [Distutils] distutils in Mandrake 8.2 In-Reply-To: <3CB4029F.E709D2F9@lemburg.com> References: <20020410053608.B5DB436E483@hydra.aufbix.org> <3CB4029F.E709D2F9@lemburg.com> Message-ID: <20020410093408.B394B53505@mail.voljatel.si> On Wednesday 10 April 2002 11:15, M.-A. Lemburg wrote: > > > > I can see a message that is telling me that .pth is being build, but > > the file is missing in the created rpm. > > Why .pth files ? Why not simply *copy* the code to site-packages ? Mainly, but not only, because of estetic reasons. My project already has 26 .py files and this number will only rise. Dumping them all in one directory (and other authors doing the same), would just make that directory look like a trashcan and could also result in filename conflicts (which can be otherwise avoided if certain modules in subdirectories are never directly imported). Kind regards, Marko From Paul.Moore@atosorigin.com Wed Apr 10 07:14:01 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed Apr 10 06:14:01 2002 Subject: [Distutils] distutils in Mandrake 8.2 Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B2B6@UKRUX002.rundc.uk.origin-it.com> From: Marko Samastur [mailto:markos@elite.org] > > Why .pth files ? Why not simply *copy* the code to site-packages ? > > Mainly, but not only, because of estetic reasons. My > project already has 26 .py files and this number will only rise. > > Dumping them all in one directory (and other authors doing > the same), would just make that directory look like a trashcan > and could also result in filename conflicts (which can be > otherwise avoided if certain modules in subdirectories are > never directly imported). So why not make your stuff a proper package? That's the correct way of handling this. If you don't want your users to have to cope with multi-level names, you can always do some magic in __init__.py. But frankly, multi-level names shouldn't be seen as a problem to be overcome - they are a *convenience* to avoid name clashes, and should be used for that purpose. Paul. From markos@elite.org Wed Apr 10 07:28:01 2002 From: markos@elite.org (Marko Samastur) Date: Wed Apr 10 06:28:01 2002 Subject: [Distutils] distutils in Mandrake 8.2 In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53B01B5B2B6@UKRUX002.rundc.uk.origin-it.com> References: <714DFA46B9BBD0119CD000805FC1F53B01B5B2B6@UKRUX002.rundc.uk.origin-it.com> Message-ID: <20020410102632.CC01453501@mail.voljatel.si> On Wednesday 10 April 2002 12:11, you wrote: > > So why not make your stuff a proper package? That's the correct way of Because I didn't know how to do it until now (I know, it's written in Tutorial, but it's been a while since I last read it). Of course you are right, that's more clean way to do it. Thank you and Marc for your help. Marko From mal@lemburg.com Wed Apr 10 07:34:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Apr 10 06:34:02 2002 Subject: [Distutils] distutils in Mandrake 8.2 References: <20020410053608.B5DB436E483@hydra.aufbix.org> <3CB4029F.E709D2F9@lemburg.com> <20020410093408.B394B53505@mail.voljatel.si> Message-ID: <3CB41534.B6226EC0@lemburg.com> Marko Samastur wrote: > > On Wednesday 10 April 2002 11:15, M.-A. Lemburg wrote: > > > > > > I can see a message that is telling me that .pth is being build, but > > > the file is missing in the created rpm. > > > > Why .pth files ? Why not simply *copy* the code to site-packages ? > > Mainly, but not only, because of estetic reasons. My project already has 26 > .py files and this number will only rise. > > Dumping them all in one directory (and other authors doing the same), would > just make that directory look like a trashcan and could also result in > filename conflicts (which can be otherwise avoided if certain modules in > subdirectories are never directly imported). Why not wrap them up as one or more Python packages ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists@mceahern.com Fri Apr 12 13:26:03 2002 From: marklists@mceahern.com (Mark McEahern) Date: Fri Apr 12 12:26:03 2002 Subject: [Distutils] separate software from data Message-ID: Here's the short form of my question: How do people generally keep their Python modules and any configuration data for those Python modules separate? I'm looking for both conventions (e.g., config goes in /etc/foo) and mechanics (e.g., use distutils with options x, y, and z). The longer form of the question is a bit more convoluted, so for those with patience, read on. ;-) I'm transitioning from Windows to Linux. So part of my question is about the conventions for separating software from data on Linux. I assume it's self-explanatory why you'd want to separate software from data. In case it's not, here's why I think it's important to separate: You don't really have to backup software (although you can if you want), but you do have to backup data (it's not like you can re-download it). So, if push comes to shove, and you have limited resources/time, it's nice to be able to focus on the important stuff and only back that up. There's always a gray line between software and data that I label configuration data. In the Linux world, I guess that'd constitute anything you do to install any piece of software beyond the equivalent of configure; make; make install. If you specify any configuration options, create daemon accounts, etc.--ideally you'd do that with a script and you'd store that script somewhere along with your data, so that you not only knew what you did, but you could easily re-do it. I've looked at distutils and it's not immediately obvious that it was designed to solve the distribution problem in the particular what I want to try to solve it, although I suppose I may be able to extend distutils with special commands to do something like this? I want a way to say something like this: Install my module here: /usr/local/lib/pythonX.Y/site-packages/ By default, place configuration data here: /etc/my-package/ But if the installer specifies different configuration options when running setup.py, then use those values when generating mypackage.conf from mypackage.conf.template. Of course, the person installing the package should be able to override where configuration data is stored: $ python setup.py --configdir=/var/foo If such an option existed, its effect might be to generate a configuration file in the root of the package's module distribution folder: /site-packages/mymodule/mymodule.conf containing something readable by ConfigParser: [locations] prefix=/etc/mymodule/ connections=%prefix/connections.xml So that at runtime, the module first looks to the configuration information in its package distribution to determine where it needs to look for the distribution-specific configuration information? Shwew. Has anybody tackled this problem or do most folks just punt on this issue and assume they can plop configuration information alongside their distributed modules without providing any easy way for the person who installs it to override that? Thanks, // mark From davida@pobox.com Sat Apr 13 00:35:01 2002 From: davida@pobox.com (David Arnold) Date: Fri Apr 12 23:35:01 2002 Subject: [Distutils] separate software from data In-Reply-To: Your message of "Fri, 12 Apr 2002 11:25:30 EST." Message-ID: <200204130328.g3D3SHk06447@xevious.dstc.monash.edu.au> -->"Mark" == Mark McEahern writes: Mark> Here's the short form of my question: How do people generally Mark> keep their Python modules and any configuration data for those Mark> Python modules separate? i use the distutils/setup.py data_files option. Mark> I'm looking for both conventions (e.g., config goes in Mark> /etc/foo) and mechanics (e.g., use distutils with options x, Mark> y, and z). i put static config into $(PREFIX)/etc. here's a cutting from my setup.py <...> data_files = [("info", ["doc/pe4.info"]), ("doc", ["doc/pe4.pdf", "doc/pe4.html"]), ("etc", ["etc/pe4_client.pem", "etc/pe4_elvin_ca.pem"]), ] <...> Mark> Install my module here: Mark> /usr/local/lib/pythonX.Y/site-packages/ Mark> By default, place configuration data here: Mark> /etc/my-package/ normally, configuration data for /usr/local packages would go into /usr/local/etc (ie. /usr/local is the install prefix). Mark> Has anybody tackled this problem or do most folks just punt on Mark> this issue and assume they can plop configuration information Mark> alongside their distributed modules without providing any easy Mark> way for the person who installs it to override that? it's a problem. where you run into distutils limits like this, at least you have the option to sub-class the actions (i override the install class, for example). the biggest problem is the lack of documentation -- you really have to just read the code. d From Peter.Bienstman@rug.ac.be Mon Apr 15 11:07:10 2002 From: Peter.Bienstman@rug.ac.be (Peter Bienstman) Date: Mon Apr 15 10:07:10 2002 Subject: [Distutils] Require a specific Python version Message-ID: Hi, Is there any way to specify in setup.py that a particular distribution requires e.g. Python 2.2, such that an error is issued if users try to install it on an earlier Python version? Thanks, Peter From Peter.Bienstman@rug.ac.be Mon Apr 15 11:08:14 2002 From: Peter.Bienstman@rug.ac.be (Peter Bienstman) Date: Mon Apr 15 10:08:14 2002 Subject: [Distutils] Windows absolute paths Message-ID: Hi, I'm having trouble in getting Windows absolute paths like e.g d:\foo to work in distutils. They alway seem to be treated as a relative path... Thanks, Peter From mal@lemburg.com Mon Apr 15 11:32:09 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Apr 15 10:32:09 2002 Subject: [Distutils] Windows absolute paths References: Message-ID: <3CBAE499.3089D7BD@lemburg.com> Peter Bienstman wrote: > > Hi, > > I'm having trouble in getting Windows absolute paths like e.g d:\foo to > work in distutils. They alway seem to be treated as a relative path... distutils uses Unix path names internally, i.e. / instead of \. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Mon Apr 15 11:34:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Apr 15 10:34:02 2002 Subject: [Distutils] Require a specific Python version References: Message-ID: <3CBAE4DA.D92C040E@lemburg.com> Peter Bienstman wrote: > > Hi, > > Is there any way to specify in setup.py that a particular > distribution requires e.g. Python 2.2, such that an error is issued if > users try to install it on an earlier Python version? import sys if sys.version < '2.2': print 'Wrong Python Version !!!' sys.exit(1) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From pbienst@MIT.EDU Mon Apr 15 11:56:01 2002 From: pbienst@MIT.EDU (Peter Bienstman) Date: Mon Apr 15 10:56:01 2002 Subject: [Distutils] Require a specific Python version In-Reply-To: <3CBAE4DA.D92C040E@lemburg.com> References: <3CBAE4DA.D92C040E@lemburg.com> Message-ID: <1018882275.25590.1.camel@hunsmac.mit.edu> > > Is there any way to specify in setup.py that a particular > > distribution requires e.g. Python 2.2, such that an error is issued if > > users try to install it on an earlier Python version? > > import sys > if sys.version < '2.2': > print 'Wrong Python Version !!!' > sys.exit(1) Yes, but I assume this won't show up when e.g. executing a binary installer for Windows? Peter From mal@lemburg.com Mon Apr 15 12:35:05 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Apr 15 11:35:05 2002 Subject: [Distutils] Require a specific Python version References: <3CBAE4DA.D92C040E@lemburg.com> <1018882275.25590.1.camel@hunsmac.mit.edu> Message-ID: <3CBAF32B.7A5BBD96@lemburg.com> Peter Bienstman wrote: > > > > Is there any way to specify in setup.py that a particular > > > distribution requires e.g. Python 2.2, such that an error is issued if > > > users try to install it on an earlier Python version? > > > > import sys > > if sys.version < '2.2': > > print 'Wrong Python Version !!!' > > sys.exit(1) > > Yes, but I assume this won't show up when e.g. executing a binary > installer for Windows? That's correct. The bdist_wininst command has an option for this though: ('target-version=', 'v', "require a specific python version" + " on the target system"), -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Peter.Bienstman@rug.ac.be Mon Apr 15 13:53:01 2002 From: Peter.Bienstman@rug.ac.be (Peter Bienstman) Date: Mon Apr 15 12:53:01 2002 Subject: [Distutils] Windows absolute paths In-Reply-To: <3CBAE499.3089D7BD@lemburg.com> Message-ID: On Mon, 15 Apr 2002, M.-A. Lemburg wrote: > Peter Bienstman wrote: > > > > Hi, > > > > I'm having trouble in getting Windows absolute paths like e.g d:\foo to > > work in distutils. They alway seem to be treated as a relative path... > > distutils uses Unix path names internally, i.e. / instead of \. Actually, it's not that simple. The following works, because setup.py lives in d:\bar ../foo None of these work: D:/foo /D:/foo //D:/foo D:\foo \D:\foo \\D:\foo Peter From mal@lemburg.com Mon Apr 15 14:11:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Apr 15 13:11:01 2002 Subject: [Distutils] Windows absolute paths References: Message-ID: <3CBB09A2.D31A003C@lemburg.com> Peter Bienstman wrote: > > On Mon, 15 Apr 2002, M.-A. Lemburg wrote: > > > Peter Bienstman wrote: > > > > > > Hi, > > > > > > I'm having trouble in getting Windows absolute paths like e.g d:\foo to > > > work in distutils. They alway seem to be treated as a relative path... > > > > distutils uses Unix path names internally, i.e. / instead of \. > > Actually, it's not that simple. > > The following works, because setup.py lives in d:\bar > > ../foo > > None of these work: > > D:/foo > /D:/foo > //D:/foo > D:\foo > \D:\foo > \\D:\foo Why would you want to put drive letters into the paths ? BTW, would '../d:/foo' work ? and if not, what's the error message you get ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Peter.Bienstman@rug.ac.be Mon Apr 15 14:27:01 2002 From: Peter.Bienstman@rug.ac.be (Peter Bienstman) Date: Mon Apr 15 13:27:01 2002 Subject: [Distutils] Windows absolute paths In-Reply-To: <3CBB09A2.D31A003C@lemburg.com> Message-ID: > > Actually, it's not that simple. > > > > The following works, because setup.py lives in d:\bar > > > > ../foo > > > > None of these work: > > > > D:/foo > > /D:/foo > > //D:/foo > > D:\foo > > \D:\foo > > \\D:\foo > > Why would you want to put drive letters into the paths ? Not in this example, but in my real-world scenario the files are on a different drive than setup.py > BTW, would '../d:/foo' work ? No luck.. > and if not, what's the error message you get ? 'File does not exist or is not a regular file'. I think 'd:/foo' gets interpreted as './d:/foo', which is why the file cannot be found. Peter From pearu@cens.ioc.ee Mon Apr 15 16:47:09 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Mon Apr 15 15:47:09 2002 Subject: [Distutils] Windows absolute paths In-Reply-To: Message-ID: On Mon, 15 Apr 2002, Peter Bienstman wrote: > > > The following works, because setup.py lives in d:\bar > > > > > > ../foo > > > > > > None of these work: > > > > > > D:/foo > > > /D:/foo > > > //D:/foo > > > D:\foo > > > \D:\foo > > > \\D:\foo Have you tried double / or \ after the drive letter: D:\\foo D://foo ? Pearu From Peter.Bienstman@rug.ac.be Mon Apr 15 17:19:01 2002 From: Peter.Bienstman@rug.ac.be (Peter Bienstman) Date: Mon Apr 15 16:19:01 2002 Subject: [Distutils] Windows absolute paths In-Reply-To: Message-ID: > Have you tried double / or \ after the drive letter: > > D:\\foo > D://foo D://foo doesn't work, but D:\\foo works! Thanks! Peter From frankm@hiwaay.net Mon Apr 15 21:14:02 2002 From: frankm@hiwaay.net (Frank McIngvale) Date: Mon Apr 15 20:14:02 2002 Subject: [Distutils] How to detect if C compiler installed? In-Reply-To: <20020416001024.9735.14211.Mailman@mail.python.org> Message-ID: Hi, I was wondering if there is a portable way to determine if a C compiler is available for compiling extensions. I'm working on a package that has some extensions that aren't strictly required, and I'd like to turn on/off building them based on whether a C compiler is available. (I know how to do the turn on/off thing, I just need to know how to check for a C compiler.) Any hints? frank From mwh@python.net Tue Apr 16 05:38:01 2002 From: mwh@python.net (Michael Hudson) Date: Tue Apr 16 04:38:01 2002 Subject: [Distutils] How to detect if C compiler installed? In-Reply-To: Frank McIngvale's message of "Mon, 15 Apr 2002 19:13:57 -0500 (CDT)" References: Message-ID: <2mvgasf39i.fsf@starship.python.net> Frank McIngvale writes: > Hi, I was wondering if there is a portable > way to determine if a C compiler is available for > compiling extensions. I'm working on a package > that has some extensions that aren't strictly > required, and I'd like to turn on/off building > them based on whether a C compiler is available. > > (I know how to do the turn on/off thing, I just > need to know how to check for a C compiler.) > > Any hints? Try it and catch an exception? I don't think there's a mechanism for asking (could be wrong though). Cheers, M. -- There are 'infinite' number of developed artifacts and one cannot develop appreciation for them all. It would be all right to not understand something, but it would be imbecilic to put judgements on things one don't understand. -- Xah, comp.lang.lisp From andy@reportlab.com Tue Apr 23 19:11:03 2002 From: andy@reportlab.com (Andy Robinson) Date: Tue Apr 23 18:11:03 2002 Subject: [Distutils] How to customize... Message-ID: Hello everybody, I'm hoping for some guidance on the best way to extend distutils and on whether it is suitable for problems Reportlab currently face. It seems very good at packing up bits of a python package hierarchy and recreating the same hierarchy elsewhere, but I can't figure out how to do some things. (Well, I can find ways, but figure I might be subverting the design or missing obvious things). The manual chapter on extending distutils is, ahem, short. I'm hoping these will be easy for you all! (1) Cross-wiring the output --------------------------- I want to create a little distribution for a corporate customer which direspects my package hierarchy. Reportlab has a 'reportlab' package for open source code, and an 'rlextra' package for other stuff. We also make a CVS tree for each customer. My CVS tree for the customer has this: hugeco/littleapp/littleapp.py hugeco/littleapp/setup.py <---presumably, see below I want to make a single directory which includes a bunch of files from elsewhere in our tree. I want to add in these into what the customer gets: rlextra/utils/rc4.py rlextra/utils/gloop.py rlextra/utils/cgisupport.py We have often done yucky stuff like checking in a copy of the rlextra files under the customer directory, and are fed up doing it. We can write code so we only have one version in the right place, but the customer inports the local onem and avoid duplications in CVS. Ideally, running sdist would assemble the 4 files above and create a combined output distribution which just dumped all 4 modules. Thus they would get a tar.gz containing littleapp-0.5/littleapp.py littleapp-0.5/rc4.py littleapp-0.5/gloop.py littleapp-0.5/cgisupport.py The manual descrivbes doing this for data files but not for source. Can you pull source from arbitrary directories? I KNOW that ideally I'd give them the rlextra tree or its subset packagized on their path, but we get situations where a self-contained app is really more desrirable; we can't inflict changes in the rlextra tree on other apps at the same time. How do I do this? (2) Where to put setup scripts ----------------------------- This is a minor "best practice" detail. The standard document presumes your setup.py is above your source tree. All my CVS projects live under C:\code. If I want to have setup scripts for project1, project2, project3, obviously I cannot have one setup.py above all 3. Do people normally maintain the setup script within the directory they want to pack up, and do a translation on the directories? or have multiple setup_project1.py, setup_project2.py etc above? (3) Shipping closed source software: ----------------------------------- Sometimes we only want to ship .pyc files. We're also looking at things like pyz archives, maybe with some additions so they can only be opened with a license key for paid-only software, but also just for the convenience. Is there anyone who has thought about extending distutils this way? how should I go about it? writing a new command (zdist??) (4) Verification on site ------------------------ With our own customer apps we include a 'signed source manifest' with checksums of each file in the manifest, and a 'signed target manifest' which does the same for pyc files and other compiled/optimized objects. Then at run time we can have verification functions. This helps because sometimes the customer fails to accurately promote some of a few hundred files onto a web cluster; we want to get back something saying that either the distro is perfect, or various files disagree with the manifest. In fact, I envision a meta-api where you could ask any app to verfy itself, run a test suite or so on. setup.py is the obvious hook. Is this a useful extension to distutils? Is there a good place to put such ideas in? Or would it be easier to roll our own? (5) General pace of activity ---------------------------- I am new to this sig. Is much happening? Is distutils basically seen as a solved problem or is a lot underway? Best Regards, Andy Robinson CEO/Chief Architect, Reportlab inc. From tshumway@uci.edu Tue Apr 23 20:44:01 2002 From: tshumway@uci.edu (Terrel Shumway) Date: Tue Apr 23 19:44:01 2002 Subject: [Distutils] Should MANIFEST.in be automatically included by sdist? Message-ID: <1019605404.16008.5.camel@localhost> When I create a package using MANIFEST.in, there is important information in that file. When I build a sdist, MANIFEST.in is ommitted, meaning that the package cannot reproduce itself. I think that if MANIFEST.in exists, it should automatically be included by sdist. If I add MANIFEST.in to itself, it gets included in all (even built) distributions, which I do not want. Am I missing something? -- Terrel From akuchlin@mems-exchange.org Wed Apr 24 11:56:09 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Apr 24 10:56:09 2002 Subject: [Distutils] Should MANIFEST.in be automatically included by sdist? In-Reply-To: <1019605404.16008.5.camel@localhost> References: <1019605404.16008.5.camel@localhost> Message-ID: <20020424145440.GB6180@ute.mems-exchange.org> On Tue, Apr 23, 2002 at 04:43:23PM -0700, Terrel Shumway wrote: >I think that if MANIFEST.in exists, it should automatically be included >by sdist. If I add MANIFEST.in to itself, it gets included in all (even >built) distributions, which I do not want. > >Am I missing something? Probably that's not done because it violates the "no magic" principle; Distutils would be making an assumption for you, and you'd either be unable to override it or we'd also have to add a way to suppress it. It's easier to just make everyone add "include MANIFEST.in" to their MANIFEST.in file. --amk (www.amk.ca) mnemonic. n. I had a wildly funny definition of this, but...oh, it may come back... -- Stan Kelly-Bootle, _The Computer Contradictionary_ From knight@baldmt.com Mon Apr 29 12:37:02 2002 From: knight@baldmt.com (Steven Knight) Date: Mon Apr 29 11:37:02 2002 Subject: [Distutils] bdist_wininst: post-installation changes? Message-ID: I don't think this is supported, but I just want to make sure... Is there any way, in the generated Win32 installer, to have it perform some arbitrary post-installation editing? To cover Win9x systems, I'd like to install a .bat file in C:\PythonXX\ using the Bruce Eckel preamble from the Python FAQ: @echo off rem = """ rem run python on this bat file. Needs the full path where rem you keep your python files. The -x causes python to skip rem the first line of the file: python -x c:\aaa\Python\\"%0".bat %1 %2 %3 %4 %5 %6 %7 %8 %9 goto endofpython rem """ # The python program goes here: The problem is that the "%0" expansion needs the full path name to where the .bat file is installed (C:\PythonXX\), and that's not known until the installer runs and consults the registry to find out where Python is located. Is there anything I can have the installer do to accomodate this? A quick glance at the code didn't turn up anything (but it *was* very quick... :-). --SK From mal@lemburg.com Mon Apr 29 13:04:05 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Apr 29 12:04:05 2002 Subject: [Distutils] bdist_wininst: post-installation changes? References: Message-ID: <3CCD6F0B.4855DD01@lemburg.com> Steven Knight wrote: > > I don't think this is supported, but I just want to make sure... > > Is there any way, in the generated Win32 installer, to have it perform > some arbitrary post-installation editing? Yes. Thomas Heller has checked in an update of the installer which supports this. You have to get it from CVS, though. > To cover Win9x systems, I'd like to install a .bat file in C:\PythonXX\ > using the Bruce Eckel preamble from the Python FAQ: > > @echo off > rem = """ > rem run python on this bat file. Needs the full path where > rem you keep your python files. The -x causes python to skip > rem the first line of the file: > python -x c:\aaa\Python\\"%0".bat %1 %2 %3 %4 %5 %6 %7 %8 %9 > goto endofpython > rem """ > > # The python program goes here: > > The problem is that the "%0" expansion needs the full path name to where > the .bat file is installed (C:\PythonXX\), and that's not known until > the installer runs and consults the registry to find out where Python is > located. > > Is there anything I can have the installer do to accomodate this? A > quick glance at the code didn't turn up anything (but it *was* very > quick... :-). No idea, I guess you'll have to look just a bit closer ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From thomas.heller@ion-tof.com Mon Apr 29 14:14:25 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Apr 29 13:14:25 2002 Subject: [Distutils] bdist_wininst: post-installation changes? References: <3CCD6F0B.4855DD01@lemburg.com> Message-ID: <07dc01c1efa1$12221080$e000a8c0@thomasnotebook> From: "M.-A. Lemburg" > Steven Knight wrote: > > > > I don't think this is supported, but I just want to make sure... > > > > Is there any way, in the generated Win32 installer, to have it perform > > some arbitrary post-installation editing? > > Yes. Thomas Heller has checked in an update of the installer > which supports this. You have to get it from CVS, though. > Right. The only documentation so far are the last two logmessages (ask me if you need more): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/distutils/misc/install.c and the updated bdist_wininst.py is here (watch out for wrapped URL): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/python/distutils/distutils/command/bdist_wininst.py?rev=1.31 > > To cover Win9x systems, I'd like to install a .bat file in C:\PythonXX\ > > using the Bruce Eckel preamble from the Python FAQ: > > > > @echo off > > rem = """ > > rem run python on this bat file. Needs the full path where > > rem you keep your python files. The -x causes python to skip > > rem the first line of the file: > > python -x c:\aaa\Python\\"%0".bat %1 %2 %3 %4 %5 %6 %7 %8 %9 > > goto endofpython > > rem """ > > > > # The python program goes here: > > > > The problem is that the "%0" expansion needs the full path name to where > > the .bat file is installed (C:\PythonXX\), and that's not known until > > the installer runs and consults the registry to find out where Python is > > located. Bruce's preamble can be simplyfied to this one: @runpython c:\aaa\Python\%0.bat %1 %2 %3 %4 %5 %6 %7 %8 %9 # start of python code print "Hello" # or whatever # EOF - you don't have to supply the 'endofpython' footer from above. when you have a batch file in your PATH named 'runpython.bat' which looks like this: @c:\python22\python -x %1 %2 %3 %4 %5 %6 %7 %8 %9 The full path before the %0.bat in the first file is still needed, unfortunately (or you always have to call your batch file with it's full pathname). Thomas From Paul.Moore@atosorigin.com Tue Apr 30 05:05:03 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Tue Apr 30 04:05:03 2002 Subject: [Distutils] bdist_wininst: post-installation changes? Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B2F0@UKRUX002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > Bruce's preamble can be simplyfied to this one: > > @runpython c:\aaa\Python\%0.bat %1 %2 %3 %4 %5 %6 %7 %8 %9 > # start of python code > print "Hello" # or whatever > # EOF - you don't have to supply the 'endofpython' footer from above. The simplest possible version I've found is @python -x %~f0 %* & goto :eof # start of python code import sys print "Hello", ', '.join(sys.argv[1:]) This works on Windows 2000 CMD.EXE. Probably also on NT and XP, but I don't have these to test. It's not likely to work on Windows 9x/ME, as the %~f0 and %* constructs aren't supported there. %* can be replaced by %1 %2 %3 %4 %5 %6 %7 %8 %9 as usual, but %~f0 (the full pathname of the current batch file) isn't in COMMAND.COM to my knowledge... Annoyingly, JP Software's 4NT doesn't correctly support %~f0, failing to include the .bat file extension unless it is typed in on the command line. I've reported this as a bug to JP software. The advantage of this version is that it *doesn't* need you to hard-code the full pathname of the BAT file. An alternative construct is %~dp0MYBATCHFILE.BAT. The %~dp0 construct gives the name of the directory containing the batch file. Again, this isn't 9x/ME compatible, to my knowledge. But it does work on all versions of NT/2000 and also in 4NT, FWIW. Hope this helps, Paul. From slash@dotnetslash.net Tue Apr 30 16:55:01 2002 From: slash@dotnetslash.net (Mark W. Alexander) Date: Tue Apr 30 15:55:01 2002 Subject: [Distutils] Documentation question Message-ID: Ok, I'm working on docs for bdist_pkgtool and bdist_sdux, but I'm completely TeX ignorant. I took the dist.tex file, cut out the RPM section and edited it for these packages. Now what? How do I test what the file actually produces, and how it fits in with the rest of the distutils docs? Next step, how do I submit the changes? (I assume as a patch to the doc file.) Pointers the whatever FM I'm looking for would be helpful. tia -- Mark W. Alexander slash@dotnetslash.net