From oliver.schoenborn at utoronto.ca Mon Nov 1 05:30:43 2004 From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn) Date: Mon Nov 1 05:31:55 2004 Subject: [Distutils] Manifestor.py Message-ID: <4185BBF3.1070609@utoronto.ca> Hello, I needed some manifest capabilities for my last distrib so I created a Manifestor.py based on the manifest stuff that's in sdist. It gives identical functionality and can be reused for other distutils aspects. For instance, for the data_files parameter to setup.py. E.g. a setup.py: dbManif = Manifestor('dbManif', deps=['db/db.py']) dbManif.loadManifest() # assume dbManif has a tree of files under a db folder: # db/db.txt # db/README.txt # db/... # then: setup(..., # put all db files in same tree under sys.prefix/Scripts: data_files=dbManif.getAsDataFiles(dest='Scripts') ) Here it is in case it is useful to others. Cheers, Oliver Schoenborn -------------- next part -------------- """ Based on manif code from distutils.command.sdist. Copyright @ 2004 Oliver Schoenborn License: same as Python """ import os # for os.path.* from sets import Set from glob import glob from distutils import dep_util, log from distutils.text_file import TextFile from distutils.filelist import FileList from distutils.errors import DistutilsTemplateError # if not name given for manifest file, this will be used: defaultManifName = 'MANIFEST' class Manifestor: """Class to generate a manifest (ie a list of files), either from a template or list of files. The manifest can be saved to disk or loaded. See section 9.2 of Python Library Manual for syntax of template file. """ def __init__(self, manifest=None, forceRegen=False, deps=None, autoPruneCVS=True, loadNow=False): """Parameters: - manifest: name of the manifest file. If not specified, defaults to the module-level variable defaultManifName. - forceRegen: if true, the manifest file will be regenerated from the assumed manifest template file of same name + ".in" extension. The syntax of the manifest template is the same as for distutils's MANIFEST.in. - deps: list of extra dependencies: if any of them are existing files that are more recent than the manifest file, that file is regenerated. - autoPruneCVS=False means that CVS folders will not be pruned. - loadNow: if true, will finish construction by calling loadManifest(), so after construction you can immediately call getFilenames() or getAsDataList(). """ self.__forceRegen = forceRegen if manifest is None: self.__manifest = defaultManifName else: self.__manifest = manifest self.__template = '%s.in' % self.__manifest # template is for sure a dependency self.__deps = Set([self.__template]) # combine with deps given by user: if deps is not None: self.__deps.union_update(deps) # prune CVS-related stuff automatically: self.__pruneSet = {} if autoPruneCVS: pruneCVS = r'%(pathSep)s(RCS|CVS)%(pathSep)s.*' self.addPrune(pruneCVS, is_regex=1) # for files added even if not specified using template self.__defaultFiles = [] # ok, done: self.__filelist = FileList() if loadNow: self.loadManifest() def addDependency(self, filename): """Add filename as a dependency. May cause the manifest file to be regenerated next time loadManifest() is called. See class doc for more info. """ self.__deps.add(filename) def addPrune(self, pattern, **flags): """Add a prunning pattern. Parameters are same as for distutils.filelist.FileList.include_pattern(), with the added bonus that if pattern contains a substitution item named pathSep, it gets properly substituted with path separator suitable for OS. E.g. pattern='%(pathSep)spat' will get replaced with '/pat' on unix but '\\\\pat' on windows. """ if os.path.sep == '\\': pathSep = os.path.sep*2 else: pathSep = os.path.sep pathSub = {'pathSep':pathSep} #log.debug(flags) self.__pruneSet[pattern % pathSub] = flags def addDefaultFile(self, fileGlob, filt=None): """Add file(s) obtained from glob(fileGlob) as default file(s) for the manifest, so it(they) need not be specified in the manifest template (if one is used). Filt is a filter, e.g. os.path.isfile if only files are desired. Returns True only if fileGlob found. """ ff = glob(fileGlob) if filt is not None: ff = filter(filt, ff) if ff != []: self.__defaultFiles.extend(ff) return True else: return False def addDefaultFileAlt(self, fileGlobs, filt=None): """Like addDefaultFile, but fileGlobs is a tuple that means "add the *first* of these alternatives". Return True only if one of the file globs was found. """ found = None for ffAltGlob in fileGlobs: ffAlt = glob(ffAltGlob) if filt is not None: ffAlt = filter(filt, ffAlt) if ffAlt != []: found = ffAlt break # if we get here then we haven't found it: if found is not None: self.__defaultFiles.extend(found) return True else: return False def needRegen(self): """Return True only if manifest file needs to be regenerated, False otherwise. It needs to be regenerated if any of its dependencies change, if forceRegen=True at construction time, or if neither a template nor a manifest file exist. """ someDepsNewer = False for ff in self.__deps: ffExists = os.path.isfile(ff) if ffExists: someDepsNewer |= dep_util.newer(ff, self.__manifest) noManifest = not os.path.isfile(self.__manifest) noTemplate = not os.path.isfile(self.__template) neitherExists = noTemplate and noManifest # Regenerate the manifest if necessary (or if explicitly told to) return someDepsNewer or neitherExists or self.__forceRegen def genManifest(self): """Generate manifest file from template. Note that this regenerates it even if not necessary, and saves it to "manifest.in", where "manifest"=name given at construction time. """ self.__filelist.findall() self.__addDefaults() self.__readTemplate() self.__pruneFileList() self.__filelist.sort() self.__filelist.remove_duplicates() def loadManifest(self): """Load list of file names from manifest file. If file doesn't exist, it will be generated (from template if there is one, or from defaults if there were some -- if neither, the manifest will be empty!).""" if self.needRegen(): self.genManifest() else: self.readManifest() def readManifest(self): """Read the manifest file. This raises exception if no manifest file was created (see genManifest() or loadManifest()). """ try: manifest = file(self.__manifest,'r') for line in manifest: self.__filelist.append(line.strip()) finally: manifest.close() def writeManifest(self): """Write the file names in manifest to manifest file. """ manifest = file(self.__manifest,'w') print "-> Writing to '%s'" % self.__manifest try: manifest.write("\n".join(self.__filelist.files)) finally: manifest.close() def delManifestFile(self, raiseIfNoExist=True): """Deletes manifest file from disk. If doesn't exist, OSError raised.""" if raiseIfNoExist: os.remove(self.__manifest) else: try: os.remove(self.__manifest) except OSError: pass def getFileNames(self): """Get list of file names loaded via a call to loadManifest().""" return self.__filelist.files def getAsDataList(self, dest=''): """Return the files in manifest, in format suitable for data_files parameter of distutils.setup(). Dest is the destination, under sys.prefix.""" if dest is not '': dest += '/' scmExtDest = ['%s%s'% (dest, os.path.dirname(extFile)) for extFile in self.__filelist.files] scmExtFiles = [[extFile] for extFile in self.__filelist.files] return zip(scmExtDest, scmExtFiles) #--------------------------------------------------------------- def __addDefaults(self): """Add files from self.__defaultFiles directly, without using FileList include/exclude.""" for fname in self.__defaultFiles: self.__filelist.append(fname) def __readTemplate(self): """Read and parse manifest template file named by self.__template. The parsing and processing is done by 'self.__filelist', which updates itself accordingly. """ template = TextFile(self.__template, strip_comments=1, skip_blanks=1, join_lines=1, lstrip_ws=1, rstrip_ws=1, collapse_join=1) while 1: line = template.readline() if line is None: # end of file break try: self.__filelist.process_template_line(line) except DistutilsTemplateError, msg: print "%s, line %d: %s" %\ (template.filename, template.current_line, msg) def __pruneFileList(self): """Prune off branches that might slip into the file list as created by '__readTemplate()', but really don't belong there. This includes any RCS or CVS directories, and any patterns added via addPrune(). """ for pat, flags in self.__pruneSet.iteritems(): self.__filelist.exclude_pattern(pat, **flags) #---------------------------------------------------------------------------- if __name__ == '__main__': def glob(pattern): # for ('alt1a','alt1b'), return second item globbed, # whereas for all else, return nothing found if pattern == 'alt1b': return ['alt1b1', 'alt1b2'] elif pattern.startswith('alt'): return [] # nothing found # for default files, only defFile1 returns a glob elif pattern == 'defFile1': return ['defFile1a', 'defFile1b'] elif pattern.startswith('defFile'): return [] return [] from distutils import filelist def findall(dir): fileList = [ 'file1', 'file2\\CVS\\Root', 'file3/prune', 'file4' ] return fileList filelist.findall = findall # without force # need generation: both no exist man = Manifestor("testManifNoExist") # no template, no manifest assert man.needRegen() # manifest exists, no template manif = file('testManifNoRegen','w') manif.close() man = Manifestor("testManifNoRegen") assert not man.needRegen() # with force man = Manifestor("testManifNoRegen",forceRegen=True) # manifest exists assert man.needRegen(), "Forced regen test failed" man.delManifestFile() # pruning, default files # need generation: newer deps manifIn = file('testManif.in','w') manifIn.write('global-include *\n') manifIn.close() man = Manifestor("testManif") assert man.needRegen() man.addPrune('prune',anchor=0) ok = man.addDefaultFile('defFile1') assert ok ok = man.addDefaultFile('defFile2') assert not ok ok = man.addDefaultFileAlt(('alt1a','alt1b')) assert ok ok = man.addDefaultFileAlt(('alt2a','alt2b')) assert not ok print "Loading manifest (creating from temporary testManif.in)" man.loadManifest() expectFiles = ['alt1b1', 'alt1b2', 'defFile1a', 'defFile1b', 'file1','file4'] assert man.getFileNames() == expectFiles, man.getFileNames() # cleanup: man.delManifestFile(raiseIfNoExist=False) os.remove('testManif.in') From lonetwin at gmail.com Mon Nov 1 16:26:09 2004 From: lonetwin at gmail.com (Steve) Date: Mon Nov 1 16:26:13 2004 Subject: [Distutils] Question about creating rpms using distutiils Message-ID: <5a309bd304110107264e4e311c@mail.gmail.com> Hi, For a python project at work I would like to start using distuils to build the rpms that currently are being built using gnu make+a custom script. The only problem is that by default the bdist_rpm also packages the '.py' files along with the compiled ".pyc's". For various management related reasons, distribution of the source code is not an option. Could someone please explain (with possibly and example) how to build a pure-pyc-only binary rpm ?? Regards Steve From slash at dotnetslash.net Mon Nov 1 21:25:09 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Mon Nov 1 21:25:11 2004 Subject: [Distutils] Question about creating rpms using distutiils In-Reply-To: <5a309bd304110107264e4e311c@mail.gmail.com> References: <5a309bd304110107264e4e311c@mail.gmail.com> Message-ID: <20041101202509.GB4108@dotnetslash.net> On Mon, Nov 01, 2004 at 08:56:09PM +0530, Steve wrote: > Hi, > For a python project at work I would like to start using distuils > to build the rpms that currently are being built using gnu make+a > custom script. The only problem is that by default the bdist_rpm also > packages the '.py' files along with the compiled ".pyc's". For various > management related reasons, distribution of the source code is not an > option. > Could someone please explain (with possibly and example) how to > build a pure-pyc-only binary rpm ?? Before you jump through too many hoops, are you aware of how trivial it is to restore the source from a .pyc file? http://www.crazy-compilers.com/decompyle/ mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials, if any, are retained by the original author(s). http://creativecommons.org/licenses/by-nc/2.0/ From symbiont at berlios.de Tue Nov 2 09:43:29 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Tue Nov 2 09:44:19 2004 Subject: [Distutils] Question about creating rpms using distutiils In-Reply-To: <5a309bd304110107264e4e311c@mail.gmail.com> References: <5a309bd304110107264e4e311c@mail.gmail.com> Message-ID: <200411021643.29138.symbiont@berlios.de> On Monday 01 November 2004 23:26, Steve wrote: > ? Could someone please explain (with possibly and example) how to > build a pure-pyc-only binary rpm ?? Hack this in a wrapper script or something: In %install, after setup.py install --record=INSTALLED_FILES: sed 's/.*\.py$//' < INSTALLED_FILES >BINARY_FILES grep ".py$" INSTALLED_FILES >nukeit.tmp for f in `cat nukeit.tmp`; do rm -f $f done Then change %files: %files -f BINARY_FILES But, then again, distributing pyc is distributing the code too! (The bytecode) have fun, -- -jeff From lonetwin at gmail.com Thu Nov 4 11:54:27 2004 From: lonetwin at gmail.com (Steve) Date: Thu Nov 4 11:54:30 2004 Subject: [Distutils] Question about creating rpms using distutiils In-Reply-To: <200411021643.29138.symbiont@berlios.de> References: <5a309bd304110107264e4e311c@mail.gmail.com> <200411021643.29138.symbiont@berlios.de> Message-ID: <5a309bd30411040254396c4537@mail.gmail.com> Thanks Jeff, Mark for your replies. I guess I'll hack something up pon my own, like Jeff suggested. BTW, Yes I am aware that distributing the pyc's are like distributing the source code ...but well, try and explain that to my PHB dammit jim, I'm a coder, not a suit. :o) Regards Steve On Tue, 2 Nov 2004 16:43:29 +0800, Jeff Pitman wrote: > On Monday 01 November 2004 23:26, Steve wrote: > > Could someone please explain (with possibly and example) how to > > build a pure-pyc-only binary rpm ?? > > Hack this in a wrapper script or something: > > In %install, after setup.py install --record=INSTALLED_FILES: > > sed 's/.*\.py$//' < INSTALLED_FILES >BINARY_FILES > > grep ".py$" INSTALLED_FILES >nukeit.tmp > for f in `cat nukeit.tmp`; do > rm -f $f > done > > Then change %files: > > %files -f BINARY_FILES > > But, then again, distributing pyc is distributing the code too! (The > bytecode) > > have fun, > -- > -jeff > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > From calvin at users.sourceforge.net Thu Nov 4 12:43:15 2004 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Thu Nov 4 12:43:17 2004 Subject: [Distutils] Question about creating rpms using distutiils In-Reply-To: <5a309bd30411040254396c4537@mail.gmail.com> References: <5a309bd304110107264e4e311c@mail.gmail.com> <200411021643.29138.symbiont@berlios.de> <5a309bd30411040254396c4537@mail.gmail.com> Message-ID: <20041104114315.GA6076@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thu, Nov 04, 2004 at 04:24:27PM +0530, Steve wrote: > BTW, Yes I am aware that distributing the pyc's are like > distributing the source code ...but well, try and explain that to my > PHB The simplest solution to this problem is a code obfuscation tool, which is indeed quite effective and easy to use when the tool is not very buggy ;) Pyobfuscate seems to be such a tool, though I have not tested it. Python already has a zip file importer (look for zipimport.c in the Python source). So another solution is to write a custom module importer in C (which is somewhat harder to decompile) that can read encrypted modules. Regards, Bastian PS: there was also a thread on comp.lang.python about this: http://coding.derkeiler.com/Archive/Python/comp.lang.python/2003-10/3659.html - -- ,''`. Bastian Kleineidam . calvin (at) debian.org : :' : `. `' GnuPG Schl?ssel http://kampfwurst.net/gpgkey.txt `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBihXTeBwlBDLsbz4RAj/9AJ9gMS9s+l+Zy+ydflBz5DDEIQSGagCfRYVa xmr1tQ09VMgFHMINMsTCG3U= =PHMU -----END PGP SIGNATURE----- From dairiki at gmail.com Thu Nov 4 16:54:48 2004 From: dairiki at gmail.com (Jeff Dairiki) Date: Thu Nov 4 16:54:57 2004 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <20041025101540.GA14892@treasure> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041025101540.GA14892@treasure> Message-ID: <4063f01204110407547f396e6d@mail.gmail.com> On Mon, 25 Oct 2004 12:15:41 +0200, Bastian Kleineidam wrote: > On Mon, Oct 25, 2004 at 10:47:41AM +0200, M.-A. Lemburg wrote: > > Do we have Debian folks in the Python-Dev team that could > > review the patch from a Debian point of view ? > I could review it. Is the patch available somewhere? It would be great if you could. The patch set is available from SourceForge's patch tracker for the Python project: http://sourceforge.net/tracker/index.php?func=detail&aid=1054967&group_id=5470&atid=305470 Best Regards, Jeff From mal at egenix.com Fri Nov 5 22:52:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Nov 5 22:52:19 2004 Subject: [Distutils] SourceForge.net: Project Info - Windows Installer XML (WiX) toolset In-Reply-To: <41803288.1040804@activestate.com> References: <417F77B2.1070507@egenix.com> <417FF0EB.4030902@activestate.com> <417FFD08.5050906@egenix.com> <41803288.1040804@activestate.com> Message-ID: <418BF60F.7020106@egenix.com> Trent Mick wrote: > M.-A. Lemburg wrote: > >> Looking more closely at the msi2xml project page it seems >> to do XML -> MSI direction as well. >> >> Trent, do you have experience with one of them ? Which is >> more usable ? > > > WiX was built and is maintained by Microsoft guys (mainly Robert > Menching) and is, they say, heavily used inside Microsoft for putting > there installer packages together. I've played a little bit with WiX and > probably intend to use it for ActivePython (and other installers I > author at work) eventually but haven't started really using it yet. I'm > pretty confident that WiX is a good way to go. I haven't used msi2xml at > all so I can't compare them technically, but the Microsoft usage stories > makes me more confident in WiX. A quick look at the msi2xml XML schema > gives me the impression that msi2xml would feel a lot more raw where as > WiX attempts to put a slight nicer face on the authoring of the database > tables that make up an MSI package -- for better or worse. (ASIDE: MySQL > is now using WiX for their installers.) > > WiX blog: http://blogs.msdn.com/robmen/category/4625.aspx > Rob's personal blog: http://blogs.msdn.com/robmen/ Thanks for the information. Looks like WiX is the way to go then. Any takers ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2004) >>> 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 anthony at interlink.com.au Sat Nov 6 05:35:45 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Sat Nov 6 05:36:44 2004 Subject: [Distutils] SourceForge.net: Project Info - Windows Installer XML (WiX) toolset In-Reply-To: <418BF60F.7020106@egenix.com> References: <417F77B2.1070507@egenix.com> <417FF0EB.4030902@activestate.com> <417FFD08.5050906@egenix.com> <41803288.1040804@activestate.com> <418BF60F.7020106@egenix.com> Message-ID: <418C54A1.3020206@interlink.com.au> M.-A. Lemburg wrote: > Thanks for the information. Looks like WiX is the way to go then. > > Any takers ? This topic's come up a couple of times on python-dev. MvL's said that it's not worth rewriting Python's installer to use this. But it might be useful as a distutils bdist backend, or alternately a distutils backend could be built on top of MvL's msi code. -- Anthony Baxter It's never too late to have a happy childhood. From jafo at tummy.com Tue Nov 9 05:30:19 2004 From: jafo at tummy.com (Sean Reifschneider) Date: Tue Nov 9 05:30:26 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <1098899442.17693.98.camel@hairball.dairiki.org> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> Message-ID: <20041109043019.GF4596@tummy.com> >That seems like a lot of work. Is it really worth it? Probably not. I'll leave that decision up to you, and plan to bug you if the format changes such that having this would have prevented code from breaking. >rfc822.formatdate is broken in my (Debian's) python2.1 and >python2.2 in that it uses strftime (and thus day and month Ok, was just wondering. Less code means less to maintain, but if it doesn't work then use the other implementation. >Using debchange to generate the changelog entry would eliminate >the need for parseaddr and formatdate altogether, so perhaps that >is the best way to go. Comments? That seems like a win. Adding a fake changelog entry is just a few lines of code, right? Stripping it out shouldn't be too bad I would guess, just a few more lines with a regex? Checking for errors in the run a few more? Wouldn't that make it more accurate, allow it to possibly follow changes to the Debian code without modification of the Python code, and get rid of a bunch of other code? >It looks like you don't use sdist to build your source distribution, >since it includes files which aren't in the MANIFEST. That's true. I have my own process for building the source tar which involves CVS, tags, a clean checkout of that tag from the repository, and running a script if present. Since not all my code releases are Python, I'd prefer if I could continue releasing code in that way, but would consider another option if required. >file from the doc subdirectory to MANIFEST to fix this, I think. >A better solution might be to add 'graft doc' to MANIFEST.in. Doing this has resolved that problem. Thanks. Looks like it builds fine. >As far as I can tell, README and README.txt are the only doc-type files >that distutils treats specially. (They automatically get added to the >MANIFEST.) Are there any PEPs or other standards which suggest >other standard names for doc files? In my case, I don't have README in doc, I have documentation for the system in there. README is in the top directory. >After sleeping on it, my current thinking is to drop 'doc' from the >list, and only look for files (not directories). After seeing >jotweb2, I'm think of adding 'LICENSE' and 'LICENCE' to the list. >Comments? That's probably a good idea. Having the license in the package is a good thing. Sean -- I think the net needs some Viagra today. It's just not performing... -- Mike Loseke, 2000 Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin From al.haddix at hp.com Tue Nov 9 07:01:10 2004 From: al.haddix at hp.com (Haddix, Al) Date: Tue Nov 9 07:01:34 2004 Subject: [Distutils] Out of Office AutoReply: Message-ID: <31891B757C09184BBFEC5275F85D55950924C654@cceexc18.americas.cpqcorp.net> I will be out of the office Tuesday, Nov 9. I will not be reading email, but will respond when I return Wed, Nov 10. Al, From dairiki at dairiki.org Tue Nov 9 16:53:26 2004 From: dairiki at dairiki.org (Geoffrey T. Dairiki) Date: Tue Nov 9 16:53:37 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <20041109043019.GF4596@tummy.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <20041026024544.GE17849@dotnetslash.net> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> <20041109043019.GF4596@tummy.com> Message-ID: <1100015606.5628.37.camel@hairball.dairiki.org> On Mon, 2004-11-08 at 20:30, Sean Reifschneider wrote: > >Using debchange to generate the changelog entry would eliminate > >the need for parseaddr and formatdate altogether, so perhaps that > >is the best way to go. Comments? > > That seems like a win. Yup, it's already done, thanks to your initial suggestion. The current set of patches (posted on the patch tracker) uses debchange to generate the debian.changelog. > >It looks like you don't use sdist to build your source distribution, > >since it includes files which aren't in the MANIFEST. > > That's true. I have my own process for building the source tar which > involves CVS, tags, a clean checkout of that tag from the repository, > and running a script if present. Since not all my code releases are > Python, I'd prefer if I could continue releasing code in that way, but > would consider another option if required. I've also modified things so that the dh_make stage looks for doc files to include in the distribution after the sdist building stage. This avoids the error you were experiencing. (But your doc files would still not make it into the Debian package unless you included them in the MANIFEST(.in).) > >As far as I can tell, README and README.txt are the only doc-type files > >that distutils treats specially. (They automatically get added to the > >MANIFEST.) Are there any PEPs or other standards which suggest > >other standard names for doc files? > > In my case, I don't have README in doc, I have documentation for the > system in there. README is in the top directory. Understood. My code (if you don't default the --doc-files option to bdist_deb) uses some (fairly dumb) heuristics to look for files which should be placed in the /usr/share/doc// directory within the Debian binary package. Files in that directory include some Debian-specific files like the debian changelog, but also "should" include things like the python packages README, and probably things like your doc/ subdirectory. I was wondering if there are any Python-specific standards or suggestions which suggested names for these doc-like files. (The GNU coding standards, http://www.gnu.org/prep/standards/, for example specify names for certain files like NEWS, INSTALL, README, COPYING, ChangeLog.) I've looked for an appropriate PEP and not found it. The only evidence of any special filenames I've found is that distutils sdist looks for README and README.txt. Anyhow, thanks again for the comments, Sean. Try out the latest patches when you get a chance. The latest patchset (fresh yesterday) can be found at http://sourceforge.net/tracker/index.php?func=detail&aid=1054967&group_id=5470&atid=305470 Jeff From mal at egenix.com Tue Nov 9 17:03:16 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Nov 9 17:03:19 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <1100015606.5628.37.camel@hairball.dairiki.org> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> <20041109043019.GF4596@tummy.com> <1100015606.5628.37.camel@hairball.dairiki.org> Message-ID: <4190EA44.3060406@egenix.com> Geoffrey T. Dairiki wrote: > I was wondering if there are any Python-specific standards or > suggestions which suggested names for these doc-like files. > (The GNU coding standards, http://www.gnu.org/prep/standards/, > for example specify names for certain files like NEWS, INSTALL, > README, COPYING, ChangeLog.) I've looked for an appropriate PEP > and not found it. The only evidence of any special filenames > I've found is that distutils sdist looks for README and README.txt. As always, I think explicit is better than implicit. The bdist_rpm command uses an option with which you can specify the doc-files (--doc-files). I'd use the same approach for bdist_deb. That way a packager has full control over what is considered a documentation file and what not. I usually place that information into the setup.cfg file, so that the user doesn't have to bother about the setting. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 09 2004) >>> 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 dairiki at gmail.com Tue Nov 9 17:41:42 2004 From: dairiki at gmail.com (Jeff Dairiki) Date: Tue Nov 9 17:41:50 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <4190EA44.3060406@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> <20041109043019.GF4596@tummy.com> <1100015606.5628.37.camel@hairball.dairiki.org> <4190EA44.3060406@egenix.com> Message-ID: <4063f01204110908416e65e758@mail.gmail.com> On Tue, 09 Nov 2004 17:03:16 +0100, M.-A. Lemburg wrote: > As always, I think explicit is better than implicit. > > The bdist_rpm command uses an option with which you can > specify the doc-files (--doc-files). I'd use the same approach for > bdist_deb. > > That way a packager has full control over what is considered > a documentation file and what not. I usually place that information > into the setup.cfg file, so that the user doesn't have to bother > about the setting. My code current does implement a --doc-files option, a la bdist_rpm. There are also several other options which control what goes into /usr/share/doc: --upstream-changelog, --license-file, and --examples. The heuristics are only used if the option is not explicitly set (e.g. if the --doc-files=NEWS option is specified, README will not automatically be included.) My thinking is that it's better to shotgun a few things, like a README and hopefully some licensing information, into the package rather than just leave them out. The reason for the four separate options rather than just --doc-files is that Debian policy want to see those four different classes of files installed in quite specific manners. Given that the heuristics are only used to compute default values, do you still think they are a bad thing? Jeff From mal at egenix.com Wed Nov 10 11:10:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 10 11:10:41 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <4063f01204110908416e65e758@mail.gmail.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041026012304.GA30638@tummy.com> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> <20041109043019.GF4596@tummy.com> <1100015606.5628.37.camel@hairball.dairiki.org> <4190EA44.3060406@egenix.com> <4063f01204110908416e65e758@mail.gmail.com> Message-ID: <4191E91E.1070805@egenix.com> Jeff Dairiki wrote: > On Tue, 09 Nov 2004 17:03:16 +0100, M.-A. Lemburg wrote: > > >>As always, I think explicit is better than implicit. >> >>The bdist_rpm command uses an option with which you can >>specify the doc-files (--doc-files). I'd use the same approach for >>bdist_deb. >> >>That way a packager has full control over what is considered >>a documentation file and what not. I usually place that information >>into the setup.cfg file, so that the user doesn't have to bother >>about the setting. > > > My code current does implement a --doc-files option, a la bdist_rpm. > There are also several other options which control what goes into > /usr/share/doc: > --upstream-changelog, --license-file, and --examples. > The heuristics are only used if the option is not explicitly set (e.g. if > the --doc-files=NEWS option is specified, README will not automatically > be included.) > > My thinking is that it's better to shotgun a few things, like a README > and hopefully some licensing information, into the package rather than > just leave them out. > > The reason for the four separate options rather than just --doc-files is that > Debian policy want to see those four different classes of files installed in > quite specific manners. > > Given that the heuristics are only used to compute default values, do you still > think they are a bad thing? Not at all. I just got the impression that you were guessing a bit much. If it is possible to override these suggestions then that's fine. BTW, why do you need so many different options for specifying doc files ? Is that a Debian thing or requirement ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 10 2004) >>> 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 dairiki at gmail.com Wed Nov 10 15:53:18 2004 From: dairiki at gmail.com (Jeff Dairiki) Date: Wed Nov 10 15:53:22 2004 Subject: [Distutils] Re: bdist_deb patches In-Reply-To: <4191E91E.1070805@egenix.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417DFF12.5020108@egenix.com> <1098838647.17693.25.camel@hairball.dairiki.org> <20041027034852.GD4826@tummy.com> <1098899442.17693.98.camel@hairball.dairiki.org> <20041109043019.GF4596@tummy.com> <1100015606.5628.37.camel@hairball.dairiki.org> <4190EA44.3060406@egenix.com> <4063f01204110908416e65e758@mail.gmail.com> <4191E91E.1070805@egenix.com> Message-ID: <4063f0120411100653449504af@mail.gmail.com> On Wed, 10 Nov 2004 11:10:38 +0100, M.-A. Lemburg wrote: > BTW, why do you need so many different options for specifying > doc files ? Is that a Debian thing or requirement ? Yes, precisely. It's a Debian thang. The upstream changelog needs special treatment since, in the Debian package, it is supposed to be named /usr/share/doc//changelog.gz. (Not ChangeLog, CHANGES, or whatever.) Hence the --upstream-changelog option. The license file needs special treatment because it is supposed to be incorporated into the /usr/share/doc//copyright file. (The copyright file is also supposed to list the upstream author, where the upstream source can be obtained, and who the Debian packager is.) Hence --license-file. Examples are supposed to go in /usr/share/doc//examples/. Hence --examples All other documentation (except man and info pages) just (as you would naively expect) get copied into /usr/share/doc//. That's the --doc-files option. References: http://www.debian.org/doc/debian-policy/ch-docs.html In particular: http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Jeff From robin at jessikat.fsnet.co.uk Mon Nov 15 11:44:32 2004 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Mon Nov 15 11:44:35 2004 Subject: [Distutils] package relative files? Message-ID: <41988890.6020809@chamonix.reportlab.co.uk> Is there a proper way to get files to go along with packages/modules. The directory options seem to imply python executable or distribution relative rather than package relative. -- Robin Becker From andres.baravalle at gmail.com Mon Nov 15 13:54:01 2004 From: andres.baravalle at gmail.com (Andres Baravalle) Date: Mon Nov 15 13:54:03 2004 Subject: [Distutils] Re: confirm c326a187aa6aaad9ba7f65132cb0d5ee4691f7fd In-Reply-To: References: Message-ID: <45992f58041115045456a43c19@mail.gmail.com> Hi, I am quite new with python and I'm developing a package that is including a binary file (eggtrayiconmodule.so) that is open source. My software is developed in part under linux, and now I would like to make it fully portable to other unix-like platforms. Therefore I need to provide the source and integrate eggtrayicon compilation in my setup.py. I have my working Makefile for eggtrayicon and I can compile eggtrayicon, but I would like to compile it automatically with setup.py, if possible, so that the user runs setup.py mysoftware build and it builds. My Makefile is: # Makefile for eggtrayicon OBJECTS = eggtrayiconmodule.so # Compilation stuff CC = gcc PYTHON_VERSION = $(shell echo `python -c "import sys; print sys.version[0:3]"`) PYTHON_INCLUDE = -I/usr/include/python$(PYTHON_VERSION) \ -I/usr/include/pygtk-2.0 \ $(shell pkg-config gtk+-2.0 --cflags) \ $(shell pkg-config libgnomeui-2.0 --cflags) LIBS = $(shell pkg-config gtk+-2.0 --libs) \ $(shell pkg-config libgnomeui-2.0 --libs) CFLAGS = -Wall -g -fomit-frame-pointer $(PYTHON_INCLUDE) all:: $(OBJECTS) %.o : %.c $(CC) -fPIC $(CFLAGS) -c -o $@ $< %.so : %.o $(CC) -shared $(LIBS) -Wl,-soname,$@ $< -o $@ Any suggestions or links to the correct direction to look at? Thanks in advance. Andres From bob at redivi.com Mon Nov 15 15:25:29 2004 From: bob at redivi.com (Bob Ippolito) Date: Mon Nov 15 15:25:49 2004 Subject: [Distutils] package relative files? In-Reply-To: <41988890.6020809@chamonix.reportlab.co.uk> References: <41988890.6020809@chamonix.reportlab.co.uk> Message-ID: <33490094-3712-11D9-9481-000A9567635C@redivi.com> On Nov 15, 2004, at 12:44 PM, Robin Becker wrote: > Is there a proper way to get files to go along with packages/modules. > The directory options seem to imply python executable or distribution > relative rather than package relative. setuptools makes it quite easy to do. -bob From fdrake at acm.org Mon Nov 15 20:54:03 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Nov 15 20:54:37 2004 Subject: [Distutils] package relative files? In-Reply-To: <41988890.6020809@chamonix.reportlab.co.uk> References: <41988890.6020809@chamonix.reportlab.co.uk> Message-ID: <200411151454.03071.fdrake@acm.org> On Monday 15 November 2004 05:44 am, Robin Becker wrote: > Is there a proper way to get files to go along with packages/modules. The > directory options seem to imply python executable or distribution relative > rather than package relative. Bob mentioned setuptools in another response; that's a good source for this functionality. I'd like to add that for Python 2.4, the functionality has been added directly to distutils in a setuptools-compatible way. You'll be able to use the "package_data" metadata with distutils directly. If this is the only setuptools functionality you need, you can easily require setuptools only for older versions of Python: -------------------------------- import sys from distutils.core import setup if sys.version_info < (2, 4): from setuptools import setup -------------------------------- -Fred -- Fred L. Drake, Jr. From jrennie at csail.mit.edu Wed Nov 17 16:40:17 2004 From: jrennie at csail.mit.edu (Jason Rennie) Date: Wed Nov 17 16:40:20 2004 Subject: [Distutils] distutils on afs Message-ID: <20041117154017.GI11627@csail.mit.edu> Hello, Distutils doesn't work with AFS (or, at least, the AFS setup at my lab :). When I try to build a package with the `sdist' command, distutils tries to do a hard link, which fails. There's no code to deal with this problem. Some code reading revealed to me that distutils checks for the existence of os.link to determine whether it should hard link or copy. Including the lines "import os" and "del os.link" in my setup.py script fixes the problem---distutils uses copy. I didn't find any information about this in the documentation. I was hoping that you might add a short discussion of the issue to the documentation so that other poor souls like myself don't have to munge the source to come up with a solution. Thanks, Jason From mukesh_bu at rediffmail.com Thu Nov 18 20:42:47 2004 From: mukesh_bu at rediffmail.com (mukesh_bu@rediffmail.com) Date: Thu Nov 18 20:43:25 2004 Subject: [Distutils] Wait for next reply.... Message-ID: <20041118194247.17189.qmail@webmail13.rediffmail.com> Hi, Thank you for your mail. Will reply as soon as I get back. Regards, Mukesh From mcfletch at rogers.com Sun Nov 21 08:17:58 2004 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Nov 21 08:18:01 2004 Subject: [Distutils] Passing in arguments to Distribution? Message-ID: <41A04126.4010807@rogers.com> I maintain the (rather large) PyOpenGL project, which is basically 4 core modules plus 300+ extension modules. One of the features I'd like to allow for developers is to specify that, for instance, only 1 of the extension modules be rebuilt during a setup pass (particularly during development, it can take 3 or 4 minutes just to run the configs for all the modules, which makes for very slow development). The way the code currently works is that we override the Distribution object's "finalize_options" to search out all of the .i (SWIG) files in the interface sub-directory, creating an Extension object for each one we find. What I'd like to do is to tell the code running in the Distribution to look for a global option (--extensions, for instance) and if it's present, restrict the set of Extensions that's being built to the list in the option. However, I don't see a clean way of passing in arguments to the Distribution object itself. It seems to be responsible for the parsing of the command line, but it assumes that it's trying to parse options for a particular command rather than for the overall process. Any recipes someone cares to share? At the moment I'm thinking I may just parse the options myself using getopt, but that seems like it might cause pain somewhere down the road. I'm going to keep experimenting to see if I can hack something in, but this seems like it would be a common requirement, so I would imagine there's a lever somewhere I can throw... At the moment I'm thinking of moving the module discovery code into the main setup script, but that's still going to require parsing the options myself... and that seems wrong somehow... Where-do-I-stand-and-on-what-do-I-pull-ly yr's, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com From symbiont at berlios.de Sun Nov 21 08:36:35 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Sun Nov 21 08:38:31 2004 Subject: [Distutils] Passing in arguments to Distribution? In-Reply-To: <41A04126.4010807@rogers.com> References: <41A04126.4010807@rogers.com> Message-ID: <200411211536.36004.symbiont@berlios.de> On Sunday 21 November 2004 15:17, Mike C. Fletcher wrote: > Any recipes someone cares to share? ?At the moment I'm thinking I may > just parse the options myself using getopt, but that seems like it > might cause pain somewhere down the road. I'm going to keep > experimenting to see if I can hack something in, but this seems like > it would be a common requirement, so I would imagine there's a lever > somewhere I can throw... 4suite's latest alpha provides an interesting approach--though I won't come right out and vouch for it because I'm trying to spec an RPM but it doesn't have the --record option--where they allow for sub-packages. This allows one to operate on only certain sub-packages for building, installing, etc. Although PackageManager provides for this, it constitutes as a fork of the mainstream distutils and as such there will be differences or even missing features (--record). Anyway, seeing how it operates is beneficial for both discussion and potential py2.5 inclusion... take care, -- -jeff From jeremy.kloth at fourthought.com Sun Nov 21 08:49:16 2004 From: jeremy.kloth at fourthought.com (Jeremy Kloth) Date: Sun Nov 21 08:49:22 2004 Subject: [Distutils] Passing in arguments to Distribution? In-Reply-To: <200411211536.36004.symbiont@berlios.de> References: <41A04126.4010807@rogers.com> <200411211536.36004.symbiont@berlios.de> Message-ID: <200411210049.16797.jeremy.kloth@fourthought.com> On Sunday 21 November 2004 12:36 am, Jeff Pitman wrote: > On Sunday 21 November 2004 15:17, Mike C. Fletcher wrote: > > Any recipes someone cares to share? ?At the moment I'm thinking I may > > just parse the options myself using getopt, but that seems like it > > might cause pain somewhere down the road. I'm going to keep > > experimenting to see if I can hack something in, but this seems like > > it would be a common requirement, so I would imagine there's a lever > > somewhere I can throw... > > 4suite's latest alpha provides an interesting approach--though I won't > come right out and vouch for it because I'm trying to spec an RPM but > it doesn't have the --record option--where they allow for sub-packages. > This allows one to operate on only certain sub-packages for building, > installing, etc. Although PackageManager provides for this, it > constitutes as a fork of the mainstream distutils and as such there > will be differences or even missing features (--record). > > Anyway, seeing how it operates is beneficial for both discussion and > potential py2.5 inclusion... > > take care, I'm curious as to why the --record option is even needed (as I removed it on purpose). 4Suite's bdist_rpm command does all the work for determining which files need to be included. Did you happen to look at the spec file produced by 4Suite? Is it missing something we should be aware of? -- Jeremy Kloth Fourthought, Inc. http://fourthought.com/ http://4suite.org/ From pje at telecommunity.com Sun Nov 21 16:11:34 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Nov 21 16:11:13 2004 Subject: [Distutils] Passing in arguments to Distribution? In-Reply-To: <200411210049.16797.jeremy.kloth@fourthought.com> References: <200411211536.36004.symbiont@berlios.de> <41A04126.4010807@rogers.com> <200411211536.36004.symbiont@berlios.de> Message-ID: <5.1.1.6.0.20041121100847.020ffcd0@mail.telecommunity.com> At 12:49 AM 11/21/04 -0700, Jeremy Kloth wrote: >I'm curious as to why the --record option is even needed (as I removed it on >purpose). Please don't break '--record'. I use it to automatically generate a PLIST file for the NetBSD packaging system. Not everybody uses RPMs, and I wouldn't be surprised if there are other people who use '--record' to interface with other packaging systems. From symbiont at berlios.de Sun Nov 21 16:23:19 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Sun Nov 21 16:25:18 2004 Subject: [Distutils] Passing in arguments to Distribution? In-Reply-To: <200411210049.16797.jeremy.kloth@fourthought.com> References: <41A04126.4010807@rogers.com> <200411211536.36004.symbiont@berlios.de> <200411210049.16797.jeremy.kloth@fourthought.com> Message-ID: <200411212323.20005.symbiont@berlios.de> On Sunday 21 November 2004 15:49, Jeremy Kloth wrote: > Did you happen to look at the spec file produced > by 4Suite? ?Is it missing something we should be aware of? Directories. I'm building a repo of py stuff and just had a spec template. But, when done differently, I have to rely on other methods. Though, I'm more inclined to rely on distutils than rolling my own RPMs. However, directories being left on the disk after uninstall and trying to implement other policies is a bit difficult. -- -jeff From mal at egenix.com Sun Nov 21 19:02:40 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Nov 21 19:02:42 2004 Subject: [Distutils] Passing in arguments to Distribution? In-Reply-To: <5.1.1.6.0.20041121100847.020ffcd0@mail.telecommunity.com> References: <200411211536.36004.symbiont@berlios.de> <41A04126.4010807@rogers.com> <200411211536.36004.symbiont@berlios.de> <5.1.1.6.0.20041121100847.020ffcd0@mail.telecommunity.com> Message-ID: <41A0D840.8050904@egenix.com> Phillip J. Eby wrote: > At 12:49 AM 11/21/04 -0700, Jeremy Kloth wrote: > >> I'm curious as to why the --record option is even needed (as I removed >> it on >> purpose). > > > Please don't break '--record'. I use it to automatically generate a > PLIST file for the NetBSD packaging system. > > Not everybody uses RPMs, and I wouldn't be surprised if there are other > people who use '--record' to interface with other packaging systems. I don't think anyone is considering removing --record from main line distutils. The discussion was about a fork of the distutils package. As for the original question on how to pass in parameters: I don't really understand what Mike is trying to do. Adding new options to Distribution is certainly possible and accessing those new options just as well. It is also possible to pass parameters into its subcommands and having them reinit themselves (e.g. to trim down the list of Extension objects; even though it's easier to do from a build_ext subclass). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 21 2004) >>> 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 hancock at anansispaceworks.com Sun Nov 21 20:33:33 2004 From: hancock at anansispaceworks.com (Terry Hancock) Date: Sun Nov 21 20:26:40 2004 Subject: [Distutils] Integrating w/ distutils, hooks? Message-ID: <200411211333.33722.hancock@anansispaceworks.com> Some time ago, I got the idea that I wanted to build image resources from vector graphic originals, instead of marshalling hundreds of tiny little icon images by hand. I wrote "BuildImage" to do this for me, and so far, it works very well, so I'm trying to make it easier to use and available to more developers. There is a brief (and somewhat dated) tutorial explaining what BuildImage itself does at: http://www.anansispaceworks.com/Documentation/BuildImage """ In as few words as I can put it: "BuildImage is a build system for image resources." That is to say, it attempts to do for image resources what make does for programs. """ So now, I'm looking for the best way to integrate the BuildImage package with distutils to make it the least painful for developers to use in their own distutils' packages. And I really feel this is something I should be talking to distutils-sig about. This is a little long -- but the idea is to spark some discussion about how I ought best to do this: I originally tried making my interface look more like distutils' interface -- providing a "setup" function, etc. I was thinking perhaps I might be able to drop in BuildImage scripts instead of distutils scripts in image resource sub-packages of some kind. But the end-user is unlikely to have BuildImage installed, and I really want 'build' and 'install' targets of the containing distribution to go without a hitch with or without BuildImage (assuming the images are already built, that is), while the developer targets "sdist" and "bdist" should use BuildImage to create image resources and include them in the distribution. Also, I'm probably starting to duplicate distutils functionality, which is wasteful. Perhaps, emulating distutils is somewhat misguided -- I certainly don't want to replace distutils, I just want to work with it in a way that will be intuitive for the developer. What I really want are hooks to attach to within distutils. *Ideally*, BuildImage would run at the time you would normally run Bison/Flex code -- i.e. it actually is a "pre-source" operation: you run it to complete your source distribution, then you compile C/C++ code, THEN you install Python modules, etc. I don't really see that distutils has this concept as yet, but it's probably a reasonable compromise to run it at the same time as C/C++ builds. (?) If that's the right path, then "sdist" should simply include all the necessary files for BuildImage, and the installer will simply need to have BuildImage installed in their Python site-packages in order to build the package. If not, then maybe 'sdist' should build the images, but certainly include all the BuildImage sources so they can be re-built. (?) OTOH, "bdist" should go ahead and build the images, store them in the correct location in the distribution tree, and tell distutils that it should install them along with the sources. (Pretty sure of this) Is it conventional for 'bdist' to *also* include the source files (i.e. in an open-source built distribution)? I'm a little confused about HOW to tell distutils what and where to install: it seems that I might want to use the "data_files" option to setup, or perhaps I want to update the MANIFEST or MANIFEST.in files (can I somehow get my code called after processing MANIFEST.in to MANIFEST so I can then add my additional instructions?). Modifying "MANIFEST.in" seems a little ugly, since the idea is that MANIFEST.in is human-edited source, while "MANIFEST" is machine-generated. But I don't know how I can get my code called to work on MANIFEST *after* it has been generated, but *before* it is used to install files. Currently, I visualize a typical setup.py module using BuildImage as something like this: """ # setup.py using BuildImage import distutils try: # We don't want to fail if BuildImage is not available, # because we are also run by the end user import BuildImage BuildImage.setup( ... options for BuildImage ... ) except: print """ You don't have BuildImage installed, so only distutils operations will be supported. """ distutils.setup( ... options for distutils ... ) """ So, when the end-user runs the setup script, they will see a message warning them that BuildImage targets won't work, but distutils will be able to do its job. OTOH, when the developer runs the script to build the images, that will work too, and BuildImage will do its thing. Obviously, though, BuildImage.setup() has to be able to tell distutils the things it needs to know, such as what to do with the images after they are built (typically they will be in a resource directory under the source tree? But in a distribution that insists on a filesystem standard, like Debian, they should be under /usr/share/images or perhaps /usr/share/pixmaps, etc). Since BuildImage won't be run at 'build' or 'install' time, these things have to already be prepared for distutils' installer. But BuildImage could be made aware of the requirements for 'bdist', 'bdist_rpm', 'bdist_deb', etc., and alter what it tells distutils accordingly. Anyway, thanks for your time -- any recommendations would greatly be appreciated, including references to previous discussion or online resources I should be reading. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com From hancock at anansispaceworks.com Sun Nov 21 23:15:11 2004 From: hancock at anansispaceworks.com (Terry Hancock) Date: Sun Nov 21 23:08:16 2004 Subject: [Distutils] Integrating w/ distutils, hooks? In-Reply-To: <200411211333.33722.hancock@anansispaceworks.com> References: <200411211333.33722.hancock@anansispaceworks.com> Message-ID: <200411211615.11890.hancock@anansispaceworks.com> I neglected to add the link for the most recent BuildImage distribution, which has moved to SourceForge: http://sourceforge.net/projects/narya-project -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com From ruh at ksa-hamm.de Thu Nov 25 08:59:38 2004 From: ruh at ksa-hamm.de (ruh@ksa-hamm.de) Date: Thu Nov 25 08:59:39 2004 Subject: [Distutils] Re: Re: Approved Message-ID: <20041125075938.13533.qmail@server056.de-nserver.de> Our virus scanner has detected that your E-Mail to "ruh@ksa-hamm.de" subject " Re: Approved" was not clean. The following files were infected: all_document.pif: Worm.SomeFool.Gen-1 The Virus Scanner From gpul-traduccion-bounces at ceu.fi.udc.es Tue Nov 30 16:08:20 2004 From: gpul-traduccion-bounces at ceu.fi.udc.es (gpul-traduccion-bounces@ceu.fi.udc.es) Date: Tue Nov 30 16:08:31 2004 Subject: [Distutils] Your message to gpul-traduccion awaits moderator approval Message-ID: Your mail to 'gpul-traduccion' with the subject Mail Delivery (failure gpul-traduccion@ceu.fi.udc.es) Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam (score 3.5) Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://ceu.fi.udc.es/cgi-bin/mailman/confirm/gpul-traduccion/b0d6cb39a12032208b5054b4ba310fa10638b6d3