Revision \d+:'. This breaks for Sourceforge subversion repositories, which include the project name before the "Revision" text (see http://cctools.svn.sourceforge.net/svnroot/cctools/vendorlibs/utidylib/ for an arbitrary example). ---------- messages: 64 nosy: nyergler priority: bug status: unread title: SVN detection for package indices breaks on Sourceforge.net _______________________________________________ Setuptools tracker <setuptools at bugs.python.org> <http://bugs.python.org/setuptools/issue29> _______________________________________________ From d.w.morriss at gmail.com Tue Jul 29 05:14:23 2008 From: d.w.morriss at gmail.com (whit morriss) Date: Mon, 28 Jul 2008 22:14:23 -0500 Subject: [Distutils] [issue29] SVN detection for package indices breaks on Sourceforge.net In-Reply-To: <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> References: <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> Message-ID: <g6m1uf$4hb$1@ger.gmane.org> Nathan R. Yergler wrote: > New submission from Nathan R. Yergler <nathan at yergler.net>: > > PackageIndex._download_html (setuptools/package_index.py) attempts to detect if > an HTML page is a Subversion repository using the regular expression > r'<title>Revision \d+:'. This breaks for Sourceforge subversion repositories, > which include the project name before the "Revision" text (see > http://cctools.svn.sourceforge.net/svnroot/cctools/vendorlibs/utidylib/ for an > arbitrary example). > > ---------- > messages: 64 > nosy: nyergler > priority: bug > status: unread > title: SVN detection for package indices breaks on Sourceforge.net > > _______________________________________________ > Setuptools tracker <setuptools at bugs.python.org> > <http://bugs.python.org/setuptools/issue29> > _______________________________________________ > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > looks like sf upgraded to svn 1.5? this issue actually breaks setuptools for anyone using the default xslt template for svn 1.5 (though that template is inadequate for fixing it) r'<title>\s*[a-zA-Z]+\s*\-?\s*Revision \d+:' will match both old and new: <title>almanac - Revision 1179: / <title>Revision 19507: / seems like there ought to be a better way to do this than sniffing title tags though... especially since svn offers easy ways to break this via the svnindex.xsl template. -w From cz at gocept.com Tue Jul 29 08:38:16 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Tue, 29 Jul 2008 08:38:16 +0200 Subject: [Distutils] A release to at least stop crashing on Subversion 1.5 would be nice References: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local> <4888C2EF.1030707@cryptelium.net> Message-ID: <g6mdso$u09$1@ger.gmane.org> On 2008-07-24 19:59:11 +0200, kiorky <kiorky at cryptelium.net> said: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > Arlo Belshee a =E9crit : >> In command/sdist.py, line 90 refers to a global log function which does= > not exist. Thus, instead of logging a warning about not understanding Su= > bversion, setuptools crashes. >> =20 >> The default setup scripts for Pylons (and probably others) use svn revi= > sion tagging. Thus, the following causes a crash: >> =20 >> easy_install Pylons >> paster create -t Pylons proj >> setup.py develop >> =20 >> And, since the user hasn't done any config (or anything but follow a tu= > torial), he isn't able to easily figure out what went wrong. Also, since = > setuptools was likely installed automatically for him via the egg in the = > cheeseshop, he isn't aware of anything that may be in dev for setuptools.= > A new user's likely response is to get frustrated for 15 minutes, then m= > ove on to another web framework / language. >> =20 >> Even if you don't provide svn 1.5 support, can you at least post an egg= > that won't crash in the presence of svn 1.5? >> =20 >> Thanks. >> =20 >> Arlo >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG at python.org >> http://mail.python.org/mailman/listinfo/distutils-sig > > You can easy_install -U "setuptools =3D=3D dev" > It is fixed on trunk as far as i know. That does not really help with an empty python. I'm not going to install anything with easy_install to have no sideeffects when using buildout. -- Christian Zagrodnick ? cz at gocept.com gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany http://gocept.com ? tel +49 345 1229889 4 ? fax +49 345 1229889 1 Zope and Plone consulting and development From d.w.morriss at gmail.com Tue Jul 29 16:39:56 2008 From: d.w.morriss at gmail.com (whit morriss) Date: Tue, 29 Jul 2008 09:39:56 -0500 Subject: [Distutils] upgrading buildout In-Reply-To: <g6kpdm$4pe$1@ger.gmane.org> References: <g6kpdm$4pe$1@ger.gmane.org> Message-ID: <g6na3t$rkl$1@ger.gmane.org> whit morriss wrote: > I'm perhaps running buildout in a bit of unusual fashion (from my > virtual env bin rather than the builds bin) and updated it recently from > 1.0.2 to 1.1.0 to debug some issue folks were having with fresh > checkouts of one of my builds (see previous message). as a caveat for others, we also noticed a number of older recipes which are cached don't take the new allowed hosts arg. It looks like older copies (in this case zc.recipe.egg) got installed in the virtualenv sitepackages (probably for the purposes of investigation) or egg caches and did not get updated. In systems like buildout where every buildout is necessarily a patch work of called dependencies (most frameworks or component systems are like this in one way or another, sometimes referred as what separates frameworks from libs), it would be useful to have some mechanism for propagate an update of a downstream component. Does setuptool support anything like this (I'm doubting it?)? could or does zc.buildout? for builds, I could see this being handled more as a migration. Update the framework library, run a migration to upgrade all the component libraries, rebuild. -w From jim at zope.com Tue Jul 29 17:30:00 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 29 Jul 2008 11:30:00 -0400 Subject: [Distutils] upgrading buildout In-Reply-To: <g6na3t$rkl$1@ger.gmane.org> References: <g6kpdm$4pe$1@ger.gmane.org> <g6na3t$rkl$1@ger.gmane.org> Message-ID: <FC78285A-EFEC-4799-A6FD-3258FAC795F9@zope.com> On Jul 29, 2008, at 10:39 AM, whit morriss wrote: > whit morriss wrote: >> I'm perhaps running buildout in a bit of unusual fashion (from my >> virtual env bin rather than the builds bin) and updated it recently >> from 1.0.2 to 1.1.0 to debug some issue folks were having with >> fresh checkouts of one of my builds (see previous message). > > as a caveat for others, we also noticed a number of older recipes > which are cached don't take the new allowed hosts arg. It looks > like older copies (in this case zc.recipe.egg) got installed in the > virtualenv sitepackages (probably for the purposes of investigation) > or egg caches and did not get updated. This sounds like a bug. I expect buildout to get and use the newest distributions that satisfy its requirements regardless of whether older versions are in site-packages. One way that this would fail is if eggs are installed into site-packages as develop eggs, aka "single- version-externally-managed". buildout gives preference to develop eggs even if there are newer non-develop eggs. Distributions installed using -single-version-externally-managed are tagged by setuptools as develop eggs. I really wish setuptools made a distinction between single-version-externally-managed and develop eggs. Was the zc.recipe.egg distribution installed into your site- packages using -single-version-externally-managed? (This will be the case if the egg contents are stored directly in site-packages rather than having egg files or directories.) > In systems like buildout where every buildout is necessarily a patch > work of called dependencies (most frameworks or component systems > are like this in one way or another, sometimes referred as what > separates frameworks from libs), it would be useful to have some > mechanism for propagate an update of a downstream component. By "downstream", do you mean a dependency? > Does setuptool support anything like this (I'm doubting it?)? > could or does zc.buildout? > > for builds, I could see this being handled more as a migration. > Update the framework library, run a migration to upgrade all the > component libraries, rebuild. As a general rule, buildout always tries to find the latest versions of all distributions used, including dependencies. One exception to this is that it prefers develop eggs. Jim -- Jim Fulton Zope Corporation From dpeterson at enthought.com Thu Jul 31 02:05:37 2008 From: dpeterson at enthought.com (Dave Peterson) Date: Wed, 30 Jul 2008 19:05:37 -0500 Subject: [Distutils] Bug in setuptools version parsing when appending '.dev'? Message-ID: <489101D1.3030903@enthought.com> Am I missing something or is the following a bug whereby adding the '.dev' tag is doing something weird? >>> from pkg_resources import parse_requirement as pv >>> pv('1.0a1.dev') < pv('1.0a1') True >>> pv('1.0a1') < pv('1.0') True >>> pv('1.0a1.dev') < pv('1.0.dev') False >>> pv('1.0a1') < pv('1.0.dev') False >>> import setuptools >>> setuptools.__version__ '0.6c8' This is mainly causing us problems when projects try to track alpha and beta level bumps in dependencies, such as when project Foo requires project Bar version 3.0b1 via a requirement like 'Bar >= 3.0b1' (which means we don't want the development prereleases of Bar's first beta release, but anything after that should be okay.) But then when we actually want to release Bar 3.0 and change the version number to just '3.0', suddenly installs fail while we try to run the last set of tests because '3.0.dev' is older than '3.0b1'. If it is not a bug, how do you handle situations where you want to run that last round of testing prior to tagging and building releases? I'd rather do that AFTER making all source changes, and not have to change the version number after the testing. -- Dave From lumir.jasiok at vsb.cz Thu Jul 31 11:46:59 2008 From: lumir.jasiok at vsb.cz (=?ISO-8859-1?Q?Lum=EDr_Jasiok?=) Date: Thu, 31 Jul 2008 11:46:59 +0200 Subject: [Distutils] How to create deb package Message-ID: <48918A13.1000903@vsb.cz> Hi, I need to create .deb package from source package. I am using distutils. Is there some working bdist_deb extension? What is best practices at this case? Any useful comments will be appreciate. Best Regards Lumir -- Lum?r Jasiok VSB-TU Ostrava - Computer centre Tel: +420 59 732 3189 E-mail: lumir.jasiok at vsb.cz http://www.vsb.cz

From setuptools at bugs.python.org Wed Jul 2 14:17:02 2008 From: setuptools at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Wed, 02 Jul 2008 12:17:02 +0000 Subject: [Distutils] [issue26] Subversion 1.5 and tag_svn_revision do work together In-Reply-To: <1215001022.44.0.473905574671.issue26@psf.upfronthosting.co.za> Message-ID: <1215001022.44.0.473905574671.issue26@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven : When using tag_svn_revision = true in setup.cfg with Subversion 1.5 the resulting revision number is 0. Example: creating /usr/local/lib/python2.5/site-packages/Trac-0.12dev_r0-py2.5.egg ---------- messages: 54 nosy: asmodai priority: bug status: unread title: Subversion 1.5 and tag_svn_revision do work together _______________________________________________ Setuptools tracker _______________________________________________ From zooko at zooko.com Wed Jul 2 17:40:06 2008 From: zooko at zooko.com (zooko) Date: Wed, 2 Jul 2008 09:40:06 -0600 Subject: [Distutils] the future of setuptools development In-Reply-To: <94bdd2610806291401l489a9b2fqce7e95e87e36af59@mail.gmail.com> References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com> <4863E51D.4010708@mail.utexas.edu> <94bdd2610806291401l489a9b2fqce7e95e87e36af59@mail.gmail.com> Message-ID: Dear PJE: Thank you so much for inventing setuptools and for bringing it to its current level of maturity. It seems that you don't have time right now to be the sole maintainer of setuptools. Opening up a codebase to commits from multiple people is always risky, but once a project is big and successful enough, multiple maintainers are often needed to make sufficiently fast progress. Fortuately, there is a good way to ameliorate the risks and to help multiple programmers coordinate with one another: unit tests. Also fortunately, Tarek Ziad? and Chris Galvan have spent some time recently writing tests for setuptools. Please give those two folks commit privileges to the setuptools SVN repository so that they will be maximally empowered and encouraged to continue that work! We -- the community of people who care enough about setuptools to spend time improving it -- will make an effort to maintain setuptools's high level of quality, both by automated testing, by code review, and by manual testing in real-world deployments. Thanks, Your user, Zooko From lists at informa.tiker.net Wed Jul 2 20:59:25 2008 From: lists at informa.tiker.net (Andreas =?utf-8?q?Kl=C3=B6ckner?=) Date: Wed, 2 Jul 2008 14:59:25 -0400 Subject: [Distutils] Correct way to allow C extension building to fail? Message-ID: <200807021459.26667.lists@informa.tiker.net> Hi there, I'm working on a Python module (simplejson) that comes with a C extension that can optionally speed up some of its operations. It is however ok for this extension to fail to build, in which case the module will use Python fallbacks. How can I allow for this failure? Bob Ippolito, the original author, has this implemented as follows: 8< ------------------------------------------------------ class ve_build_ext(build_ext): # This class allows C extension building to fail. def run(self): try: build_ext.run(self) except DistutilsPlatformError, x: self._unavailable(x) def build_extension(self, ext): try: build_ext.build_extension(self, ext) except (CCompilerError, DistutilsExecError), x: self._unavailable(x) def _unavailable(self, exc): print '*'*70 print BUILD_EXT_WARNING print exc print '*'*70 ... setup(cmdclass={'build_ext': ve_build_ext},) 8< ------------------------------------------------------ On current setuptools, this fails with ** error: Setup script exited with error: can't copy 'simplejson.egg-info\native_libs.txt': doesn't exist or not a regular file How can I fix this? Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From strawman at astraw.com Wed Jul 2 21:54:53 2008 From: strawman at astraw.com (Andrew Straw) Date: Wed, 02 Jul 2008 12:54:53 -0700 Subject: [Distutils] Correct way to allow C extension building to fail? In-Reply-To: <200807021459.26667.lists@informa.tiker.net> References: <200807021459.26667.lists@informa.tiker.net> Message-ID: <486BDD0D.3050401@astraw.com> I'm not sure if this will work, but it might: class NotPlatformDependentDistribution(Distribution): # Force platform-independent build. def has_ext_modules(self): return False setup( distclass = NotPlatformDependentDistribution, ) Andreas Kl?ckner wrote: > Hi there, > > I'm working on a Python module (simplejson) that comes with a C extension that > can optionally speed up some of its operations. It is however ok for this > extension to fail to build, in which case the module will use Python > fallbacks. > > How can I allow for this failure? Bob Ippolito, the original author, has this > implemented as follows: > > 8< ------------------------------------------------------ > class ve_build_ext(build_ext): > # This class allows C extension building to fail. > > def run(self): > try: > build_ext.run(self) > except DistutilsPlatformError, x: > self._unavailable(x) > > def build_extension(self, ext): > try: > build_ext.build_extension(self, ext) > except (CCompilerError, DistutilsExecError), x: > self._unavailable(x) > > def _unavailable(self, exc): > print '*'*70 > print BUILD_EXT_WARNING > print exc > print '*'*70 > > ... > > setup(cmdclass={'build_ext': ve_build_ext},) > 8< ------------------------------------------------------ > > On current setuptools, this fails with > > ** error: Setup script exited with error: can't > copy 'simplejson.egg-info\native_libs.txt': doesn't exist or not a regular > file > > How can I fix this? > > Andreas > > > ------------------------------------------------------------------------ > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig From lists at informa.tiker.net Wed Jul 2 23:01:51 2008 From: lists at informa.tiker.net (Andreas =?iso-8859-1?q?Kl=F6ckner?=) Date: Wed, 2 Jul 2008 17:01:51 -0400 Subject: [Distutils] Correct way to allow C extension building to fail? In-Reply-To: <486BDD0D.3050401@astraw.com> References: <200807021459.26667.lists@informa.tiker.net> <486BDD0D.3050401@astraw.com> Message-ID: <200807021701.52976.lists@informa.tiker.net> Hi Andrew, On Mittwoch 02 Juli 2008, Andrew Straw wrote: > I'm not sure if this will work, but it might: > > class NotPlatformDependentDistribution(Distribution): > # Force platform-independent build. > def has_ext_modules(self): > return False > > setup( > distclass = NotPlatformDependentDistribution, > ) First of all, thanks for your help. However, when I try your solution, it seems to disable the C extension outright, which is not what I'm going for. Instead, I would like setuptools to try the build and simply forget about it if it fails. Can that be done somehow? Thanks, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From strawman at astraw.com Thu Jul 3 00:07:00 2008 From: strawman at astraw.com (Andrew Straw) Date: Wed, 02 Jul 2008 15:07:00 -0700 Subject: [Distutils] Correct way to allow C extension building to fail? In-Reply-To: <200807021701.52976.lists@informa.tiker.net> References: <200807021459.26667.lists@informa.tiker.net> <486BDD0D.3050401@astraw.com> <200807021701.52976.lists@informa.tiker.net> Message-ID: <486BFC04.5030401@astraw.com> Sorry, I was thinking to switch the return value of the distclass's has_ext_modules() method based on whether building the extension failed (not in all cases). Sorry for not being more clear. Anyhow, it's just an idea -- I have no idea when setuptools queries this method relative to when compiling the modules actually take place. If switching after the build failed isn't possible, I wonder if you could semi-reliably predict whether the build would fail (compiler detection?) and then switch the distclass based on that? I realize that idea is sub-optimal... Maybe what you want to do is too magic anyway -- perhaps the users should just attempt to install the version with extension code and if that fails to install the version with no extension code? Or maybe the extension code is a 2nd package that the main package works around if it cannot be imported? -Andrew Andreas Kl?ckner wrote: > Hi Andrew, > > On Mittwoch 02 Juli 2008, Andrew Straw wrote: > >> I'm not sure if this will work, but it might: >> >> class NotPlatformDependentDistribution(Distribution): >> # Force platform-independent build. >> def has_ext_modules(self): >> return False >> >> setup( >> distclass = NotPlatformDependentDistribution, >> ) >> > > First of all, thanks for your help. However, when I try your solution, it > seems to disable the C extension outright, which is not what I'm going for. > Instead, I would like setuptools to try the build and simply forget about it > if it fails. > > Can that be done somehow? > > Thanks, > Andreas > > ------------------------------------------------------------------------ > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > From lists at informa.tiker.net Thu Jul 3 00:14:01 2008 From: lists at informa.tiker.net (Andreas =?iso-8859-1?q?Kl=F6ckner?=) Date: Wed, 2 Jul 2008 18:14:01 -0400 Subject: [Distutils] Correct way to allow C extension building to fail? In-Reply-To: References: <200807021459.26667.lists@informa.tiker.net> <200807021701.52976.lists@informa.tiker.net> Message-ID: <200807021814.04336.lists@informa.tiker.net> On Mittwoch 02 Juli 2008, you wrote: > on failure have it raise any kind of exception (custom or otherwise) > and wrap the creation of the module in a try/except block. if it > fails, proceed on the alternate branch of execution This seems to do what I want. Thanks! Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From lists at informa.tiker.net Thu Jul 3 02:31:54 2008 From: lists at informa.tiker.net (Andreas =?iso-8859-1?q?Kl=F6ckner?=) Date: Wed, 2 Jul 2008 20:31:54 -0400 Subject: [Distutils] Optimization of C++ extensions to Python In-Reply-To: References: Message-ID: <200807022031.55616.lists@informa.tiker.net> Hi Michael, On Montag 30 Juni 2008, Michael Wieher wrote: > Can anyone > a) tell me if my binary compiled w/extra_compile_args -O0 is, indeed, level > zero b) tell me the correct way to adjust this flag? Not sure about "correct", but this works for me: 8< --------------------------------------------------------- def hack_distutils(debug=False, fast_link=True): # hack distutils.sysconfig to eliminate debug flags # stolen from mpi4py def remove_prefixes(optlist, bad_prefixes): for bad_prefix in bad_prefixes: for i, flag in enumerate(optlist): if flag.startswith(bad_prefix): optlist.pop(i) break return optlist import sys if not sys.platform.lower().startswith("win"): from distutils import sysconfig cvars = sysconfig.get_config_vars() cflags = cvars.get('OPT') if cflags: cflags = remove_prefixes(cflags.split(), ['-g', '-O', '-Wstrict-prototypes', '-DNDEBUG']) if debug: cflags.append("-g") else: cflags.append("-O3") cflags.append("-DNDEBUG") cvars['OPT'] = str.join(' ', cflags) cvars["CFLAGS"] = cvars["BASECFLAGS"] + " " + cvars["OPT"] if fast_link: for varname in ["LDSHARED", "BLDSHARED"]: ldsharedflags = cvars.get(varname) if ldsharedflags: ldsharedflags = remove_prefixes(ldsharedflags.split(), ['-Wl,-O']) cvars[varname] = str.join(' ', ldsharedflags) 8< --------------------------------------------------------- Distutils may just be the most-monkeypatched piece of software in history. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From uschmitt at mineway.de Fri Jul 4 09:56:13 2008 From: uschmitt at mineway.de (Uwe Schmitt) Date: Fri, 04 Jul 2008 09:56:13 +0200 Subject: [Distutils] ctypes based modules Message-ID: <486DD79D.9070700@mineway.de> Hi, how do you distribute ctypes based modules on a linux machine ? What does your setup.py look like ? I have to copy my shared library to /usr/lib or another common place, but I would prefer .../site-packages/... In the latter case I think I have to modify LD_LIBRARY_PATH oder some ld.so.conf configuration file. So, what is the prefered method for this task ? Greetings, Uwe -- Dr. rer. nat. Uwe Schmitt F&E Mathematik mineway GmbH Science Park 2 D-66123 Saarbr?cken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt at mineway.de www.mineway.de Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbr?cken HRB 12339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From milinda.pathirage at gmail.com Fri Jul 4 10:45:16 2008 From: milinda.pathirage at gmail.com (Milinda Pathirage) Date: Fri, 4 Jul 2008 14:15:16 +0530 Subject: [Distutils] Running 'ldconfig' after install command Message-ID: <22a059a60807040145i19e89d09k9fc71abd61d5ec5b@mail.gmail.com> Hi all, I'am developing a extension for Python using C library. I have correctly follow the steps described in docs and now the setup is working fine. But the problem is we have some libraries deployed in a custom location other than /usr/lib or any other default location. So at the installation time I am copying a configuration file containing library location to /etc/ld.so.conf.d. But after copying this I have to run ldconfig to make system pickup the libraries. Can any one please suggest a method that I can run ldconfig when the instllation is finished (As the last step of installation run the ldconfig.). Thanks in advance Milinda -- http://mpathirage.com http://wso2.org "Oxygen for Web Service Developers" http://wsaxc.blogspot.com "Web Services With Axis2/C" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaraco at jaraco.com Sat Jul 5 23:26:16 2008 From: jaraco at jaraco.com (Jason R. Coombs) Date: Sat, 5 Jul 2008 15:26:16 -0600 Subject: [Distutils] Subversion 1.5 entries not parsed successfully Message-ID: <750B64C66078B34D918257A1AC004DB20308A9@messiah.jaraco.com> Subversion 1.5 is released and official now. Any chance we can get the patch suggested at http://mail.python.org/pipermail/python-bugs-list/2008-May/051721.html or any other fix applied to the 0.6 branch of setuptools? I acknowledge this fix may not fit into the grand scheme of the development, but it seems to me to be a straightforward and logical fix to address what will be an increasingly prominent problem. Sincerely, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7001 bytes Desc: not available URL: From flormayer at aim.com Wed Jul 9 18:33:18 2008 From: flormayer at aim.com (Florian Mayer) Date: Wed, 09 Jul 2008 18:33:18 +0200 Subject: [Distutils] Setuptools documentation Message-ID: <4874E84E.1090303@aim.com> Hello! I have read the setuptools documentation and have tried out the parse_version comparison, and it turns out that the documentation says is just wrong. I am using version 0.6c8 of setuptools. The documentation says, quoting: "Don't use - or any other character than . as a separator, unless you really want a post-release. Remember that 2.1-rc2 means you've already released 2.1, whereas 2.1rc2 and 2.1.c2 are candidates you're putting out before 2.1". It also shows a little example for that: >>> parse_version('2.1-rc2') < parse_version('2.1') False While this sounds pretty weird(how can a rc be after the release?) but also logical if you just consider any character but "." to be post-release, which you can do, but do not have to. Still if they say this is the rule it is okay, although I would not quite agree with that, as many people use underscores or dashes as a separation. So what the real problem is, is that the documentation says things that are untrue with at least the latest version. As said before I have setuptools 0.6c8 and the behaviour is not like the documentation says in any way. Here is a little example: >>> parse_version("2.1-rc2") < parse_version("2.1") True Notice the difference? It's exactly the *opposite* of what the documentation says. I really ask you to correct this issue as it might confuse new users. The documentation I mean can be found at http://peak.telecommunity.com/DevCenter/setuptools, if it is not done by you or you cannot edit it, I apologise and will send another email to its maintainer, but as I could not find out who maintains this site, I just assumed that you, as the maintainer of setuptools are maintaining the documentation. Thanks in advance for your time reading this and correcting the documentation. Best regards, Florian Mayer From pje at telecommunity.com Wed Jul 9 18:50:26 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 09 Jul 2008 12:50:26 -0400 Subject: [Distutils] Setuptools documentation In-Reply-To: <4874E84E.1090303@aim.com> References: <4874E84E.1090303@aim.com> Message-ID: <20080709164944.1E54A3A403A@sparrow.telecommunity.com> At 06:33 PM 7/9/2008 +0200, Florian Mayer wrote: >Hello! >I have read the setuptools documentation and have tried out the >parse_version comparison, and it turns out that the documentation says >is just wrong. I am using version 0.6c8 of setuptools. > >The documentation says, quoting: >"Don't use - or any other character than . as a separator, unless you >really want a post-release. Remember that 2.1-rc2 means you've already >released 2.1, whereas 2.1rc2 and 2.1.c2 are candidates you're putting >out before 2.1". >It also shows a little example for that: > >>> parse_version('2.1-rc2') < parse_version('2.1') >False > >While this sounds pretty weird(how can a rc be after the release?) but >also logical if you just consider any character but "." to be >post-release, which you can do, but do not have to. >Still if they say this is the rule it is okay, although I would not >quite agree with that, as many people use underscores or dashes as a >separation. > >So what the real problem is, is that the documentation says things that >are untrue with at least the latest version. As said before I have >setuptools 0.6c8 and the behaviour is not like the documentation says in >any way. Here is a little example: > >>> parse_version("2.1-rc2") < parse_version("2.1") >True > >Notice the difference? It's exactly the *opposite* of what the >documentation says. I really ask you to correct this issue as it might >confuse new users. The code is apparently correct here; the choice of example in the text is bad. Patches welcome. From asmodai at in-nomine.org Wed Jul 9 18:56:44 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Wed, 9 Jul 2008 18:56:44 +0200 Subject: [Distutils] Setuptools documentation In-Reply-To: <20080709164944.1E54A3A403A@sparrow.telecommunity.com> References: <4874E84E.1090303@aim.com> <20080709164944.1E54A3A403A@sparrow.telecommunity.com> Message-ID: <20080709165644.GF68329@nexus.in-nomine.org> -On [20080709 18:52], Phillip J. Eby (pje at telecommunity.com) wrote: >The code is apparently correct here; the choice of example in the >text is bad. Patches welcome. Not meant disrespectful Phillip, but who will apply the patches? It has been obvious that you have had very little time lately and there's already a few patches in the issue tracker waiting for some TLC. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Dreams are like Angels, they keep bad at bay, bad at bay, Love is the Light, scaring Darkness away... From pje at telecommunity.com Wed Jul 9 20:06:33 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 09 Jul 2008 14:06:33 -0400 Subject: [Distutils] Setuptools documentation In-Reply-To: <20080709165644.GF68329@nexus.in-nomine.org> References: <4874E84E.1090303@aim.com> <20080709164944.1E54A3A403A@sparrow.telecommunity.com> <20080709165644.GF68329@nexus.in-nomine.org> Message-ID: <20080709180551.5FFAD3A403A@sparrow.telecommunity.com> At 06:56 PM 7/9/2008 +0200, Jeroen Ruigrok van der Werven wrote: >-On [20080709 18:52], Phillip J. Eby (pje at telecommunity.com) wrote: > >The code is apparently correct here; the choice of example in the > >text is bad. Patches welcome. > >Not meant disrespectful Phillip, but who will apply the patches? It has been >obvious that you have had very little time lately and there's already a few >patches in the issue tracker waiting for some TLC. "lately" != "never again" My time at OSAF will probably end in November, and my book project (@ thinkingthingsdone.com) will end sooner than that. Doesn't mean I might not still be pretty busy, but I won't be two jobs worth of busy forever. From pje at telecommunity.com Wed Jul 9 20:24:13 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 09 Jul 2008 14:24:13 -0400 Subject: [Distutils] Setuptools documentation In-Reply-To: <4874F535.5020901@aim.com> References: <4874E84E.1090303@aim.com> <20080709164944.1E54A3A403A@sparrow.telecommunity.com> <4874F535.5020901@aim.com> Message-ID: <20080709182335.0899E3A403A@sparrow.telecommunity.com> At 07:28 PM 7/9/2008 +0200, Florian Mayer wrote: >Phillip J. Eby wrote: > > > > The code is apparently correct here; the choice of example in the text > > is bad. Patches welcome. > > > >I do not seem to quite understand the answer. Which code is correct? parse_version() is correct: "-" should be dropped when it precedes a prerelease tag. Apparently I changed it as a bugfix, but didn't update the docs: http://svn.python.org/view?rev=41630&view=rev From pje at telecommunity.com Wed Jul 9 20:34:51 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 09 Jul 2008 14:34:51 -0400 Subject: [Distutils] Setuptools documentation In-Reply-To: <20080709181834.GG68329@nexus.in-nomine.org> <7.1.0.9.0.20080709140728.05d6f198@telecommunity.com> References: <4874E84E.1090303@aim.com> <20080709164944.1E54A3A403A@sparrow.telecommunity.com> <20080709165644.GF68329@nexus.in-nomine.org> <20080709180551.5FFAD3A403A@sparrow.telecommunity.com> <20080709181834.GG68329@nexus.in-nomine.org> <4874E84E.1090303@aim.com> <20080709164944.1E54A3A403A@sparrow.telecommunity.com> <4874F535.5020901@aim.com> <7.1.0.9.0.20080709140728.05d6f198@telecommunity.com> Message-ID: <20080709183413.132843A404D@sparrow.telecommunity.com> At 08:18 PM 7/9/2008 +0200, Jeroen Ruigrok van der Werven wrote: >-On [20080709 20:06], Phillip J. Eby (pje at telecommunity.com) wrote: > >"lately" != "never again" > >I understand that. >And I can also understand you might not no anyone yet you feel comfortable >with sharing commit access with someone else. 2 things: 1. I don't even have time to review people's work in order to become comfortable, and 2. I don't control commit access to setuptools, anyway... it's Python's SVN, not mine. From ziade.tarek at gmail.com Thu Jul 10 15:15:10 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 10 Jul 2008 15:15:10 +0200 Subject: [Distutils] Setuptools documentation In-Reply-To: <20080709180551.5FFAD3A403A@sparrow.telecommunity.com> References: <4874E84E.1090303@aim.com> <20080709164944.1E54A3A403A@sparrow.telecommunity.com> <20080709165644.GF68329@nexus.in-nomine.org> <20080709180551.5FFAD3A403A@sparrow.telecommunity.com> Message-ID: <94bdd2610807100615v4ca64fcft72f5e595a9b22713@mail.gmail.com> On Wed, Jul 9, 2008 at 8:06 PM, Phillip J. Eby wrote: > At 06:56 PM 7/9/2008 +0200, Jeroen Ruigrok van der Werven wrote: > >> -On [20080709 18:52], Phillip J. Eby (pje at telecommunity.com) wrote: >> >The code is apparently correct here; the choice of example in the >> >text is bad. Patches welcome. >> >> Not meant disrespectful Phillip, but who will apply the patches? It has >> been >> obvious that you have had very little time lately and there's already a >> few >> patches in the issue tracker waiting for some TLC. >> > > "lately" != "never again" > > My time at OSAF will probably end in November, and my book project (@ > thinkingthingsdone.com) will end sooner than that. > > Doesn't mean I might not still be pretty busy, but I won't be two jobs > worth of busy forever. > You asked for some tests some time ago to reduce the amount of work for you to review other people patches, we did a sprint on the topic, and we were ready to continue this work, but were waiting for feedback. I think a quick look on our brz branch would take less than 10 mn, http://bazaar.launchpad.net/~setuptools/setuptools-test/main/files (all text files in setuptools/tests) Just to say if it is the right direction. That would motivate us to continue our work until you can dedicate some time on setuptools project again. Regards, Tarek -------------- next part -------------- An HTML attachment was scrubbed... URL: From runyaga at runyaga.com Mon Jul 14 19:11:53 2008 From: runyaga at runyaga.com (Alan Runyan) Date: Mon, 14 Jul 2008 12:11:53 -0500 Subject: [Distutils] Where is setuptools 0.6c9? Message-ID: Just ran across the NameError that was fixed in revision 60846. Looks like setup.py was bumped to 0.6c9 in revision 60848. Was 0.6c9 intended to be released? I heard a rumor of released software "gone missing" from pypi. Curious to the status. cheers alan From pje at telecommunity.com Mon Jul 14 21:50:55 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 14 Jul 2008 15:50:55 -0400 Subject: [Distutils] Where is setuptools 0.6c9? In-Reply-To: References: Message-ID: <20080714195011.D65983A407B@sparrow.telecommunity.com> At 12:11 PM 7/14/2008 -0500, Alan Runyan wrote: >Just ran across the NameError that was fixed in revision 60846. >Looks like setup.py was bumped to 0.6c9 in revision 60848. That's standard procedure in order to avoid revision numbers going backwards: as soon as I make an official release, I bump the version so that all subsequent builds or checkouts are a .dev version of the *next* release. >Was 0.6c9 intended to be released? It has not been, no. If it were, the version in SVN would be 0.6c10. When 0.6final is released, the SVN version will jump to 0.6.1, and so on. From runyaga at runyaga.com Mon Jul 14 23:49:12 2008 From: runyaga at runyaga.com (Alan Runyan) Date: Mon, 14 Jul 2008 16:49:12 -0500 Subject: [Distutils] Where is setuptools 0.6c9? In-Reply-To: <20080714195011.D65983A407B@sparrow.telecommunity.com> References: <20080714195011.D65983A407B@sparrow.telecommunity.com> Message-ID: Is there any ETA on the next release of 0.6? On Mon, Jul 14, 2008 at 2:50 PM, Phillip J. Eby wrote: > At 12:11 PM 7/14/2008 -0500, Alan Runyan wrote: >> >> Just ran across the NameError that was fixed in revision 60846. >> Looks like setup.py was bumped to 0.6c9 in revision 60848. > > That's standard procedure in order to avoid revision numbers going > backwards: as soon as I make an official release, I bump the version so that > all subsequent builds or checkouts are a .dev version of the *next* release. > > >> Was 0.6c9 intended to be released? > > It has not been, no. If it were, the version in SVN would be 0.6c10. When > 0.6final is released, the SVN version will jump to 0.6.1, and so on. > > -- Alan Runyan Enfold Systems, Inc. http://www.enfoldsystems.com/ phone: +1.713.942.2377x111 fax: +1.832.201.8856 From chris at simplistix.co.uk Tue Jul 15 21:09:55 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 20:09:55 +0100 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear Message-ID: <487CF603.7060402@simplistix.co.uk> Hi All, This section of the docs at http://pypi.python.org/pypi/zc.buildout/1.0.6 doesn't seem to make much sense. extension1.cfg and extension2.cfg are set up but no examples use them as far as I can see. The demo also uses extending of configurations as well as buildout extensions before these have been introduced as concepts. I'm *guessing* that: >>> write(sample_buildout, 'base.cfg', ... """ ... [buildout] ... parts = part2 ... ... [part2] ... recipe = ... option = b1 b2 b3 b4 ... """) >>> write(sample_buildout, 'extension1.cfg', ... """ ... [buildout] ... extends = base.cfg ... ... [part2] ... option -= b1 b2 ... """) ..will result in 'option' being 'b3 b4' when extension1.cfg is used, but there's no explanation of how this works. Are option values always split on spaces or is there another set of rules for this? Where is this documented? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Tue Jul 15 21:28:35 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 20:28:35 +0100 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: References: <487CF603.7060402@simplistix.co.uk> Message-ID: <487CFA63.9020803@simplistix.co.uk> Jim Fulton wrote: > > Could you be more specific? What section of the documentation are you in? I can try, but I was about as specific as I could be first time round... http://pypi.python.org/pypi/zc.buildout/1.0.6 The sections titled "adding and removing options". cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Tue Jul 15 21:39:58 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 20:39:58 +0100 Subject: [Distutils] [zc.buildout] general doc sprawl Message-ID: <487CFD0E.7000701@simplistix.co.uk> Hi All, If you go to http://pypi.python.org/pypi/zc.buildout/1.0.6 the resulting page is *huge* :-( There doesn't appear to be any real structure to it and it reads as if it's been added to by various different authors over time. It also seems to be a good example of "doctests gone wrong" where the doc has become less important than the test. Of particular difficulty is that sections often seem to refer to concepts that are only introduced further down in the document. As someone trying to learn buildout in depth, what I'd most like is: - a short tutorial introduction (this bit is there, I think..) - a list/reference of the options passable when running buildout (I think this appears about 30% of the way through that doc, but I'm not sure all the options are covered) - a list/reference of the "commands" buildout has. I counted "install" and "init" and maybe "bootstrap" too, but I don't know if that's all and I'm still hazy about what the differences are between each one. - a list/reference of the options names that have meaning in the [buildout] section to buildout itself. There seem to be a *lot* of these and they're scattered throughout the document at that URL. I have a horrible sinking feeling that I'm going to spend most of my life with buildout trying to find the right option name to use :-/ - now, and now only, docs on how to write recipes and then on to the more esoteric stuff, although I suspect the references above would likely cover a lot of it. It'd also be great it it wasn't just one monolithic file, but I guess that's just my reading preference :-S I'm afraid I'm unable to offer resources to try and fix this problem but I do feel it should be highlighted as it makes buildout, which now that I'm finally getting over the documentation barrier, seems to actually be a very sturdy and useful tool (and gets over some of the setuptools, egg and pypi suck), exponentially less easy to play with for newbies. Oh, and a parting shot: it would be great to get some idea of the "known good" recipe types to use too. I see the plone guys have vomited several million recipe eggs into pypi and, to be blunt, it's impossible to figure out which were written by muppets and which by people with functioning brains. Someone mentioned a cmmi recipe at EPC. That sounded interesting but now I don't know where to find it... drowning-ly yours, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 15 21:40:45 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 15:40:45 -0400 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <487CF603.7060402@simplistix.co.uk> References: <487CF603.7060402@simplistix.co.uk> Message-ID: <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> On Jul 15, 2008, at 3:09 PM, Chris Withers wrote: > Hi All, > > This section of the docs at http://pypi.python.org/pypi/zc.buildout/1.0.6 > doesn't seem to make much sense. You are referring to: http://pypi.python.org/pypi/zc.buildout/1.0.6#adding-and-removing-options > extension1.cfg and extension2.cfg are set up but no examples use > them as far as I can see. The last example extends extensions2.cfg, which extends extensions1.cfg. > The demo also uses extending of configurations as well as buildout > extensions before these have been introduced as concepts. Yup. That's annoying. This section should be moved until after extending has been described and should use an extension. Probably just invoking the buildout with -vv should be enough. I'm hoping the person who wrote this section is paying attention so I don't have to fix this myself. :) > > > I'm *guessing* that: > > >>> write(sample_buildout, 'base.cfg', > ... """ > ... [buildout] > ... parts = part2 > ... > ... [part2] > ... recipe = > ... option = b1 b2 b3 b4 > ... """) > > >>> write(sample_buildout, 'extension1.cfg', > ... """ > ... [buildout] > ... extends = base.cfg > ... > ... [part2] > ... option -= b1 b2 > ... """) > > ..will result in 'option' being 'b3 b4' Right. > when extension1.cfg is used, but there's no explanation of how this > works. Are option values always split on spaces Yes > or is there another set of rules for this? No. > Where is this documented? That section tries to explain it. The parsing rule should have been stated. The example should be made simpler. The extension business complicates it excessively. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Tue Jul 15 21:47:16 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 20:47:16 +0100 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> References: <487CF603.7060402@simplistix.co.uk> <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> Message-ID: <487CFEC4.40202@simplistix.co.uk> Jim Fulton wrote: > > You are referring to: > http://pypi.python.org/pypi/zc.buildout/1.0.6#adding-and-removing-options Yup. >> extension1.cfg and extension2.cfg are set up but no examples use them >> as far as I can see. > > The last example extends extensions2.cfg, which extends extensions1.cfg. Oh, right, 4th time of reading I see that... :-S >> The demo also uses extending of configurations as well as buildout >> extensions before these have been introduced as concepts. > > Yup. That's annoying. This section should be moved until after extending > has been described and should use an extension. I'm guessing you mean "shouldn't use an extension"? Extensions look like something I don't ever want to have to use ;-) >> when extension1.cfg is used, but there's no explanation of how this >> works. Are option values always split on spaces > > Yes Okay, I don't know if there's a "this is how sections, names and values" work section but if there isn't, there should be, and if there is, I missed it and I don't remember reading anything about how and where values are split ;-) (ie: does a recipe get the values pre-split or does it need to split itself and therefore is it just convention that prevents a recipe from splitting on other characters too?) >> Where is this documented? > > That section tries to explain it. The parsing rule should have been > stated. The example should be made simpler. The extension business > complicates it excessively. Yup. Maybe just a simple bit on "this is how sections, names and values work" would do it? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Tue Jul 15 21:55:45 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 20:55:45 +0100 Subject: [Distutils] [setuptools] how are entry points consumed Message-ID: <487D00C1.5090808@simplistix.co.uk> Hi all, Been reading: http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins This seems to sort of cover eggs that provide entry points but doesn't cover at all how they're consumed. So, taking the blogtool.parsers example, what python code would blogtool actually use to get hold of all the different parsers? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 15 21:55:48 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 15:55:48 -0400 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <487CFEC4.40202@simplistix.co.uk> References: <487CF603.7060402@simplistix.co.uk> <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> <487CFEC4.40202@simplistix.co.uk> Message-ID: <4DC42384-6833-4375-918F-0D04F7B62A45@zope.com> On Jul 15, 2008, at 3:47 PM, Chris Withers wrote: ... >>> The demo also uses extending of configurations as well as buildout >>> extensions before these have been introduced as concepts. >> Yup. That's annoying. This section should be moved until after >> extending has been described and should use an extension. > > I'm guessing you mean "shouldn't use an extension"? Extensions look > like something I don't ever want to have to use ;-) Right. They are a rather advanced feature. We use them to support sftp urls. >>> when extension1.cfg is used, but there's no explanation of how >>> this works. Are option values always split on spaces >> Yes > > Okay, I don't know if there's a "this is how sections, names and > values" work section but if there isn't, there should be, and if > there is, I missed it http://pypi.python.org/pypi/zc.buildout/1.0.6#configuration-file-syntax > and I don't remember reading anything about how and where values are > split ;-) Parsing of option values is specific to individual recipes, so it isn't part of the general syntax. Having said that, many many options are treated as white-space delimited sequences of values. The += and - = syntax is only useful for options that have this form. The documentation should have said more about this. > (ie: does a recipe get the values pre-split no > or does it need to split itself yes > and therefore is it just convention that prevents a recipe from > splitting on other characters too?) Yes. In fact, if values can have spaces in them, then a option may be split on new lines. For example the eggs option in many recipes, which should really be named "requirements", is split on new lines because the individual values can have spaces in them. Jim -- Jim Fulton Zope Corporation From jim at zope.com Tue Jul 15 21:26:39 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 15:26:39 -0400 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <487CF603.7060402@simplistix.co.uk> References: <487CF603.7060402@simplistix.co.uk> Message-ID: On Jul 15, 2008, at 3:09 PM, Chris Withers wrote: > Hi All, > > This section of the docs at http://pypi.python.org/pypi/zc.buildout/1.0.6 > doesn't seem to make much sense. > > extension1.cfg and extension2.cfg are set up but no examples use > them as far as I can see. > > The demo also uses extending of configurations as well as buildout > extensions before these have been introduced as concepts. Could you be more specific? What section of the documentation are you in? Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Tue Jul 15 22:03:31 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 21:03:31 +0100 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <4DC42384-6833-4375-918F-0D04F7B62A45@zope.com> References: <487CF603.7060402@simplistix.co.uk> <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> <487CFEC4.40202@simplistix.co.uk> <4DC42384-6833-4375-918F-0D04F7B62A45@zope.com> Message-ID: <487D0293.6020705@simplistix.co.uk> Jim Fulton wrote: > >> Okay, I don't know if there's a "this is how sections, names and >> values" work section but if there isn't, there should be, and if there >> is, I missed it > > http://pypi.python.org/pypi/zc.buildout/1.0.6#configuration-file-syntax Okay, but that doesn't mention splitting on spaces ;-) It's also below stuff dealing with writing recipe clases, etc, which seems weird as understanding the format of the .cfg file seems pretty integral to using buildout from the get-go :-S >> and I don't remember reading anything about how and where values are >> split ;-) > > Parsing of option values is specific to individual recipes, so it isn't > part of the general syntax. Having said that, many many options are > treated as white-space delimited sequences of values. The += and -= > syntax is only useful for options that have this form. The > documentation should have said more about this. ...and I'm still left baffled. so: - the parsing of the value is soley up to the recipe - but += -= are "buildout" things that can be applied to all values, no matter their recipe - and many many options, but not all, are treated as whitespace delimited sequences of values um... :'( (I don't know the emoticon for an exploding head) >> and therefore is it just convention that prevents a recipe from >> splitting on other characters too?) > > Yes. In fact, if values can have spaces in them, then a option may be > split on new lines. For example the eggs option in many recipes, which > should really be named "requirements", is split on new lines because the > individual values can have spaces in them. So what happens if I use += or -= with the eggs option? (and I've wanted to do just this in the past, but didn't even know I could...) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Tue Jul 15 22:08:28 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 21:08:28 +0100 Subject: [Distutils] [zc.buildout] confusion from "work on a package" section Message-ID: <487D03BC.30101@simplistix.co.uk> Reading: http://pypi.python.org/pypi/zc.buildout/1.0.6#work-on-a-package ...again. Can someone walk me through like the idiot I feel right now why having "develop = ." results in src/zc/ngi/ ending up on the python path? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From marius at pov.lt Tue Jul 15 22:11:39 2008 From: marius at pov.lt (Marius Gedminas) Date: Tue, 15 Jul 2008 23:11:39 +0300 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <487CFA63.9020803@simplistix.co.uk> References: <487CF603.7060402@simplistix.co.uk> <487CFA63.9020803@simplistix.co.uk> Message-ID: <20080715201139.GA11032@fridge.pov.lt> On Tue, Jul 15, 2008 at 08:28:35PM +0100, Chris Withers wrote: > Jim Fulton wrote: > >Could you be more specific? What section of the documentation are you in? > > I can try, but I was about as specific as I could be first time round... Never assume people read the Subject line. Marius Gedminas -- The memory management on the PowerPC can be used to frighten small children. -- Linus Torvalds -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jim at zope.com Tue Jul 15 22:13:17 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 16:13:17 -0400 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: <487D0293.6020705@simplistix.co.uk> References: <487CF603.7060402@simplistix.co.uk> <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> <487CFEC4.40202@simplistix.co.uk> <4DC42384-6833-4375-918F-0D04F7B62A45@zope.com> <487D0293.6020705@simplistix.co.uk> Message-ID: On Jul 15, 2008, at 4:03 PM, Chris Withers wrote: ... >>> and therefore is it just convention that prevents a recipe from >>> splitting on other characters too?) >> Yes. In fact, if values can have spaces in them, then a option may >> be split on new lines. For example the eggs option in many >> recipes, which should really be named "requirements", is split on >> new lines because the individual values can have spaces in them. > > So what happens if I use += or -= with the eggs option? > (and I've wanted to do just this in the past, but didn't even know I > could...) You'll get garbage. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Tue Jul 15 22:14:46 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 21:14:46 +0100 Subject: [Distutils] [zc.buildout] "Adding and removing options" section unclear In-Reply-To: References: <487CF603.7060402@simplistix.co.uk> <16C4E9E5-44C2-4623-AC93-F94DECA6F9AE@zope.com> <487CFEC4.40202@simplistix.co.uk> <4DC42384-6833-4375-918F-0D04F7B62A45@zope.com> <487D0293.6020705@simplistix.co.uk> Message-ID: <487D0536.4000806@simplistix.co.uk> Jim Fulton wrote: > >> So what happens if I use += or -= with the eggs option? >> (and I've wanted to do just this in the past, but didn't even know I >> could...) > > You'll get garbage. Always nice knowing a tool is point the gun firmly at your feet for you ;-) Shame, being able ot do += -= and have the recipe interpret what that meant would be cool... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 15 22:19:39 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 16:19:39 -0400 Subject: [Distutils] [zc.buildout] confusion from "work on a package" section In-Reply-To: <487D03BC.30101@simplistix.co.uk> References: <487D03BC.30101@simplistix.co.uk> Message-ID: <171D1B54-FD34-4EFB-AFC2-246A53C1D25A@zope.com> On Jul 15, 2008, at 4:08 PM, Chris Withers wrote: > Reading: > > http://pypi.python.org/pypi/zc.buildout/1.0.6#work-on-a-package > > ...again. > > Can someone walk me through like the idiot I feel right now why > having "develop = ." results in src/zc/ngi/ ending up on the python > path? It doesn't. It results, in the case of zc.ngi, in src being on the Python path. The develop option takes one or more paths, separated by spaces. :) Each path should point to a setup script or to a directory containing one. Each setup script is run in "develop" mode creating a "develop" egg which is just a file containing the path to a project's sourc directory. This directory is added to the path. Note that the project's source directory is controlled by the setup script. It need not be a src subdirectory of a project. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Tue Jul 15 22:25:07 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 21:25:07 +0100 Subject: [Distutils] [zc.buildout] confusion from "work on a package" section In-Reply-To: <171D1B54-FD34-4EFB-AFC2-246A53C1D25A@zope.com> References: <487D03BC.30101@simplistix.co.uk> <171D1B54-FD34-4EFB-AFC2-246A53C1D25A@zope.com> Message-ID: <487D07A3.6040101@simplistix.co.uk> Jim Fulton wrote: > > On Jul 15, 2008, at 4:08 PM, Chris Withers wrote: > >> Reading: >> >> http://pypi.python.org/pypi/zc.buildout/1.0.6#work-on-a-package >> >> ...again. >> >> Can someone walk me through like the idiot I feel right now why having >> "develop = ." results in src/zc/ngi/ ending up on the python path? > > It doesn't. It results, in the case of zc.ngi, in src being on the > Python path. Okay, but how? I don't see any mention of 'src' in any of the config... > The develop option takes one or more paths, separated by spaces. :) > > Each path should point to a setup script or to a directory containing > one. Each setup script is run in "develop" mode What does this mean? > creating a "develop" > egg which is just a file containing the path to a project's sourc > directory. This directory is added to the path. Note that the project's > source directory is controlled by the setup script. It need not be a src > subdirectory of a project. Ah, okay, hmmm, to be honest using an example that's not in the docs makes this less clear than it should be. It's only now that I read http://svn.zope.org/zc.ngi/trunk/setup.py?rev=76019&view=auto that I see the 'src'... Thanks for replying though, I feel like the fog is giving a good 3 feet of visibility now ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 15 22:29:24 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 16:29:24 -0400 Subject: [Distutils] [zc.buildout] confusion from "work on a package" section In-Reply-To: <487D07A3.6040101@simplistix.co.uk> References: <487D03BC.30101@simplistix.co.uk> <171D1B54-FD34-4EFB-AFC2-246A53C1D25A@zope.com> <487D07A3.6040101@simplistix.co.uk> Message-ID: <78BE7E5D-5CCE-49FF-9D2C-55EE49F4BBA1@zope.com> On Jul 15, 2008, at 4:25 PM, Chris Withers wrote: ... >> The develop option takes one or more paths, separated by spaces. :) >> Each path should point to a setup script or to a directory >> containing one. Each setup script is run in "develop" mode > > What does this mean? http://peak.telecommunity.com/DevCenter/setuptools#develop-deploy-the-project-source-in-development-mode Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Tue Jul 15 22:31:44 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 21:31:44 +0100 Subject: [Distutils] [zc.buildout] repeatable buildouts Message-ID: <487D0930.90103@simplistix.co.uk> wow, I'm on a roll tonight ;-) So: http://pypi.python.org/pypi/zc.buildout/1.0.6#repeatable-buildouts-controlling-eggs-used I just don't really follow this... Is the 'versions' name in the [buildout] section meaningful to buildout? what are the keys in a version section? just egg versions or something else? fwiw, most of the time I seem to use an egg recipe or something similar to lock specific egg versions. Having the release number in the section name seems odd, I'd expect something more like [buildout] versions = versions [versions] spam = 1 eggs = 2.2 ...and then just keep the versions stuff correct on different svn branches/tags of the buildout. What am I missing? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 15 23:23:13 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 15 Jul 2008 17:23:13 -0400 Subject: [Distutils] [zc.buildout] repeatable buildouts In-Reply-To: <487D0930.90103@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> Message-ID: On Jul 15, 2008, at 4:31 PM, Chris Withers wrote: > wow, I'm on a roll tonight ;-) > > So: > > http://pypi.python.org/pypi/zc.buildout/1.0.6#repeatable-buildouts-controlling-eggs-used > > I just don't really follow this... > > Is the 'versions' name in the [buildout] section meaningful to > buildout? The versions option in the buildout section specifies the name of a section containing version information. > what are the keys in a version section? just egg versions or > something else? project names > fwiw, most of the time I seem to use an egg recipe or something > similar to lock specific egg versions. Having the release number in > the section name seems odd, That was just an example. buildout doesn't care what the section name is. > I'd expect something more like > > [buildout] > versions = versions > > [versions] > spam = 1 > eggs = 2.2 > That is a common pattern. > ...and then just keep the versions stuff correct on different svn > branches/tags of the buildout. > > What am I missing? Nothing really. The example assumed you might want to keep multiple sets of versions in the same buildout. That isn't a pattern that has caught on though. Jim -- Jim Fulton Zope Corporation From lgautier at gmail.com Wed Jul 16 00:12:28 2008 From: lgautier at gmail.com (Laurent Gautier) Date: Wed, 16 Jul 2008 00:12:28 +0200 Subject: [Distutils] autotools-like AC_COMPILE_IFELSE Message-ID: <27d1e6020807151512o64a1f366n53fddc1b7ae332ed@mail.gmail.com> Hi, I would like to know if it is possible to emulate some features of the GNU build tools with distutils (or related python module). In particular, I have a C-written Python module and I would like to try compiling very short (few lines) C programs in order to check that third-party C libraries the python module links to has given features. I suspect that I am not the first to ask, but I could not find much information about that topic on the net. Any help/pointer would be appreciated, L. From chris at simplistix.co.uk Wed Jul 16 00:24:57 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 23:24:57 +0100 Subject: [Distutils] [zc.buildout] repeatable buildouts In-Reply-To: References: <487D0930.90103@simplistix.co.uk> Message-ID: <487D23B9.80607@simplistix.co.uk> Jim Fulton wrote: > >> Is the 'versions' name in the [buildout] section meaningful to buildout? > > The versions option in the buildout section specifies the name of a > section containing version information. OK. >> what are the keys in a version section? just egg versions or something >> else? > > project names Not sure what a "project name" is in buildout parlance. As best I can tell, it seems to be a recipe name used in a part. What's the different between: [buildout] parts = foo versions = versions [versions] spam = 1 [foo] recipe = spam ...and: [buildout] parts = foo [foo] recipe = spam == 1 cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Wed Jul 16 00:56:18 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 15 Jul 2008 23:56:18 +0100 Subject: [Distutils] [zc.buildout] another way of specifying egg versions? Message-ID: <487D2B12.80003@simplistix.co.uk> Just reading this: http://pypi.python.org/pypi/zc.buildout/1.0.6#automatic-buildout-updates Is this pattern: [buildout] zc.buildout-version == 1.0.6 setuptools-version == 0.6 ...only applicable to buildout and setuptools or does it generalize to: [buildout] -version ? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From tseaver at palladion.com Wed Jul 16 01:12:51 2008 From: tseaver at palladion.com (Tres Seaver) Date: Tue, 15 Jul 2008 19:12:51 -0400 Subject: [Distutils] [zc.buildout] repeatable buildouts In-Reply-To: <487D23B9.80607@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> Message-ID: <487D2EF3.2030007@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote: > Jim Fulton wrote: >>> Is the 'versions' name in the [buildout] section meaningful to buildout? >> The versions option in the buildout section specifies the name of a >> section containing version information. > > OK. > >>> what are the keys in a version section? just egg versions or something >>> else? >> project names > > Not sure what a "project name" is in buildout parlance. It is distutils speak: distributions are "releases" of projects. The project name oftent, but not always, corresponds to the name of the Python package which makes up the project's guts. 'setup.py' is what defines a project, actually, and the 'name' argument passed to the 'setup()' command is the project name. I'll stay mute on the parts bit, as I understand it less than you do. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfS7z+gerLs4ltQ4RAoyqAKCjVoKkaZ+QF2IKS+eiAP+dA7PV4gCePiM/ ugNVRS7J2rlzYkcjYvzZp4Q= =2lnf -----END PGP SIGNATURE----- From chris at simplistix.co.uk Wed Jul 16 01:33:53 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 00:33:53 +0100 Subject: [Distutils] [zc.buildout] bootstrap.py Message-ID: <487D33E1.4010909@simplistix.co.uk> Hi All, From what I can see, bootstrap.py is there if you don't want either setuptools or zc.buildout to end up in your site-packages. Am I right? If so, where is it's use documented and what's the "correct" way to get hold of bootstrap.py? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Wed Jul 16 01:44:47 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 00:44:47 +0100 Subject: [Distutils] [zc.buildout] another way of specifying egg versions? In-Reply-To: <487D2B12.80003@simplistix.co.uk> References: <487D2B12.80003@simplistix.co.uk> Message-ID: <487D366F.5010606@simplistix.co.uk> Chris Withers wrote: > [buildout] > zc.buildout-version == 1.0.6 > setuptools-version == 0.6 > > ...only applicable to buildout and setuptools or does it generalize to: Okay, correct me if I'm wrong, but the answer is that the above are special magic keys that only apply to buildout and setuptools. Worse still, to get the intention of the above, you actually have to spell it like: setuptools-version = == 0.6c8 zc.buildout-version = == 1.0.6 :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Wed Jul 16 01:48:37 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 00:48:37 +0100 Subject: [Distutils] weird setuptools error... Message-ID: <487D3755.3070206@simplistix.co.uk> This is while using buildout, but the weirdness is definitely setuptools... The buildout.cfg: [buildout] parts = eggs setuptools-version = == 0.6c8 zc.buildout-version = == 1.0.6 [eggs] recipe = zc.recipe.egg eggs = BeautifulSoup The output: >bin\buildout.exe Getting distribution for 'zc.recipe.egg'. Got zc.recipe.egg 1.1.0b1. Installing eggs. Getting distribution for 'BeautifulSoup'. zip_safe flag not set; analyzing archive contents... eggs\setuptools-0.6c8-py2.5.egg\setuptools\command\bdist_egg. py:422: UnicodeWarning: Unicode equal comparison failed to convert both argument s to Unicode - interpreting them as being unequal symbols = dict.fromkeys(iter_symbols(code)) Installing BeautifulSoup 3.0.7a Caused installation of a distribution: beautifulsoup 3.0.7a with a different project name. Got beautifulsoup 3.0.7a. What's that unicode warning all about? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Wed Jul 16 02:03:58 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 01:03:58 +0100 Subject: [Distutils] [zc.recipe.egg] why would eggs get updated when not specified? Message-ID: <487D3AEE.60808@simplistix.co.uk> Reading this: http://pypi.python.org/pypi/zc.recipe.egg#egg-updating So, the eggs options is removed from the recipe. Why then would the demo egg be updated towards the end of the section? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From setuptools at bugs.python.org Wed Jul 16 02:33:40 2008 From: setuptools at bugs.python.org (Philip Jenvey) Date: Wed, 16 Jul 2008 00:33:40 +0000 Subject: [Distutils] [issue27] [PATCH] Fix shebang lines for Jython on POSIX In-Reply-To: <1216168420.02.0.0968245543998.issue27@psf.upfronthosting.co.za> Message-ID: <1216168420.02.0.0968245543998.issue27@psf.upfronthosting.co.za> New submission from Philip Jenvey : Jython's sys.executable is a shell script on POSIX (and .bat on Windows) and thus can't be used as a shebang line interpreter. The following patch works around this by calling sys.executable via /usr/bin/env in shebang lines on platforms where sys.platform.startswith('java') and sys.executable's MAGIC is '#!'. Jython on Windows is a separate issue -- Jython probably has to ship a .exe to solve the problem there. This fix doesn't apply to Windows because sys.executable's MAGIC is not '#!' there. Marking as a higher priority because installed scripts on Jython aren't executable without this fix Original distutils-sig discussion: http://www.nabble.com/Shebang-lines-on- Jython-td16730414.html ---------- files: jython-shebang-fix_r61342.diff messages: 60 nosy: pjenvey priority: critical status: unread title: [PATCH] Fix shebang lines for Jython on POSIX Added file: http://bugs.python.org/setuptools/file10/jython-shebang-fix_r61342.diff _______________________________________________ Setuptools tracker _______________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jython-shebang-fix_r61342.diff URL: From lists at zopyx.com Wed Jul 16 14:09:25 2008 From: lists at zopyx.com (Andreas Jung) Date: Wed, 16 Jul 2008 14:09:25 +0200 Subject: [Distutils] [zc.buildout/egg-cache] .pyc files referencing temporary location? Message-ID: We have some reports from co-workers working with zc.buildout and an egg-cache where the .pyc files refer to temporary directories within the egg-cache (obviously the location where the files within the egg were unpacked and compiled) - something like that. P:\home\freyp\.buildout\eggs\tmp27l-TE\Products.LDAPUserFolder-2.5-py2.4.egg\Products\LDAPUserFolder\LDAPUserFolder.py" Is there some solution other than removing the .pyc files? The issue seems to be related to debugging Zope environments with WingIDE. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jim at zope.com Wed Jul 16 15:38:59 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 09:38:59 -0400 Subject: [Distutils] [zc.buildout] repeatable buildouts In-Reply-To: <487D23B9.80607@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> Message-ID: On Jul 15, 2008, at 6:24 PM, Chris Withers wrote: > Jim Fulton wrote: >>> Is the 'versions' name in the [buildout] section meaningful to >>> buildout? >> The versions option in the buildout section specifies the name of a >> section containing version information. > > OK. > >>> what are the keys in a version section? just egg versions or >>> something else? >> project names > > Not sure what a "project name" is in buildout parlance. See Tres' explanation. > > As best I can tell, it seems to be a recipe name used in a part. No. > What's the different between: > > [buildout] > parts = foo > versions = versions > > [versions] > spam = 1 > > [foo] > recipe = spam > > ...and: > > [buildout] > parts = foo > > [foo] > recipe = spam == 1 There is no effective difference between these two examples. Often a buildout refers to the same project more than once. Using versions affects all uses. Using versions also applies to dependencies. Jim -- Jim Fulton Zope Corporation From jim at zope.com Wed Jul 16 15:40:15 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 09:40:15 -0400 Subject: [Distutils] [zc.buildout] another way of specifying egg versions? In-Reply-To: <487D2B12.80003@simplistix.co.uk> References: <487D2B12.80003@simplistix.co.uk> Message-ID: <53FBCD89-636D-4017-80D1-F89CC07E5D67@zope.com> On Jul 15, 2008, at 6:56 PM, Chris Withers wrote: > Just reading this: > > http://pypi.python.org/pypi/zc.buildout/1.0.6#automatic-buildout-updates > > Is this pattern: > > [buildout] > zc.buildout-version == 1.0.6 > setuptools-version == 0.6 > > ...only applicable to buildout and setuptools or does it generalize > to: > > [buildout] > -version > > ? No. Note that the options predated the versions feature, which accomplishes the same thing. These 2 options should probably be deprecated. Jim -- Jim Fulton Zope Corporation From jim at zope.com Wed Jul 16 15:48:32 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 09:48:32 -0400 Subject: [Distutils] [zc.buildout] bootstrap.py In-Reply-To: <487D33E1.4010909@simplistix.co.uk> References: <487D33E1.4010909@simplistix.co.uk> Message-ID: On Jul 15, 2008, at 7:33 PM, Chris Withers wrote: > Hi All, > > From what I can see, bootstrap.py is there if you don't want either > setuptools or zc.buildout to end up in your site-packages. > > Am I right? Yes. > If so, where is it's use documented This is a hole in the documentation. It is documented briefly in the "work on a package" section. > and what's the "correct" way to get hold of bootstrap.py? Many projects include it. I get it using svn: svn cat svn://svn.zope.org/repos/main/zc.buildout/trunk/bootstrap/ bootstrap.py > bootstrap.py Jim -- Jim Fulton Zope Corporation From jim at zope.com Wed Jul 16 15:54:27 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 09:54:27 -0400 Subject: [Distutils] [zc.recipe.egg] why would eggs get updated when not specified? In-Reply-To: <487D3AEE.60808@simplistix.co.uk> References: <487D3AEE.60808@simplistix.co.uk> Message-ID: <20008D33-5710-48D9-A366-5D2E657E9776@zope.com> On Jul 15, 2008, at 8:03 PM, Chris Withers wrote: > Reading this: > > http://pypi.python.org/pypi/zc.recipe.egg#egg-updating > > So, the eggs options is removed from the recipe. from the part section. Note that this isn't important and illustrates the rather dumb feature that if you omit the eggs option, the part name is used as the value of the eggs section. This feature should be deprecated. > Why then would the demo egg be updated towards the end of the section? This has nothing to dowith whether the eggs option was used. The egg is updated at the end because we ran buildout in the default mode which looks for newest versions of distributions. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Wed Jul 16 15:58:12 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 14:58:12 +0100 Subject: [Distutils] [zc.recipe.egg] why would eggs get updated when not specified? In-Reply-To: <20008D33-5710-48D9-A366-5D2E657E9776@zope.com> References: <487D3AEE.60808@simplistix.co.uk> <20008D33-5710-48D9-A366-5D2E657E9776@zope.com> Message-ID: <487DFE74.9000407@simplistix.co.uk> Jim Fulton wrote: > >> Why then would the demo egg be updated towards the end of the section? > > This has nothing to dowith whether the eggs option was used. The egg is > updated at the end because we ran buildout in the default mode which > looks for newest versions of distributions. So even if an egg/distribution/whatever isn't used anywhere in the buildout.cfg, it'll still get updated? Where does buildout look to decide what gets updated? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Wed Jul 16 16:03:53 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 10:03:53 -0400 Subject: [Distutils] [zc.buildout/egg-cache] .pyc files referencing temporary location? In-Reply-To: References: Message-ID: <7C77D03B-73D5-4500-A3E7-39DFC77941F5@zope.com> On Jul 16, 2008, at 8:09 AM, Andreas Jung wrote: > We have some reports from co-workers working with zc.buildout and an > egg-cache where the .pyc files refer to temporary directories within > the egg-cache (obviously the location where the files within the egg > were unpacked and compiled) - something like that. > > P:\home\freyp\.buildout\eggs\tmp27l-TE\Products.LDAPUserFolder-2.5- > py2.4.egg\Products\LDAPUserFolder\LDAPUserFolder.py" > > Is there some solution other than removing the .pyc files? Not currently. > The issue seems > to be related to debugging Zope environments with WingIDE. No, this is either a buildout, or possibly setuptools, issue having to do with the way eggs get built. There would be a similar issue with downloaded eggs. I plan to fix this at some point. Note: - This is important when using any debugger, since debuggers need to be able to get at source files. It would be nice if debuggers were clever enough to get run-time file locations based on __file__, rather than relying on file information stored in pyc files. - This only matters if you use unzipped eggs. (I have no idea why people use zipped eggs, since they are slower to import and generally a pain. I plan to add a buildout option to unzip all eggs.) Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Wed Jul 16 16:07:27 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 15:07:27 +0100 Subject: [Distutils] [zc.buildout] versions section In-Reply-To: References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> Message-ID: <487E009F.10401@simplistix.co.uk> Jim Fulton wrote: > >> As best I can tell, it seems to be a recipe name used in a part. > > No. So the versions specified in a versions section apply to all uses of a "project"? (regardless of whether the project is an egg, a recipe, or something else?) >> What's the different between: >> >> [buildout] >> parts = foo >> versions = versions >> >> [versions] >> spam = 1 >> >> [foo] >> recipe = spam >> >> ...and: >> >> [buildout] >> parts = foo >> >> [foo] >> recipe = spam == 1 > > > There is no effective difference between these two examples. Often a > buildout refers to the same project more than once. Using versions > affects all uses. Using versions also applies to dependencies. Okay, what happens if I don't use a versions section and some egg has a dependency incompatible with a version of an egg I've specified elsewhere? (say in an egg recipe section?) Some to think of it, what happens if I *do* use a versions section and this happens? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Wed Jul 16 16:11:24 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 10:11:24 -0400 Subject: [Distutils] [zc.buildout] versions section In-Reply-To: <487E009F.10401@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> <487E009F.10401@simplistix.co.uk> Message-ID: <531A2DD8-CA0B-4E26-9908-708D57FAAB50@zope.com> On Jul 16, 2008, at 10:07 AM, Chris Withers wrote: > Jim Fulton wrote: >>> As best I can tell, it seems to be a recipe name used in a part. >> No. > > So the versions specified in a versions section apply to all uses of > a "project"? (regardless of whether the project is an egg, a recipe, > or something else?) Yes. A recipe is installed as an egg. The value of a recipe option is just a distribution (i.e. egg) requirement specification. > Okay, what happens if I don't use a versions section and some egg > has a dependency incompatible with a version of an egg I've > specified elsewhere? (say in an egg recipe section?) You'd get an error. This can happen whether or not you have a versions section. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Wed Jul 16 16:22:49 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 15:22:49 +0100 Subject: [Distutils] [zc.buildout] versions section (doesn't - does - erm? appear to work..) In-Reply-To: <487E009F.10401@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> <487E009F.10401@simplistix.co.uk> Message-ID: <487E0439.9050809@simplistix.co.uk> (apologies for half sent mail, emacs save file and thunderbird send message have the same key mapping :-S) Okay, so I had a simple buildout config as follows: [buildout] parts = eggs versions = versions [versions] setuptools-version = == 0.6c8 zc.buildout-version = == 1.0.6 [eggs] recipe = zc.recipe.egg eggs = BeautifulSoup == 3.0.7a interpreter = py extra-paths = . Now, from what Jim's said, it would seem like the versions section would be a good thing to use, so I tried changing the above recipe to: [buildout] parts = eggs versions = versions [versions] setuptools = 2 zc.buildout = 2 BeautifulSoup = 4 [eggs] recipe = zc.recipe.egg eggs = BeautifulSoup interpreter = py extra-paths = . Now, I could have sworn this ran without barfing on the (deliberately) non-existent versions. However, paranoidly re-checking before (*cough*) I sent the mail, it seems to work now. Are there any situations where this would fail? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Wed Jul 16 16:32:19 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 10:32:19 -0400 Subject: [Distutils] [zc.buildout] versions section (doesn't - does - erm? appear to work..) In-Reply-To: <487E0439.9050809@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> <487E009F.10401@simplistix.co.uk> <487E0439.9050809@simplistix.co.uk> Message-ID: On Jul 16, 2008, at 10:22 AM, Chris Withers wrote: > (apologies for half sent mail, emacs save file and thunderbird send > message have the same key mapping :-S) > > Okay, so I had a simple buildout config as follows: > > [buildout] > parts = eggs > versions = versions > > [versions] > setuptools-version = == 0.6c8 > zc.buildout-version = == 1.0.6 This isn't correct syntax. It should be just: setuptools-version = 0.6c8 zc.buildout-version = 1.0.6 > > > [eggs] > recipe = zc.recipe.egg > eggs = BeautifulSoup == 3.0.7a > interpreter = py > extra-paths = . > > Now, from what Jim's said, it would seem like the versions section > would be a good thing to use, so I tried changing the above recipe to: > > [buildout] > parts = eggs > versions = versions > > [versions] > setuptools = 2 > zc.buildout = 2 > BeautifulSoup = 4 These are non-existent versions. > [eggs] > recipe = zc.recipe.egg > eggs = BeautifulSoup > interpreter = py > extra-paths = . > > Now, I could have sworn this ran without barfing on the > (deliberately) non-existent versions. However, paranoidly re- > checking before (*cough*) I sent the mail, it seems to work now. I have no idea what you are trying to say. > Are there any situations where this would fail? Your buildout should fail as long as you have invalid versions for projects used in the buildout. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Wed Jul 16 16:44:10 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 16 Jul 2008 15:44:10 +0100 Subject: [Distutils] [zc.buildout] versions section (doesn't - does - erm? appear to work..) In-Reply-To: <487E0439.9050809@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> <487E009F.10401@simplistix.co.uk> <487E0439.9050809@simplistix.co.uk> Message-ID: <487E093A.9000908@simplistix.co.uk> Wow, what a total FAIL of a mail, apoliges for that :-( Okay, let me try this again from the top... So, I had a buildout that looked like this: [buildout] parts = eggs setuptools-version = == 0.6c8 zc.buildout-version = == 1.0.6 [eggs] recipe = zc.recipe.egg eggs = BeautifulSoup == 3.0.7a interpreter = py extra-paths = . ...using the (apparently soon to be deprecated) setuptools-version and zc.buildout-version options. From what Jim said, I changed this to be: [buildout] parts = eggs versions = versions [versions] setuptools = 2 zc.buildout = 2 BeautifulSoup = 4 [eggs] recipe = zc.recipe.egg eggs = BeautifulSoup interpreter = py extra-paths = . I deliberately picked non-existent versions in the hope that I'd see error messages saying these versions didn't exist. I could have sworn that the first time I ran buildout after this, nothing happened. But, given my recent finger clumsiness, I'm not so sure. Especially as now when I try, I get error messages about not being able to find distributions until I've changed the buildout to: [buildout] parts = eggs versions = versions [versions] setuptools = 0.6c8 zc.buildout = 1.0.6 BeautifulSoup = 3.0.7a [eggs] recipe = zc.recipe.egg eggs = BeautifulSoup interpreter = py extra-paths = . So I think everything's working as I expected, but I'm still left wondering if there are any situations where a [versions] section won't be checked and/or acted upon? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Wed Jul 16 17:00:36 2008 From: jim at zope.com (Jim Fulton) Date: Wed, 16 Jul 2008 11:00:36 -0400 Subject: [Distutils] [zc.buildout] versions section (doesn't - does - erm? appear to work..) In-Reply-To: <487E093A.9000908@simplistix.co.uk> References: <487D0930.90103@simplistix.co.uk> <487D23B9.80607@simplistix.co.uk> <487E009F.10401@simplistix.co.uk> <487E0439.9050809@simplistix.co.uk> <487E093A.9000908@simplistix.co.uk> Message-ID: <0784C38D-9EC2-4845-B416-5185C0A27755@zope.com> On Jul 16, 2008, at 10:44 AM, Chris Withers wrote: > So I think everything's working as I expected, but I'm still left > wondering if there are any situations where a [versions] section > won't be checked and/or acted upon? No. Jim -- Jim Fulton Zope Corporation From lumir.jasiok at vsb.cz Wed Jul 16 17:01:23 2008 From: lumir.jasiok at vsb.cz (=?ISO-8859-1?Q?Lum=EDr_Jasiok?=) Date: Wed, 16 Jul 2008 17:01:23 +0200 Subject: [Distutils] Scripts and configuration data Message-ID: <487E0D43.2000100@vsb.cz> Hi, I am developing small package that provide some Python package and some other data (scripts and configuration data). I know how to install script(s), bud I have no idea how to install configuration file(s) using setuptools. For example I have configuration file called "kiosk.conf" and I want to install it into "/etc/kiosk/" directory. So I have to create /etc/kiosk/ dir (if isn't already exists) and put the file into. How can I do this? Lumir -- Lum?r Jasiok VSB-TU Ostrava - Computer centre E-mail: lumir.jasiok at vsb.cz http://www.vsb.cz From zooko at zooko.com Wed Jul 16 18:35:09 2008 From: zooko at zooko.com (zooko) Date: Wed, 16 Jul 2008 10:35:09 -0600 Subject: [Distutils] [zc.buildout/egg-cache] .pyc files referencing temporary location? In-Reply-To: References: Message-ID: <1F2B6629-7279-4437-8BE2-BECF01D76D5E@zooko.com> On Jul 16, 2008, at 6:09 AM, Andreas Jung wrote: > We have some reports from co-workers working with zc.buildout and > an egg-cache where the .pyc files refer to temporary directories > within the egg-cache (obviously the location where the files within > the egg were unpacked and compiled) - something like that. > > P:\home\freyp\.buildout\eggs\tmp27l-TE\Products.LDAPUserFolder-2.5- > py2.4.egg\Products\LDAPUserFolder\LDAPUserFolder.py" > > Is there some solution other than removing the .pyc files? Unzip all eggs. You can add the following stanza to your distutils config file [1]: [easy_install] zip_ok=False By the way, here is where I keep notes about problems that people have encountered which they would not have encountered if setuptools unzipped all eggs by default: http://allmydata.org/trac/setuptools/ticket/4 (I ought to migrate those notes to the new official setuptools issue tracker.) Regards, Zooko [1] http://mail.python.org/pipermail/distutils-sig/2007-December/ 008554.html From philipp at weitershausen.de Thu Jul 17 06:25:28 2008 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Thu, 17 Jul 2008 00:25:28 -0400 Subject: [Distutils] [zc.buildout] general doc sprawl In-Reply-To: <487CFD0E.7000701@simplistix.co.uk> References: <487CFD0E.7000701@simplistix.co.uk> Message-ID: <487EC9B8.7080305@weitershausen.de> Chris Withers wrote: > If you go to http://pypi.python.org/pypi/zc.buildout/1.0.6 > the resulting page is *huge* :-( > > There doesn't appear to be any real structure to it and it reads as if > it's been added to by various different authors over time. It also seems > to be a good example of "doctests gone wrong" where the doc has become > less important than the test. I agree. This "README.txt" isn't really a good primer on zc.buildout anymore. Well, honestly, it never was. It should just be renamed so we can stop pretending it was a test. > Of particular difficulty is that sections often seem to refer to > concepts that are only introduced further down in the document. > > As someone trying to learn buildout in depth, what I'd most like is: > > - a short tutorial introduction (this bit is there, I think..) http://grok.zope.org/documentation/tutorial/introduction-to-zc.buildout > - a list/reference of the options passable when running buildout > (I think this appears about 30% of the way through that doc, but I'm > not sure all the options are covered) > > - a list/reference of the "commands" buildout has. I counted "install" > and "init" and maybe "bootstrap" too, but I don't know if that's all > and I'm still hazy about what the differences are between each one. bin/buildout --help ??? > - a list/reference of the options names that have meaning in the > [buildout] section to buildout itself. There seem to be a *lot* of > these and they're scattered throughout the document at that URL. I > have a horrible sinking feeling that I'm going to spend most of my > life with buildout trying to find the right option name to use :-/ > > - now, and now only, docs on how to write recipes and then on to the > more esoteric stuff, although I suspect the references above would > likely cover a lot of it. > > It'd also be great it it wasn't just one monolithic file, but I guess > that's just my reading preference :-S > > I'm afraid I'm unable to offer resources to try and fix this problem but > I do feel it should be highlighted as it makes buildout, which now that > I'm finally getting over the documentation barrier, seems to actually be > a very sturdy and useful tool (and gets over some of the setuptools, egg > and pypi suck), exponentially less easy to play with for newbies. > > Oh, and a parting shot: it would be great to get some idea of the "known > good" recipe types to use too. I see the plone guys have vomited several > million recipe eggs into pypi and, to be blunt, it's impossible to > figure out which were written by muppets and which by people with > functioning brains. You're several orders of magnitude off :). PyPI counts 99 recipes (http://pypi.python.org/pypi?:action=browse&show=all&c=512) and there aren't that many that provide the same kind of functionality. So why not jus try out a recipe when you need its functionality. If any of these were indeed written by "muppets", you'd find out pretty quickly, no? > Someone mentioned a cmmi recipe at EPC. That sounded interesting but now > I don't know where to find it... http://www.google.com/search?q=buildout+cmmi+recipe From chris at simplistix.co.uk Fri Jul 18 18:33:24 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 18 Jul 2008 17:33:24 +0100 Subject: [Distutils] [zc.buildout] grok's buildout tutorial In-Reply-To: <487EC9B8.7080305@weitershausen.de> References: <487CFD0E.7000701@simplistix.co.uk> <487EC9B8.7080305@weitershausen.de> Message-ID: <4880C5D4.4040709@simplistix.co.uk> Philipp von Weitershausen wrote: >> - a short tutorial introduction (this bit is there, I think..) > > http://grok.zope.org/documentation/tutorial/introduction-to-zc.buildout Maybe that should get worked onto buildout.zope.org? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Fri Jul 18 18:37:22 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 18 Jul 2008 17:37:22 +0100 Subject: [Distutils] [zc.buildout] general doc sprawl In-Reply-To: <487EC9B8.7080305@weitershausen.de> References: <487CFD0E.7000701@simplistix.co.uk> <487EC9B8.7080305@weitershausen.de> Message-ID: <4880C6C2.30108@simplistix.co.uk> Philipp von Weitershausen wrote: > I agree. This "README.txt" isn't really a good primer on zc.buildout > anymore. Well, honestly, it never was. It should just be renamed so we > can stop pretending it was a test. ...and maybe not have it show up as pypi's readme for buildout? >> - a list/reference of the options passable when running buildout >> (I think this appears about 30% of the way through that doc, but I'm >> not sure all the options are covered) >> >> - a list/reference of the "commands" buildout has. I counted "install" >> and "init" and maybe "bootstrap" too, but I don't know if that's all >> and I'm still hazy about what the differences are between each one. > > bin/buildout --help ??? Oooh... yeah, this does solve the above two. >> - a list/reference of the options names that have meaning in the >> [buildout] section to buildout itself. There seem to be a *lot* of >> these and they're scattered throughout the document at that URL. I >> have a horrible sinking feeling that I'm going to spend most of my >> life with buildout trying to find the right option name to use :-/ Nothing on this one though :-S >> Oh, and a parting shot: it would be great to get some idea of the >> "known good" recipe types to use too. I see the plone guys have >> vomited several million recipe eggs into pypi and, to be blunt, it's >> impossible to figure out which were written by muppets and which by >> people with functioning brains. > > You're several orders of magnitude off :). PyPI counts 99 recipes > (http://pypi.python.org/pypi?:action=browse&show=all&c=512) and there > aren't that many that provide the same kind of functionality. Yeah, like ccmi ;-) > So why not > jus try out a recipe when you need its functionality. If any of these > were indeed written by "muppets", you'd find out pretty quickly, no? Yes, after they've trashed your whole system, etc... >> Someone mentioned a cmmi recipe at EPC. That sounded interesting but >> now I don't know where to find it... > > http://www.google.com/search?q=buildout+cmmi+recipe pypi.python.org/pypi/hexagonit.recipe.cmmi/ pypi.python.org/pypi/zc.recipe.cmmi/ Which to go for? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Fri Jul 18 18:39:46 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 18 Jul 2008 17:39:46 +0100 Subject: [Distutils] [zc.buildout] init/bootstrap commands Message-ID: <4880C752.1080701@simplistix.co.uk> Hi All, Is it just be or would it be better if: - the bootstrap command also copied the latest bootstrap.py into the new buildout? - the bootstrap and init commands were combined? I can't see where they're useful on their own... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Fri Jul 18 19:41:08 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 18 Jul 2008 18:41:08 +0100 Subject: [Distutils] [zc.buildout] init/bootstrap commands In-Reply-To: <44C915C1-C14B-41AC-B742-697178824D31@zope.com> References: <4880C752.1080701@simplistix.co.uk> <44C915C1-C14B-41AC-B742-697178824D31@zope.com> Message-ID: <4880D5B4.2020704@simplistix.co.uk> Jim Fulton wrote: > > On Jul 18, 2008, at 12:39 PM, Chris Withers wrote: > >> Hi All, >> >> Is it just be or would it be better if: >> >> - the bootstrap command also copied the latest bootstrap.py into the >> new buildout? > > I don't think so. Why not? >> - the bootstrap and init commands were combined? I can't see where >> they're useful on their own... > > > The benefit of the init command is so minor, I'd be happy to see it go > away. What needs to happen for that to happen? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Fri Jul 18 19:42:38 2008 From: jim at zope.com (Jim Fulton) Date: Fri, 18 Jul 2008 13:42:38 -0400 Subject: [Distutils] [zc.buildout] init/bootstrap commands In-Reply-To: <4880D5B4.2020704@simplistix.co.uk> References: <4880C752.1080701@simplistix.co.uk> <44C915C1-C14B-41AC-B742-697178824D31@zope.com> <4880D5B4.2020704@simplistix.co.uk> Message-ID: <7FAF19BB-B8B3-4138-8A67-2342066CBBAC@zope.com> On Jul 18, 2008, at 1:41 PM, Chris Withers wrote: > Jim Fulton wrote: >> On Jul 18, 2008, at 12:39 PM, Chris Withers wrote: >>> Hi All, >>> >>> Is it just be or would it be better if: >>> >>> - the bootstrap command also copied the latest bootstrap.py into >>> the new buildout? >> I don't think so. > > Why not? Because people may not *want* a bootstrap.py. I would be annoyed if one was put in my buildout. >>> - the bootstrap and init commands were combined? I can't see where >>> they're useful on their own... >> The benefit of the init command is so minor, I'd be happy to see it >> go away. > > What needs to happen for that to happen? I wouldn't actually remove it -- for backward compatibility reasons. I'd just remove it from the documentation. Jim -- Jim Fulton Zope Corporation From jim at zope.com Fri Jul 18 19:39:49 2008 From: jim at zope.com (Jim Fulton) Date: Fri, 18 Jul 2008 13:39:49 -0400 Subject: [Distutils] [zc.buildout] init/bootstrap commands In-Reply-To: <4880C752.1080701@simplistix.co.uk> References: <4880C752.1080701@simplistix.co.uk> Message-ID: <44C915C1-C14B-41AC-B742-697178824D31@zope.com> On Jul 18, 2008, at 12:39 PM, Chris Withers wrote: > Hi All, > > Is it just be or would it be better if: > > - the bootstrap command also copied the latest bootstrap.py into the > new buildout? I don't think so. > - the bootstrap and init commands were combined? I can't see where > they're useful on their own... The benefit of the init command is so minor, I'd be happy to see it go away. Jim -- Jim Fulton Zope Corporation From gustavo at gnulinuxmatters.org Fri Jul 18 22:07:06 2008 From: gustavo at gnulinuxmatters.org (Gustavo Narea) Date: Fri, 18 Jul 2008 22:07:06 +0200 Subject: [Distutils] `develop' doesn't appends my package's directory to sys.path Message-ID: <200807182207.14846.gustavo@gnulinuxmatters.org> Hello, everyone. I have an script which is supposed to run my test suite periodically, and the routine is basically this: 1.- It checkouts my app's source from the repository, and stores it in a different directory on every checkout. 2.- It runs setuptools build. 3.- It runs setuptools develop. 4.- It runs my test suite (via setuptools unittest). But setuptools' develop doesn't append my project's path to sys.path; I don't know what is going on, but I'm absolutely sure about that. Here is part of the verbose output of the script (it's actually not an script per se; I'm using an Ant like app, part of the Bitten continuous integration system): > [DEBUG ] Executing with arguments: > {'executable': './setup.py', 'args': 'develop'} > [DEBUG ] Executing ['./setup.py', 'develop'] And because my package is not accessible, its modules are not accessible either: > ImportError: No module named build.lib.animador.config Then, from the Python interpreter, I check sys.path and I find that my package's path is not included. But if I manually run `setup.py develop', and then open the Python interpreter again, the path is included. Here's the output of my script http://paste.turbogears.org/paste/3255 and here's the full output of `setup.py develop' http://paste.turbogears.org/paste/3256 Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk I hope someone can help me out; I have spent days trying to fix this. Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From philipp at weitershausen.de Fri Jul 18 22:20:58 2008 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Fri, 18 Jul 2008 16:20:58 -0400 Subject: [Distutils] [zc.buildout] grok's buildout tutorial In-Reply-To: <4880C5D4.4040709@simplistix.co.uk> References: <487CFD0E.7000701@simplistix.co.uk> <487EC9B8.7080305@weitershausen.de> <4880C5D4.4040709@simplistix.co.uk> Message-ID: El 18 Jul 2008, a las 12:33 , Chris Withers escribi?: > Philipp von Weitershausen wrote: >>> - a short tutorial introduction (this bit is there, I think..) >> http://grok.zope.org/documentation/tutorial/introduction-to-zc.buildout > > Maybe that should get worked onto buildout.zope.org? http://buildout.zope.org/docs/tutorial.html From pje at telecommunity.com Sat Jul 19 00:27:02 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 18 Jul 2008 18:27:02 -0400 Subject: [Distutils] `develop' doesn't appends my package's directory to sys.path In-Reply-To: <200807182207.14846.gustavo@gnulinuxmatters.org> References: <200807182207.14846.gustavo@gnulinuxmatters.org> Message-ID: <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> I would suggest setting DISTUTILS_DEBUG=yes in your environment when running both, and compare the other environment contents. My guess is that you are either running a different Python executable or have a different HOME -- which might change what setup.cfg is being used, and thus the target install directory. Notice in particular that the run for your wrapper script says that it is already present in easy-install.pth, while the other run does not. This suggests that the target installation path is different. Personally, however, I don't see the point of your script running "build" or "develop" prior to "test"; running "test" will both do a build and put the package on sys.path for the duration of the test run, so the preceding commands are redundant. Also, if for some reason you *did* need to run all three in sequence, you could just do "setup.py build develop test" and save a lot of excess overhead and repetition. At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote: >Hello, everyone. > >I have an script which is supposed to run my test suite periodically, and the >routine is basically this: > 1.- It checkouts my app's source from the repository, and stores it in a >different directory on every checkout. > 2.- It runs setuptools build. > 3.- It runs setuptools develop. > 4.- It runs my test suite (via setuptools unittest). > >But setuptools' develop doesn't append my project's path to sys.path; I don't >know what is going on, but I'm absolutely sure about that. Here is part of >the verbose output of the script (it's actually not an script per se; I'm >using an Ant like app, part of the Bitten continuous integration system): > > > [DEBUG ] Executing with arguments: > > {'executable': './setup.py', 'args': 'develop'} > > [DEBUG ] Executing ['./setup.py', 'develop'] > >And because my package is not accessible, its modules are not accessible >either: > > ImportError: No module named build.lib.animador.config > >Then, from the Python interpreter, I check sys.path and I find that my >package's path is not included. But if I manually run `setup.py develop', and >then open the Python interpreter again, the path is included. > >Here's the output of my script http://paste.turbogears.org/paste/3255 and >here's the full output of `setup.py develop' >http://paste.turbogears.org/paste/3256 > >Also, here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ >and here you can browse the source code: >https://tracker.gnulinuxmatters.org/browser/animador/trunk > >I hope someone can help me out; I have spent days trying to fix this. > >Thanks in advance. >-- >Gustavo Narea. >General Secretary. GNU/Linux Matters. >http://www.gnulinuxmatters.org/ > > >_______________________________________________ >Distutils-SIG maillist - Distutils-SIG at python.org >http://mail.python.org/mailman/listinfo/distutils-sig From robotguy at hybotics.com Sat Jul 19 12:09:08 2008 From: robotguy at hybotics.com (Dale Weber) Date: Sat, 19 Jul 2008 03:09:08 -0700 Subject: [Distutils] Cross compiling with extensions In-Reply-To: <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> References: <200807182207.14846.gustavo@gnulinuxmatters.org> <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> Message-ID: <1216462148.22805.7.camel@dsl093-038-072.pdx1.dsl.speakeasy.net> Hi, everyone, I've been in the process of rebuilding my robot, W.A.L.T.E.R. and will be using Python to create all the new control and interface software for it. I'm currently using Gentoo Embedded Linux on a TinCanTools Hammer Board (http://www.tincantools.com). I have gotten all the software components I need cross compiled except two - pysqlite and imaging (Python Imaging). These packages have extensions, and will not cross compile properly. I'm willing to do work on getting a cross compile working for these types of packages, but am not quite sure where to start. I've been looking at the code for distutils that installes with Python 2.4.4, and I think I understand at least part of what needs to be done, but again am not completely sure because I don't know how to interface to distutils. What is the proper way to interface to distutils to start a build? Is there already a mechanism to tell distutils which compiler to use and/or which platform to build for? 8-Dale From jim at zope.com Sat Jul 19 17:09:47 2008 From: jim at zope.com (Jim Fulton) Date: Sat, 19 Jul 2008 11:09:47 -0400 Subject: [Distutils] [buildout] New buildout release that recompiles and can always unzip Message-ID: <9FD4D57D-0A00-4585-9266-0C563E388856@zope.com> I just made a new release of zc.buildout, 1.1.0, that: - Provides a global buildout option, unzip, that sets the default policy for unzipping eggs. If you include: unzip = true in your buildout section, then all eggs will be unzipped by default. Note that you'll need zc.recipe.egg 1.1.0 or later for this to work for eggs installed by the egg recipes. - Now recompile Python files when eggs are installed unzipped. This is helpful for debugging, as the file names stored in code objects will be correct. Both pyc and pyo files are produced. (Most eggs only have pyc files.) Jim -- Jim Fulton Zope Corporation From gustavo at gnulinuxmatters.org Sat Jul 19 19:32:48 2008 From: gustavo at gnulinuxmatters.org (Gustavo Narea) Date: Sat, 19 Jul 2008 19:32:48 +0200 Subject: [Distutils] `develop' doesn't appends my package's directory to sys.path In-Reply-To: <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> References: <200807182207.14846.gustavo@gnulinuxmatters.org> <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> Message-ID: <200807191932.56942.gustavo@gnulinuxmatters.org> Hello, Phillip. I don't really understand why, but if I don't run "build" my script works. However I need "develop" because the Ant-like tool runs my test suite on a different folder for every svn revision. If I remove "build", I get an import error because my modules are not accessible. Thanks for your help! Cheers. On Saturday 19 July 2008 00:27:02 Phillip J. Eby wrote: > I would suggest setting DISTUTILS_DEBUG=yes in your environment when > running both, and compare the other environment contents. My guess > is that you are either running a different Python executable or have > a different HOME -- which might change what setup.cfg is being used, > and thus the target install directory. > > Notice in particular that the run for your wrapper script says that > it is already present in easy-install.pth, while the other run does > not. This suggests that the target installation path is different. > > Personally, however, I don't see the point of your script running > "build" or "develop" prior to "test"; running "test" will both do a > build and put the package on sys.path for the duration of the test > run, so the preceding commands are redundant. Also, if for some > reason you *did* need to run all three in sequence, you could just do > "setup.py build develop test" and save a lot of excess overhead and > repetition. > > At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote: > >Hello, everyone. > > > >I have an script which is supposed to run my test suite periodically, and > > the routine is basically this: > > 1.- It checkouts my app's source from the repository, and stores it in a > >different directory on every checkout. > > 2.- It runs setuptools build. > > 3.- It runs setuptools develop. > > 4.- It runs my test suite (via setuptools unittest). > > > >But setuptools' develop doesn't append my project's path to sys.path; I > > don't know what is going on, but I'm absolutely sure about that. Here is > > part of the verbose output of the script (it's actually not an script per > > se; I'm > > > >using an Ant like app, part of the Bitten continuous integration system): > > > [DEBUG ] Executing with arguments: > > > {'executable': './setup.py', 'args': 'develop'} > > > [DEBUG ] Executing ['./setup.py', 'develop'] > > > >And because my package is not accessible, its modules are not accessible > > > >either: > > > ImportError: No module named build.lib.animador.config > > > >Then, from the Python interpreter, I check sys.path and I find that my > >package's path is not included. But if I manually run `setup.py develop', > > and then open the Python interpreter again, the path is included. > > > >Here's the output of my script http://paste.turbogears.org/paste/3255 and > >here's the full output of `setup.py develop' > >http://paste.turbogears.org/paste/3256 > > > >Also, here's my repository > > https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can > > browse the source code: > >https://tracker.gnulinuxmatters.org/browser/animador/trunk > > > >I hope someone can help me out; I have spent days trying to fix this. > > > >Thanks in advance. > >-- > >Gustavo Narea. > >General Secretary. GNU/Linux Matters. > >http://www.gnulinuxmatters.org/ > > > > > >_______________________________________________ > >Distutils-SIG maillist - Distutils-SIG at python.org > >http://mail.python.org/mailman/listinfo/distutils-sig -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From gustavo at gnulinuxmatters.org Sat Jul 19 19:55:24 2008 From: gustavo at gnulinuxmatters.org (Gustavo Narea) Date: Sat, 19 Jul 2008 19:55:24 +0200 Subject: [Distutils] HTML files are included in code coverage analysis Message-ID: <200807191955.24706.gustavo@gnulinuxmatters.org> Hello, everyone. If I run `setup.py unittest', everything works (http://paste.turbogears.org/paste/3279), but if I run it with the following options: --xml-output build/test-results.xml --coverage-summary \ build/test-coverage.txt --coverage-dir build/coverage it fails because it includes *.html files in the code coverage: http://paste.turbogears.org/paste/3280 How can I avoid that HTML files are included in the code coverage analysis? I couldn't find the answer via `./setup.py unittest --help' Here's my repository https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can browse the source code: https://tracker.gnulinuxmatters.org/browser/animador/trunk Thanks in advance. -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pje at telecommunity.com Sat Jul 19 20:35:54 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat, 19 Jul 2008 14:35:54 -0400 Subject: [Distutils] `develop' doesn't appends my package's directory to sys.path In-Reply-To: <200807191932.56942.gustavo@gnulinuxmatters.org> References: <200807182207.14846.gustavo@gnulinuxmatters.org> <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> <200807191932.56942.gustavo@gnulinuxmatters.org> Message-ID: <20080719183509.E95743A407B@sparrow.telecommunity.com> It doesn't sound like you read what I wrote below, or that you did any of what I said to do, so I'm not sure what other help I can offer. (Also, your statements about "develop" and "build" are mutually inconsistent.) At 07:32 PM 7/19/2008 +0200, Gustavo Narea wrote: >Hello, Phillip. > >I don't really understand why, but if I don't run "build" my script works. > >However I need "develop" because the Ant-like tool runs my test suite on a >different folder for every svn revision. If I remove "build", I get an import >error because my modules are not accessible. > >Thanks for your help! > >Cheers. > >On Saturday 19 July 2008 00:27:02 Phillip J. Eby wrote: > > I would suggest setting DISTUTILS_DEBUG=yes in your environment when > > running both, and compare the other environment contents. My guess > > is that you are either running a different Python executable or have > > a different HOME -- which might change what setup.cfg is being used, > > and thus the target install directory. > > > > Notice in particular that the run for your wrapper script says that > > it is already present in easy-install.pth, while the other run does > > not. This suggests that the target installation path is different. > > > > Personally, however, I don't see the point of your script running > > "build" or "develop" prior to "test"; running "test" will both do a > > build and put the package on sys.path for the duration of the test > > run, so the preceding commands are redundant. Also, if for some > > reason you *did* need to run all three in sequence, you could just do > > "setup.py build develop test" and save a lot of excess overhead and > > repetition. > > > > At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote: > > >Hello, everyone. > > > > > >I have an script which is supposed to run my test suite periodically, and > > > the routine is basically this: > > > 1.- It checkouts my app's source from the repository, and stores it in a > > >different directory on every checkout. > > > 2.- It runs setuptools build. > > > 3.- It runs setuptools develop. > > > 4.- It runs my test suite (via setuptools unittest). > > > > > >But setuptools' develop doesn't append my project's path to sys.path; I > > > don't know what is going on, but I'm absolutely sure about that. Here is > > > part of the verbose output of the script (it's actually not an script per > > > se; I'm > > > > > >using an Ant like app, part of the Bitten continuous integration system): > > > > [DEBUG ] Executing with arguments: > > > > {'executable': './setup.py', 'args': 'develop'} > > > > [DEBUG ] Executing ['./setup.py', 'develop'] > > > > > >And because my package is not accessible, its modules are not accessible > > > > > >either: > > > > ImportError: No module named build.lib.animador.config > > > > > >Then, from the Python interpreter, I check sys.path and I find that my > > >package's path is not included. But if I manually run `setup.py develop', > > > and then open the Python interpreter again, the path is included. > > > > > >Here's the output of my script http://paste.turbogears.org/paste/3255 and > > >here's the full output of `setup.py develop' > > >http://paste.turbogears.org/paste/3256 > > > > > >Also, here's my repository > > > https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can > > > browse the source code: > > >https://tracker.gnulinuxmatters.org/browser/animador/trunk > > > > > >I hope someone can help me out; I have spent days trying to fix this. > > > > > >Thanks in advance. > > >-- > > >Gustavo Narea. > > >General Secretary. GNU/Linux Matters. > > >http://www.gnulinuxmatters.org/ > > > > > > > > >_______________________________________________ > > >Distutils-SIG maillist - Distutils-SIG at python.org > > >http://mail.python.org/mailman/listinfo/distutils-sig > > >-- >Gustavo Narea. >General Secretary. GNU/Linux Matters. >http://www.gnulinuxmatters.org/ > From tseaver at palladion.com Sat Jul 19 20:39:24 2008 From: tseaver at palladion.com (Tres Seaver) Date: Sat, 19 Jul 2008 14:39:24 -0400 Subject: [Distutils] Cross compiling with extensions In-Reply-To: <1216462148.22805.7.camel@dsl093-038-072.pdx1.dsl.speakeasy.net> References: <200807182207.14846.gustavo@gnulinuxmatters.org> <20080718222700.1D5DF3A4080@sparrow.telecommunity.com> <1216462148.22805.7.camel@dsl093-038-072.pdx1.dsl.speakeasy.net> Message-ID: <488234DC.5070905@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dale Weber wrote: > Hi, everyone, > > I've been in the process of rebuilding my robot, W.A.L.T.E.R. and will > be using Python to create all the new control and interface software for > it. I'm currently using Gentoo Embedded Linux on a TinCanTools Hammer > Board (http://www.tincantools.com). I have gotten all the software > components I need cross compiled except two - pysqlite and imaging > (Python Imaging). These packages have extensions, and will not cross > compile properly. > > I'm willing to do work on getting a cross compile working for these > types of packages, but am not quite sure where to start. I've been > looking at the code for distutils that installes with Python 2.4.4, and > I think I understand at least part of what needs to be done, but again > am not completely sure because I don't know how to interface to > distutils. > > What is the proper way to interface to distutils to start a build? Is > there already a mechanism to tell distutils which compiler to use and/or > which platform to build for? You can run the 'build_ext' step separately, which allows you to specify several options you may need:: - ----------------------- 8< ---------------------------------- $ python setup.py build_ext --help Global options: --verbose (-v) run verbosely (default) --quiet (-q) run quietly (turns verbosity off) --dry-run (-n) don't actually do anything --help (-h) show detailed help message Options for 'build_ext' command: --build-lib (-b) directory for compiled extension modules --build-temp (-t) directory for temporary files (build by-products) --inplace (-i) ignore build-lib and put compiled extensions into the source directory alongside your pure Python modules --include-dirs (-I) list of directories to search for header files (separated by ':') --define (-D) C preprocessor macros to define --undef (-U) C preprocessor macros to undefine --libraries (-l) external C libraries to link with --library-dirs (-L) directories to search for external C libraries (separated by ':') --rpath (-R) directories to search for shared C libraries at runtime --link-objects (-O) extra explicit link objects to include in the link --debug (-g) compile/link with debugging information --force (-f) forcibly build everything (ignore file timestamps) --compiler (-c) specify the compiler type --swig-cpp make SWIG create C++ files (default is C) --swig-opts list of SWIG command line options --swig path to the SWIG executable --help-compiler list available compilers usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help $ python setup.py build_ext --help-compiler List of available compilers: --compiler=bcpp Borland C++ Compiler --compiler=cygwin Cygwin port of GNU C Compiler for Win32 --compiler=emx EMX port of GNU C Compiler for OS/2 --compiler=mingw32 Mingw32 port of GNU C Compiler for Win32 --compiler=msvc Microsoft Visual C++ --compiler=mwerks MetroWerks CodeWarrior --compiler=unix standard UNIX-style compiler - ----------------------- 8< ---------------------------------- Hope that helps, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgjTc+gerLs4ltQ4RAjjQAKC1+gANXAHX41mPUgYF1FLKIgi5ggCglo7v UWDXEmNG0/ezLflE1q+hSEE= =volI -----END PGP SIGNATURE----- From erik1vandamme at gmail.com Sun Jul 20 09:19:39 2008 From: erik1vandamme at gmail.com (Darthcoder) Date: Sun, 20 Jul 2008 00:19:39 -0700 (PDT) Subject: [Distutils] Distutils for CygWin pyffmpeg Message-ID: <18552019.post@talk.nabble.com> During the build of pyFFMpeg.py etc under CygWin/msys following error occurs File "F:\Python25\lib\distutils\version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '2.18.50.20080109' According to the forums this is some sort of bug inside distutils... One recommendations is to use version 1.37. instead of current 1.38 cause that uses unixcompiler.py instead of cygwincompiler.py,... how does one to this? -- View this message in context: http://www.nabble.com/Distutils-for-CygWin-pyffmpeg-tp18552019p18552019.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From gustavo at gnulinuxmatters.org Sun Jul 20 14:34:02 2008 From: gustavo at gnulinuxmatters.org (Gustavo Narea) Date: Sun, 20 Jul 2008 14:34:02 +0200 Subject: [Distutils] `develop' doesn't appends my package's directory to sys.path In-Reply-To: <20080719183509.E95743A407B@sparrow.telecommunity.com> References: <200807182207.14846.gustavo@gnulinuxmatters.org> <200807191932.56942.gustavo@gnulinuxmatters.org> <20080719183509.E95743A407B@sparrow.telecommunity.com> Message-ID: <200807201434.20227.gustavo@gnulinuxmatters.org> Hello, Phillip. On Saturday 19 July 2008 20:35:54 Phillip J. Eby wrote: > It doesn't sound like you read what I wrote below, or that you did > any of what I said to do, so I'm not sure what other help I can > offer. I did do what you said, and sorry for not letting you know about the result I got. The output is basically the same; the environment contents are exactly the same (which you can verify, because the output is attached). The only thing that changes is that with the build system I get > Animador 1.0a1 is already the active version in easy-install.pth while with `setup.py develop' I get > Adding Animador 1.0a1 to easy-install.pth file But that's the only difference. I found that if I remove "build", the test suite finally works, and therefore I didn't try to understand what's the problem with setuptools' develop in my script if the environment contents are the same as in `setup.py develop'. > (Also, your statements about "develop" and "build" are > mutually inconsistent.) I don't understand why you think that. Setuptools' build is included in the only example of configuration file for a Python-powered project I found in the documentation of the continuous integration system I use, Bitten, so I thought it was required and therefore I included it in my script. But when I noticed it breaks the script, I removed it. Regarding "develop", I had to include it in my script because otherwise my packages' modules wouldn't be accessible - I got import errors when I didn't use it. Thank you very much for your help. Cheers, - Gustavo. > At 07:32 PM 7/19/2008 +0200, Gustavo Narea wrote: > >Hello, Phillip. > > > >I don't really understand why, but if I don't run "build" my script works. > > > >However I need "develop" because the Ant-like tool runs my test suite on a > >different folder for every svn revision. If I remove "build", I get an > > import error because my modules are not accessible. > > > >Thanks for your help! > > > >Cheers. > > > >On Saturday 19 July 2008 00:27:02 Phillip J. Eby wrote: > > > I would suggest setting DISTUTILS_DEBUG=yes in your environment when > > > running both, and compare the other environment contents. My guess > > > is that you are either running a different Python executable or have > > > a different HOME -- which might change what setup.cfg is being used, > > > and thus the target install directory. > > > > > > Notice in particular that the run for your wrapper script says that > > > it is alrady present in easy-install.pth, while the other run does > > > not. This suggests that the target installation path is different. > > > > > > Personally, however, I don't see the point of your script running > > > "build" or "develop" prior to "test"; running "test" will both do a > > > build and put the package on sys.path for the duration of the test > > > run, so the preceding commands are redundant. Also, if for some > > > reason you *did* need to run all three in sequence, you could just do > > > "setup.py build develop test" and save a lot of excess overhead and > > > repetition. > > > > > > At 10:07 PM 7/18/2008 +0200, Gustavo Narea wrote: > > > >Hello, everyone. > > > > > > > >I have an script which is supposed to run my test suite periodically, > > > > and the routine is basically this: > > > > 1.- It checkouts my app's source from the repository, and stores it > > > > in a different directory on every checkout. > > > > 2.- It runs setuptools build. > > > > 3.- It runs setuptools develop. > > > > 4.- It runs my test suite (via setuptools unittest). > > > > > > > >But setuptools' develop doesn't append my project's path to sys.path; > > > > I don't know what is going on, but I'm absolutely sure about that. > > > > Here is part of the verbose output of the script (it's actually not > > > > an script per se; I'm > > > > > > > >using an Ant like app, part of the Bitten continuous integration system): > > > > > [DEBUG ] Executing with arguments: > > > > > {'executable': './setup.py', 'args': 'develop'} > > > > > [DEBUG ] Executing ['./setup.py', 'develop'] > > > > > > > >And because my package is not accessible, its modules are not > > > > accessible > > > > > > > >either: > > > > > ImportError: No module named build.lib.animador.config > > > > > > > >Then, from the Python interpreter, I check sys.path and I find that my > > > >package's path is not included. But if I manually run `setup.py > > > > develop', and then open the Python interpreter again, the path is > > > > included. > > > > > > > >Here's the output of my script http://paste.turbogears.org/paste/3255 > > > > and here's the full output of `setup.py develop' > > > >http://paste.turbogears.org/paste/3256 > > > > > > > >Also, here's my repository > > > > https://svn.gnulinuxmatters.org:81/animador/trunk/ and here you can > > > > browse the source code: > > > >https://tracker.gnulinuxmatters.org/browser/animador/trunk > > > > > > > >I hope someone can help me out; I have spent days trying to fix this. > > > > > > > >Thanks in advance. > > > >-- > > > >Gustavo Narea. > > > >General Secretary. GNU/Linux Matters. > > > >http://www.gnulinuxmatters.org/ > > > > > > > > > > > >_______________________________________________ > > > >Distutils-SIG maillist - Distutils-SIG at python.org > > > >http://mail.python.org/mailman/listinfo/distutils-sig > > > >-- > >Gustavo Narea. > >General Secretary. GNU/Linux Matters. > >http://www.gnulinuxmatters.org/ -- Gustavo Narea. General Secretary. GNU/Linux Matters. http://www.gnulinuxmatters.org/ -------------- next part -------------- Executing with arguments: {'command': 'develop'} Executing ['/usr/bin/python', '/home/gustavo/builds/build_animador-trunk_13/setup.py', 'develop'] Distribution.parse_config_files(): options (after parsing config files): no commands known yet options (after parsing command line): option dict for 'aliases' command: {} option dict for 'develop' command: {} running develop Distribution.get_command_obj(): creating 'develop' command object setting options for 'develop' command: Distribution.get_command_obj(): creating 'egg_info' command object Distribution.get_command_obj(): creating 'install' command object pre-finalize_{unix,other}: prefix: None exec_prefix: None home: None install_base: None install_platbase: None root: None install_purelib: None install_platlib: None install_lib: None install_headers: None install_scripts: None install_data: None compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None post-finalize_{unix,other}(): prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: $base/lib/python$py_version_short/site-packages install_platlib: $platbase/lib/python$py_version_short/site-packages install_lib: None install_headers: $base/include/python$py_version_short/$dist_name install_scripts: $base/bin install_data: $base compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None post-expand_basedirs(): prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: $base/lib/python$py_version_short/site-packages install_platlib: $platbase/lib/python$py_version_short/site-packages install_lib: None install_headers: $base/include/python$py_version_short/$dist_name install_scripts: $base/bin install_data: $base compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None config vars: {'base': '/usr', 'dist_fullname': 'Animador-1.0a1', 'dist_name': 'Animador', 'dist_version': '1.0a1', 'exec_prefix': '/usr', 'platbase': '/usr', 'prefix': '/usr', 'py_version': '2.5.2', 'py_version_short': '2.5', 'sys_exec_prefix': '/usr', 'sys_prefix': '/usr'} post-expand_dirs(): prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: /usr/lib/python2.5/site-packages install_platlib: /usr/lib/python2.5/site-packages install_lib: None install_headers: /usr/include/python2.5/Animador install_scripts: /usr/bin install_data: /usr compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None after prepending root: prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: /usr/lib/python2.5/site-packages install_platlib: /usr/lib/python2.5/site-packages install_lib: /usr/lib/python2.5/site-packages/ install_headers: /usr/include/python2.5/Animador install_scripts: /usr/bin install_data: /usr compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None Distribution.get_command_obj(): creating 'build' command object Distribution.get_command_obj(): creating 'install_lib' command object Distribution.get_command_obj(): creating 'install_scripts' command object running egg_info paster_plugins not set in setup(), but Animador.egg-info/paster_plugins.txt exists writing requirements to Animador.egg-info/requires.txt writing Animador.egg-info/PKG-INFO writing top-level names to Animador.egg-info/top_level.txt writing dependency_links to Animador.egg-info/dependency_links.txt writing entry points to Animador.egg-info/entry_points.txt Distribution.get_command_obj(): creating 'build_py' command object package init file 'locales/__init__.py' not found (or not a regular file) include_pattern: applying regex r'^Animador\.egg\-info/.*[^/]*$' adding Animador.egg-info/entry_points.txt adding Animador.egg-info/SOURCES.txt adding Animador.egg-info/dependency_links.txt adding Animador.egg-info/not-zip-safe adding Animador.egg-info/requires.txt adding Animador.egg-info/paster_plugins.txt adding Animador.egg-info/top_level.txt adding Animador.egg-info/PKG-INFO adding Animador.egg-info/.svn/all-wcprops adding Animador.egg-info/.svn/entries adding Animador.egg-info/.svn/format adding Animador.egg-info/.svn/text-base/requires.txt.svn-base adding Animador.egg-info/.svn/text-base/PKG-INFO.svn-base adding Animador.egg-info/.svn/text-base/not-zip-safe.svn-base adding Animador.egg-info/.svn/text-base/paster_plugins.txt.svn-base adding Animador.egg-info/.svn/text-base/SOURCES.txt.svn-base adding Animador.egg-info/.svn/text-base/dependency_links.txt.svn-base adding Animador.egg-info/.svn/text-base/entry_points.txt.svn-base adding Animador.egg-info/.svn/text-base/top_level.txt.svn-base exclude_pattern: applying regex r'^build/.*' exclude_pattern: applying regex r'^Animador\-1\.0a1/.*' exclude_pattern: applying regex r'\/(RCS|CVS|\.svn)\/' removing Animador.egg-info/.svn/text-base/top_level.txt.svn-base removing Animador.egg-info/.svn/text-base/entry_points.txt.svn-base removing Animador.egg-info/.svn/text-base/dependency_links.txt.svn-base removing Animador.egg-info/.svn/text-base/SOURCES.txt.svn-base removing Animador.egg-info/.svn/text-base/paster_plugins.txt.svn-base removing Animador.egg-info/.svn/text-base/not-zip-safe.svn-base removing Animador.egg-info/.svn/text-base/PKG-INFO.svn-base removing Animador.egg-info/.svn/text-base/requires.txt.svn-base removing Animador.egg-info/.svn/format removing Animador.egg-info/.svn/entries removing Animador.egg-info/.svn/all-wcprops writing manifest file 'Animador.egg-info/SOURCES.txt' Distribution.get_command_obj(): creating 'build_ext' command object running build_ext Creating /usr/lib/python2.5/site-packages/Animador.egg-link (link to .) Animador 1.0a1 is already the active version in easy-install.pth Installing start-animador script to /usr/bin Installed /home/gustavo/builds/build_animador-trunk_13 Processing dependencies for Animador==1.0a1 Searching for Elixir==0.5.2 Best match: Elixir 0.5.2 Processing Elixir-0.5.2-py2.5.egg Elixir 0.5.2 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/Elixir-0.5.2-py2.5.egg Searching for SQLAlchemy==0.4.6 Best match: SQLAlchemy 0.4.6 Processing SQLAlchemy-0.4.6-py2.5.egg SQLAlchemy 0.4.6 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/SQLAlchemy-0.4.6-py2.5.egg Searching for TurboGears==1.0.5 Best match: TurboGears 1.0.5 Processing TurboGears-1.0.5-py2.5.egg TurboGears 1.0.5 is already the active version in easy-install.pth Installing tg-admin script to /usr/bin Using /usr/lib/python2.5/site-packages/TurboGears-1.0.5-py2.5.egg Searching for TurboKid==1.0.4 Best match: TurboKid 1.0.4 Processing TurboKid-1.0.4-py2.5.egg TurboKid 1.0.4 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/TurboKid-1.0.4-py2.5.egg Searching for TurboJson==1.1.3 Best match: TurboJson 1.1.3 Processing TurboJson-1.1.3-py2.5.egg TurboJson 1.1.3 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/TurboJson-1.1.3-py2.5.egg Searching for TurboCheetah==1.0 Best match: TurboCheetah 1.0 Processing TurboCheetah-1.0-py2.5.egg TurboCheetah 1.0 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/TurboCheetah-1.0-py2.5.egg Searching for simplejson==1.9.1 Best match: simplejson 1.9.1 Processing simplejson-1.9.1-py2.5-linux-i686.egg simplejson 1.9.1 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/simplejson-1.9.1-py2.5-linux-i686.egg Searching for setuptools==0.6c8 Best match: setuptools 0.6c8 Processing setuptools-0.6c8-py2.5.egg Removing setuptools 0.6c8 from easy-install.pth file setuptools 0.6c8 is already the active version in easy-install.pth Installing easy_install script to /usr/bin Installing easy_install-2.5 script to /usr/bin Using /usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg Searching for RuleDispatch==0.5a0.dev-r2306 Best match: RuleDispatch 0.5a0.dev-r2306 Processing RuleDispatch-0.5a0.dev_r2306-py2.5-linux-i686.egg RuleDispatch 0.5a0.dev-r2306 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/RuleDispatch-0.5a0.dev_r2306-py2.5-linux-i686.egg Searching for PasteScript==1.6.3 Best match: PasteScript 1.6.3 Processing PasteScript-1.6.3-py2.5.egg PasteScript 1.6.3 is already the active version in easy-install.pth Installing paster script to /usr/bin Installing paster script to /usr/bin Using /usr/lib/python2.5/site-packages/PasteScript-1.6.3-py2.5.egg Searching for FormEncode==0.7.1 Best match: FormEncode 0.7.1 Adding FormEncode 0.7.1 to easy-install.pth file Using /usr/lib/python2.5/site-packages Searching for DecoratorTools==1.7 Best match: DecoratorTools 1.7 Processing DecoratorTools-1.7-py2.5.egg DecoratorTools 1.7 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/DecoratorTools-1.7-py2.5.egg Searching for configobj==4.5.2 Best match: configobj 4.5.2 Processing configobj-4.5.2-py2.5.egg configobj 4.5.2 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/configobj-4.5.2-py2.5.egg Searching for CherryPy==2.3.0 Best match: CherryPy 2.3.0 Processing CherryPy-2.3.0-py2.5.egg CherryPy 2.3.0 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/CherryPy-2.3.0-py2.5.egg Searching for kid==0.9.6 Best match: kid 0.9.6 Processing kid-0.9.6-py2.5.egg kid 0.9.6 is already the active version in easy-install.pth Installing kidc script to /usr/bin Installing kid script to /usr/bin Using /usr/lib/python2.5/site-packages/kid-0.9.6-py2.5.egg Searching for Cheetah==2.0.1 Best match: Cheetah 2.0.1 Processing Cheetah-2.0.1-py2.5-linux-i686.egg Cheetah 2.0.1 is already the active version in easy-install.pth Installing cheetah-compile script to /usr/bin Installing cheetah script to /usr/bin Using /usr/lib/python2.5/site-packages/Cheetah-2.0.1-py2.5-linux-i686.egg Searching for PyProtocols==1.0a0dev-r2302 Best match: PyProtocols 1.0a0dev-r2302 Processing PyProtocols-1.0a0dev_r2302-py2.5-linux-i686.egg PyProtocols 1.0a0dev-r2302 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/PyProtocols-1.0a0dev_r2302-py2.5-linux-i686.egg Searching for PasteDeploy==1.3.2 Best match: PasteDeploy 1.3.2 Processing PasteDeploy-1.3.2-py2.5.egg PasteDeploy 1.3.2 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/PasteDeploy-1.3.2-py2.5.egg Searching for Paste==1.7.1 Best match: Paste 1.7.1 Processing Paste-1.7.1-py2.5.egg Paste 1.7.1 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/Paste-1.7.1-py2.5.egg Finished processing dependencies for Animador==1.0a1 /usr/bin/python exited with code 0 -------------- next part -------------- Distribution.parse_config_files(): options (after parsing config files): no commands known yet options (after parsing command line): option dict for 'aliases' command: {} option dict for 'develop' command: {} running develop Distribution.get_command_obj(): creating 'develop' command object setting options for 'develop' command: Distribution.get_command_obj(): creating 'egg_info' command object Distribution.get_command_obj(): creating 'install' command object pre-finalize_{unix,other}: prefix: None exec_prefix: None home: None install_base: None install_platbase: None root: None install_purelib: None install_platlib: None install_lib: None install_headers: None install_scripts: None install_data: None compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None post-finalize_{unix,other}(): prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: $base/lib/python$py_version_short/site-packages install_platlib: $platbase/lib/python$py_version_short/site-packages install_lib: None install_headers: $base/include/python$py_version_short/$dist_name install_scripts: $base/bin install_data: $base compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None post-expand_basedirs(): prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: $base/lib/python$py_version_short/site-packages install_platlib: $platbase/lib/python$py_version_short/site-packages install_lib: None install_headers: $base/include/python$py_version_short/$dist_name install_scripts: $base/bin install_data: $base compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None config vars: {'base': '/usr', 'dist_fullname': 'Animador-1.0a1', 'dist_name': 'Animador', 'dist_version': '1.0a1', 'exec_prefix': '/usr', 'platbase': '/usr', 'prefix': '/usr', 'py_version': '2.5.2', 'py_version_short': '2.5', 'sys_exec_prefix': '/usr', 'sys_prefix': '/usr'} post-expand_dirs(): prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: /usr/lib/python2.5/site-packages install_platlib: /usr/lib/python2.5/site-packages install_lib: None install_headers: /usr/include/python2.5/Animador install_scripts: /usr/bin install_data: /usr compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None after prepending root: prefix: /usr exec_prefix: /usr home: None install_base: /usr install_platbase: /usr root: None install_purelib: /usr/lib/python2.5/site-packages install_platlib: /usr/lib/python2.5/site-packages install_lib: /usr/lib/python2.5/site-packages/ install_headers: /usr/include/python2.5/Animador install_scripts: /usr/bin install_data: /usr compile: None compile: True optimize: None force: None skip_build: 0 record: None old_and_unmanageable: None single_version_externally_managed: None Distribution.get_command_obj(): creating 'build' command object Distribution.get_command_obj(): creating 'install_lib' command object Distribution.get_command_obj(): creating 'install_scripts' command object running egg_info paster_plugins not set in setup(), but Animador.egg-info/paster_plugins.txt exists writing requirements to Animador.egg-info/requires.txt writing Animador.egg-info/PKG-INFO writing top-level names to Animador.egg-info/top_level.txt writing dependency_links to Animador.egg-info/dependency_links.txt writing entry points to Animador.egg-info/entry_points.txt Distribution.get_command_obj(): creating 'build_py' command object package init file 'locales/__init__.py' not found (or not a regular file) include_pattern: applying regex r'^Animador\.egg\-info/.*[^/]*$' adding Animador.egg-info/entry_points.txt adding Animador.egg-info/SOURCES.txt adding Animador.egg-info/dependency_links.txt adding Animador.egg-info/not-zip-safe adding Animador.egg-info/requires.txt adding Animador.egg-info/paster_plugins.txt adding Animador.egg-info/top_level.txt adding Animador.egg-info/PKG-INFO adding Animador.egg-info/.svn/all-wcprops adding Animador.egg-info/.svn/entries adding Animador.egg-info/.svn/format adding Animador.egg-info/.svn/text-base/requires.txt.svn-base adding Animador.egg-info/.svn/text-base/PKG-INFO.svn-base adding Animador.egg-info/.svn/text-base/not-zip-safe.svn-base adding Animador.egg-info/.svn/text-base/paster_plugins.txt.svn-base adding Animador.egg-info/.svn/text-base/SOURCES.txt.svn-base adding Animador.egg-info/.svn/text-base/dependency_links.txt.svn-base adding Animador.egg-info/.svn/text-base/entry_points.txt.svn-base adding Animador.egg-info/.svn/text-base/top_level.txt.svn-base exclude_pattern: applying regex r'^build/.*' exclude_pattern: applying regex r'^Animador\-1\.0a1/.*' exclude_pattern: applying regex r'\/(RCS|CVS|\.svn)\/' removing Animador.egg-info/.svn/text-base/top_level.txt.svn-base removing Animador.egg-info/.svn/text-base/entry_points.txt.svn-base removing Animador.egg-info/.svn/text-base/dependency_links.txt.svn-base removing Animador.egg-info/.svn/text-base/SOURCES.txt.svn-base removing Animador.egg-info/.svn/text-base/paster_plugins.txt.svn-base removing Animador.egg-info/.svn/text-base/not-zip-safe.svn-base removing Animador.egg-info/.svn/text-base/PKG-INFO.svn-base removing Animador.egg-info/.svn/text-base/requires.txt.svn-base removing Animador.egg-info/.svn/format removing Animador.egg-info/.svn/entries removing Animador.egg-info/.svn/all-wcprops writing manifest file 'Animador.egg-info/SOURCES.txt' Distribution.get_command_obj(): creating 'build_ext' command object running build_ext Creating /usr/lib/python2.5/site-packages/Animador.egg-link (link to .) Adding Animador 1.0a1 to easy-install.pth file Installing start-animador script to /usr/bin Installed /home/gustavo/GLM/Projects/Animador Processing dependencies for Animador==1.0a1 Searching for Elixir==0.5.2 Best match: Elixir 0.5.2 Processing Elixir-0.5.2-py2.5.egg Elixir 0.5.2 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/Elixir-0.5.2-py2.5.egg Searching for SQLAlchemy==0.4.6 Best match: SQLAlchemy 0.4.6 Processing SQLAlchemy-0.4.6-py2.5.egg SQLAlchemy 0.4.6 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/SQLAlchemy-0.4.6-py2.5.egg Searching for TurboGears==1.0.5 Best match: TurboGears 1.0.5 Processing TurboGears-1.0.5-py2.5.egg TurboGears 1.0.5 is already the active version in easy-install.pth Installing tg-admin script to /usr/bin Using /usr/lib/python2.5/site-packages/TurboGears-1.0.5-py2.5.egg Searching for TurboKid==1.0.4 Best match: TurboKid 1.0.4 Processing TurboKid-1.0.4-py2.5.egg TurboKid 1.0.4 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/TurboKid-1.0.4-py2.5.egg Searching for TurboJson==1.1.3 Best match: TurboJson 1.1.3 Processing TurboJson-1.1.3-py2.5.egg TurboJson 1.1.3 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/TurboJson-1.1.3-py2.5.egg Searching for TurboCheetah==1.0 Best match: TurboCheetah 1.0 Processing TurboCheetah-1.0-py2.5.egg TurboCheetah 1.0 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/TurboCheetah-1.0-py2.5.egg Searching for simplejson==1.9.1 Best match: simplejson 1.9.1 Processing simplejson-1.9.1-py2.5-linux-i686.egg simplejson 1.9.1 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/simplejson-1.9.1-py2.5-linux-i686.egg Searching for setuptools==0.6c8 Best match: setuptools 0.6c8 Processing setuptools-0.6c8-py2.5.egg Removing setuptools 0.6c8 from easy-install.pth file setuptools 0.6c8 is already the active version in easy-install.pth Installing easy_install script to /usr/bin Installing easy_install-2.5 script to /usr/bin Using /usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg Searching for RuleDispatch==0.5a0.dev-r2306 Best match: RuleDispatch 0.5a0.dev-r2306 Processing RuleDispatch-0.5a0.dev_r2306-py2.5-linux-i686.egg RuleDispatch 0.5a0.dev-r2306 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/RuleDispatch-0.5a0.dev_r2306-py2.5-linux-i686.egg Searching for PasteScript==1.6.3 Best match: PasteScript 1.6.3 Processing PasteScript-1.6.3-py2.5.egg PasteScript 1.6.3 is already the active version in easy-install.pth Installing paster script to /usr/bin Installing paster script to /usr/bin Using /usr/lib/python2.5/site-packages/PasteScript-1.6.3-py2.5.egg Searching for FormEncode==0.7.1 Best match: FormEncode 0.7.1 Adding FormEncode 0.7.1 to easy-install.pth file Using /usr/lib/python2.5/site-packages Searching for DecoratorTools==1.7 Best match: DecoratorTools 1.7 Processing DecoratorTools-1.7-py2.5.egg DecoratorTools 1.7 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/DecoratorTools-1.7-py2.5.egg Searching for configobj==4.5.2 Best match: configobj 4.5.2 Processing configobj-4.5.2-py2.5.egg configobj 4.5.2 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/configobj-4.5.2-py2.5.egg Searching for CherryPy==2.3.0 Best match: CherryPy 2.3.0 Processing CherryPy-2.3.0-py2.5.egg CherryPy 2.3.0 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/CherryPy-2.3.0-py2.5.egg Searching for kid==0.9.6 Best match: kid 0.9.6 Processing kid-0.9.6-py2.5.egg kid 0.9.6 is already the active version in easy-install.pth Installing kidc script to /usr/bin Installing kid script to /usr/bin Using /usr/lib/python2.5/site-packages/kid-0.9.6-py2.5.egg Searching for Cheetah==2.0.1 Best match: Cheetah 2.0.1 Processing Cheetah-2.0.1-py2.5-linux-i686.egg Cheetah 2.0.1 is already the active version in easy-install.pth Installing cheetah-compile script to /usr/bin Installing cheetah script to /usr/bin Using /usr/lib/python2.5/site-packages/Cheetah-2.0.1-py2.5-linux-i686.egg Searching for PyProtocols==1.0a0dev-r2302 Best match: PyProtocols 1.0a0dev-r2302 Processing PyProtocols-1.0a0dev_r2302-py2.5-linux-i686.egg PyProtocols 1.0a0dev-r2302 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/PyProtocols-1.0a0dev_r2302-py2.5-linux-i686.egg Searching for PasteDeploy==1.3.2 Best match: PasteDeploy 1.3.2 Processing PasteDeploy-1.3.2-py2.5.egg PasteDeploy 1.3.2 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/PasteDeploy-1.3.2-py2.5.egg Searching for Paste==1.7.1 Best match: Paste 1.7.1 Processing Paste-1.7.1-py2.5.egg Paste 1.7.1 is already the active version in easy-install.pth Using /usr/lib/python2.5/site-packages/Paste-1.7.1-py2.5.egg Finished processing dependencies for Animador==1.0a1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pje at telecommunity.com Sun Jul 20 18:48:43 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 20 Jul 2008 12:48:43 -0400 Subject: [Distutils] `develop' doesn't appends my package's directory to sys.path In-Reply-To: <200807201434.20227.gustavo@gnulinuxmatters.org> References: <200807182207.14846.gustavo@gnulinuxmatters.org> <200807191932.56942.gustavo@gnulinuxmatters.org> <20080719183509.E95743A407B@sparrow.telecommunity.com> <200807201434.20227.gustavo@gnulinuxmatters.org> Message-ID: <20080720165717.8EE963A406B@sparrow.telecommunity.com> At 02:34 PM 7/20/2008 +0200, Gustavo Narea wrote: >Hello, Phillip. > >On Saturday 19 July 2008 20:35:54 Phillip J. Eby wrote: > > It doesn't sound like you read what I wrote below, or that you did > > any of what I said to do, so I'm not sure what other help I can > > offer. > >I did do what you said, and sorry for not letting you know about the result I >got. > >The output is basically the same; the environment contents are exactly the >same (which you can verify, because the output is attached). The only thing >that changes is that with the build system I get > > Animador 1.0a1 is already the active version in easy-install.pth >while with `setup.py develop' I get > > Adding Animador 1.0a1 to easy-install.pth file I think you should probably dump the contents of your easy-install.pth file before and after running each one, so we can see what's happening there, exactly. >But that's the only difference. > >I found that if I remove "build", the test suite finally works, and therefore >I didn't try to understand what's the problem with setuptools' develop in my >script if the environment contents are the same as in `setup.py develop'. > > > (Also, your statements about "develop" and "build" are > > mutually inconsistent.) > >I don't understand why you think that. You said: """If I don't run "build" my script works. However I need "develop" because the Ant-like tool runs my test suite on a different folder for every svn revision. If I remove "build", I get an import error because my modules are not accessible.""" In other words, you said that you need develop because if you don't use build you get an error. But also that if you remove build it works. So, your statements are not such that I can make any kind of consistent sense of what is happening. Also, "build" should have zero effect on testing or installing, and "develop" should be unnecessary for testing, regardless of what directory your code is unpacked in. You should simply be able to run "setup.py test" and skip all this build and develop stuff, because the "test" command puts the code on sys.path while the tests are running, and it also executes any build steps that are necessary. >Regarding "develop", I had to include it in my script because otherwise my >packages' modules wouldn't be accessible - I got import errors when I didn't >use it. What import errors, specifically? From chris at simplistix.co.uk Tue Jul 22 16:24:49 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 22 Jul 2008 15:24:49 +0100 Subject: [Distutils] [zc.buildout] building a testrunner Message-ID: <4885EDB1.4010002@simplistix.co.uk> Hi All, I've just finished making one of my python libraries into something that setuptools is happy with: https://secure.simplistix.co.uk/svn/Simplistix/twiddler/trunk/ I'm trying to add a short buildout.cfg next to the setup.py so I can check this project out, run bootstrap.py, run buildout and then do: C:\LocalSVN\twiddler> bin\test ...to run the tests. Here's the buildout.cfg I currently have: [buildout] develop = . parts = test [test] recipe = zc.recipe.testrunner eggs = twiddler Now, if I do: C:\LocalSVN\twiddler> bin\test -m twiddler ...I get the results I'd expect. However, if I do: C:\LocalSVN\twiddler> bin\test I get the following unexpected output: Test-module import failures: Module: eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources ImportError: No module named eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.te st_resources Module: eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_packageindex ImportError: No module named eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.te st_packageindex Module: eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_resources ImportError: No module named eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.te st_resources Module: eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.tests ImportError: No module named eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.te sts Module: eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests ImportError: No module named eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests Module: eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.tests ImportError: No module named eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.te sts Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.common.tests.te st_idatetime ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.common.tests.test_idatetime Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.common.tests.te st_import_interfaces ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.common.tests.test_import_interfaces Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_adap ter ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_adapter Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_advi ce ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_advice Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_decl arations ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_declarations Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_docu ment ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_document Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_elem ent ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_element Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_inte rface ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_interface Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_odd_ declarations ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_odd_declarations Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_sort ing ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_sorting Module: eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_veri fy ImportError: No module named eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.inte rface.tests.test_verify Module: eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.tests ImportError: No module named eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.test s Module: eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.testrunner.tests ImportError: No module named eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.test runner.tests Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Test-modules with import problems: eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_packageindex eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_resources eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.tests eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.tests eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.common.tests.test_ida tetime eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.common.tests.test_imp ort_interfaces eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_adapter eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_advice eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_declaratio ns eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_document eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_element eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_interface eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_odd_declar ations eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_sorting eggs.zope.interface-3.4.1-py2.4-win32.egg.zope.interface.tests.test_verify eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.tests eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.testrunner.tests How come? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 22 17:05:56 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 22 Jul 2008 11:05:56 -0400 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <4885EDB1.4010002@simplistix.co.uk> References: <4885EDB1.4010002@simplistix.co.uk> Message-ID: <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> My guess is that you forgot to list lots of your dependencies in your setup.py file. Look at the generated test script. You should see all required eggs listed in the Python path. You might find it useful to also add an "interpreter" part: [buildout] parts = test py ... [py] recipe = zc.recipe.egg eggs = twidddler interpreter = py Then, after running the buildout, you'll be able to: bin/py and get a Python prompt with twiddler and it's dependencies in the Python path. This makes it easy play with your code. Jim On Jul 22, 2008, at 10:24 AM, Chris Withers wrote: > Hi All, > > I've just finished making one of my python libraries into something > that setuptools is happy with: > > https://secure.simplistix.co.uk/svn/Simplistix/twiddler/trunk/ > > I'm trying to add a short buildout.cfg next to the setup.py so I can > check this project out, run bootstrap.py, run buildout and then do: > > C:\LocalSVN\twiddler> bin\test > > ...to run the tests. > > Here's the buildout.cfg I currently have: > > [buildout] > develop = . > parts = test > > [test] > recipe = zc.recipe.testrunner > eggs = twiddler > > Now, if I do: > > C:\LocalSVN\twiddler> bin\test -m twiddler > > ...I get the results I'd expect. > > However, if I do: > > C:\LocalSVN\twiddler> bin\test > > I get the following unexpected output: > > Test-module import failures: > Module: eggs.setuptools-0.6c5- > py2.4.egg.setuptools.tests.test_resources > ImportError: No module named eggs.setuptools-0.6c5- > py2.4.egg.setuptools.tests.te > st_resources > Module: eggs.setuptools-0.6c8- > py2.4.egg.setuptools.tests.test_packageindex > ImportError: No module named eggs.setuptools-0.6c8- > py2.4.egg.setuptools.tests.te > st_packageindex > Module: eggs.setuptools-0.6c8- > py2.4.egg.setuptools.tests.test_resources > ImportError: No module named eggs.setuptools-0.6c8- > py2.4.egg.setuptools.tests.te > st_resources > Module: eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.tests > ImportError: No module named eggs.zc.buildout-1.0.7_dev- > py2.4.egg.zc.buildout.te > sts > Module: eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests > ImportError: No module named eggs.zc.buildout-1.1.0- > py2.4.egg.zc.buildout.tests > Module: eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.tests > ImportError: No module named eggs.zc.recipe.egg-1.1.0- > py2.4.egg.zc.recipe.egg.te > sts > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.common.tests.te > st_idatetime > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.common.tests.test_idatetime > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.common.tests.te > st_import_interfaces > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.common.tests.test_import_interfaces > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_adap > ter > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_adapter > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_advi > ce > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_advice > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_decl > arations > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_declarations > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_docu > ment > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_document > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_elem > ent > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_element > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_inte > rface > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_interface > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_odd_ > declarations > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_odd_declarations > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_sort > ing > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_sorting > Module: eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_veri > fy > ImportError: No module named eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.inte > rface.tests.test_verify > Module: eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.tests > ImportError: No module named eggs.zope.testing-3.6.0- > py2.4.egg.zope.testing.test > s > Module: eggs.zope.testing-3.6.0- > py2.4.egg.zope.testing.testrunner.tests > ImportError: No module named eggs.zope.testing-3.6.0- > py2.4.egg.zope.testing.test > runner.tests > Running zope.testing.testrunner.layer.UnitTests tests: > Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. > > Test-modules with import problems: > eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources > eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_packageindex > eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_resources > eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.tests > eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests > eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.tests > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.common.tests.test_ida > tetime > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.common.tests.test_imp > ort_interfaces > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_adapter > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_advice > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_declaratio > ns > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_document > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_element > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_interface > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_odd_declar > ations > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_sorting > eggs.zope.interface-3.4.1-py2.4- > win32.egg.zope.interface.tests.test_verify > eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.tests > eggs.zope.testing-3.6.0-py2.4.egg.zope.testing.testrunner.tests > > How come? > > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Tue Jul 22 17:10:39 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 22 Jul 2008 16:10:39 +0100 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> References: <4885EDB1.4010002@simplistix.co.uk> <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> Message-ID: <4885F86F.4040402@simplistix.co.uk> Jim Fulton wrote: > My guess is that you forgot to list lots of your dependencies in your > setup.py file. I don't think so, twiddler only has dependencies on elementtree and zope.interface and these are both listed. > Look at the generated test script. You should see all required eggs > listed in the Python path. Yep, I do. >> Test-module import failures: >> Module: eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources >> ImportError: No module named >> eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.te >> st_resources Okay, taking just this first one: - why is the script trying to run setuptools' tests? - why is it failing? Both of these questions could also be applied just as equally to zc.buildout, zc.egg.recipe, zope.interface and zope.testing. >> Test-modules with import problems: >> eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources >> eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_packageindex >> eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_resources >> eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.tests >> eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests >> eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.tests It looks like the testrunner might be trying to find tests in the egg cache? Why would it do that? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Tue Jul 22 17:28:00 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 22 Jul 2008 11:28:00 -0400 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <4885F86F.4040402@simplistix.co.uk> References: <4885EDB1.4010002@simplistix.co.uk> <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> <4885F86F.4040402@simplistix.co.uk> Message-ID: <52C6347F-BF98-4FAC-BF5B-F6133D8AC6BE@zope.com> On Jul 22, 2008, at 11:10 AM, Chris Withers wrote: ... >>> Test-module import failures: >>> Module: eggs.setuptools-0.6c5- >>> py2.4.egg.setuptools.tests.test_resources >>> ImportError: No module named eggs.setuptools-0.6c5- >>> py2.4.egg.setuptools.tests.te >>> st_resources > > Okay, taking just this first one: > > - why is the script trying to run setuptools' tests? Ah, I totally miss-read your error messages. Sorry. I have no idea. > - why is it failing? well, eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources is not a valid module name. I have no idea were it is getting this module name. > Both of these questions could also be applied just as equally to > zc.buildout, zc.egg.recipe, zope.interface and zope.testing. Yup >>> Test-modules with import problems: >>> eggs.setuptools-0.6c5-py2.4.egg.setuptools.tests.test_resources >>> eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_packageindex >>> eggs.setuptools-0.6c8-py2.4.egg.setuptools.tests.test_resources >>> eggs.zc.buildout-1.0.7_dev-py2.4.egg.zc.buildout.tests >>> eggs.zc.buildout-1.1.0-py2.4.egg.zc.buildout.tests >>> eggs.zc.recipe.egg-1.1.0-py2.4.egg.zc.recipe.egg.tests > Note, again, that these are not valid module names. I have no idea where the test runner is getting these. > It looks like the testrunner might be trying to find tests in the > egg cache? Those aren't valid module names, so I have no idea what it's doing. > Why would it do that? Don't know. Must be a windows thing. ;) I tried your buildout -- even on windows :) -- at it worked fine for me. The test ran find (with a test failure). I suggest making sure your Python is clean. Jim -- Jim Fulton Zope Corporation From ziade.tarek at gmail.com Wed Jul 23 15:34:08 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 23 Jul 2008 15:34:08 +0200 Subject: [Distutils] zc.buildout poll Message-ID: <94bdd2610807230634n6f5aa1e9i55d32fe918b735f6@mail.gmail.com> Hi, I have an OSCON talk tomorrow about zc.buildout and I am trying to see if it's used outside the Zope community, for public projects I can show as examples on a slide If you do so, please let me know ! Tarek -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arlo.belshee at Bluevolt.com Thu Jul 24 19:30:25 2008 From: arlo.belshee at Bluevolt.com (Arlo Belshee) Date: Thu, 24 Jul 2008 10:30:25 -0700 Subject: [Distutils] A release to at least stop crashing on Subversion 1.5 would be nice Message-ID: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local> In command/sdist.py, line 90 refers to a global log function which does not exist. Thus, instead of logging a warning about not understanding Subversion, setuptools crashes. The default setup scripts for Pylons (and probably others) use svn revision tagging. Thus, the following causes a crash: easy_install Pylons paster create -t Pylons proj setup.py develop And, since the user hasn't done any config (or anything but follow a tutorial), he isn't able to easily figure out what went wrong. Also, since setuptools was likely installed automatically for him via the egg in the cheeseshop, he isn't aware of anything that may be in dev for setuptools. A new user's likely response is to get frustrated for 15 minutes, then move on to another web framework / language. Even if you don't provide svn 1.5 support, can you at least post an egg that won't crash in the presence of svn 1.5? Thanks. Arlo From kiorky at cryptelium.net Thu Jul 24 19:59:11 2008 From: kiorky at cryptelium.net (kiorky) Date: Thu, 24 Jul 2008 19:59:11 +0200 Subject: [Distutils] A release to at least stop crashing on Subversion 1.5 would be nice In-Reply-To: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local> References: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local> Message-ID: <4888C2EF.1030707@cryptelium.net> Arlo Belshee a ?crit : > In command/sdist.py, line 90 refers to a global log function which does not exist. Thus, instead of logging a warning about not understanding Subversion, setuptools crashes. > > The default setup scripts for Pylons (and probably others) use svn revision tagging. Thus, the following causes a crash: > > easy_install Pylons > paster create -t Pylons proj > setup.py develop > > And, since the user hasn't done any config (or anything but follow a tutorial), he isn't able to easily figure out what went wrong. Also, since setuptools was likely installed automatically for him via the egg in the cheeseshop, he isn't aware of anything that may be in dev for setuptools. A new user's likely response is to get frustrated for 15 minutes, then move on to another web framework / language. > > Even if you don't provide svn 1.5 support, can you at least post an egg that won't crash in the presence of svn 1.5? > > Thanks. > > Arlo > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig You can easy_install -U "setuptools == dev" It is fixed on trunk as far as i know. -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From kiorky at cryptelium.net Thu Jul 24 20:00:31 2008 From: kiorky at cryptelium.net (kiorky) Date: Thu, 24 Jul 2008 20:00:31 +0200 Subject: [Distutils] zc.buildout poll In-Reply-To: <94bdd2610807230634n6f5aa1e9i55d32fe918b735f6@mail.gmail.com> References: <94bdd2610807230634n6f5aa1e9i55d32fe918b735f6@mail.gmail.com> Message-ID: <4888C33F.10508@cryptelium.net> Tarek Ziad? a ?crit : > Hi, > > I have an OSCON talk tomorrow about zc.buildout and I am trying to see > if it's used outside the Zope community, for public > projects I can show as examples on a slide > > If you do so, please let me know ! > > Tarek > > -- > Tarek Ziad? | Association AfPy | www.afpy.org > Blog FR | http://programmation-python.org > Blog EN | http://tarekziade.wordpress.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig We use it for some turbogears and django projects there. -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From chris at simplistix.co.uk Thu Jul 24 20:58:30 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 24 Jul 2008 19:58:30 +0100 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <52C6347F-BF98-4FAC-BF5B-F6133D8AC6BE@zope.com> References: <4885EDB1.4010002@simplistix.co.uk> <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> <4885F86F.4040402@simplistix.co.uk> <52C6347F-BF98-4FAC-BF5B-F6133D8AC6BE@zope.com> Message-ID: <4888D0D6.1080105@simplistix.co.uk> Jim Fulton wrote: > > Don't know. Must be a windows thing. ;) > > I tried your buildout -- even on windows :) -- at it worked fine for me. > The test ran find (with a test failure). I suggest making sure your > Python is clean. Well, I just tried this on linux on both python2.4 and python2.5, source built pythons and got very similar results to those on windows. (with the testrunner tripping up on stuff in the egg cache) In all cases, the egg versions picked were as follows: zc.buildout 1.1.0 setuptools 0.6c8 zc.recipe.testrunner 1.0.0 zc.recipe.egg 1.1.0 zope.testing 3.6.0 zope.interface 3.4.1 elementtree 1.2.7-20070827-preview Do these match the versions you're using? I've attached the full output from when I'd just completed the svn checkout on trunk through running tests with both versions of python in case you can spot anything "different". I've also attached the bin/test script. It'd be interesting to know if this differs from yours. The only other thing I can think of: do you maybe have "default user config files" living in ~ that are influencing zope.testing or zc.recipe.testrunner in some way? cheers, Chris PS: The buildout.cfg I'm now using is also checked in and the svn path is https://secure.simplistix.co.uk/svn/Simplistix/twiddler/trunk -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unix.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test URL: From chris at simplistix.co.uk Thu Jul 24 21:40:51 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 24 Jul 2008 20:40:51 +0100 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? Message-ID: <4888DAC3.4070001@simplistix.co.uk> Hi All, I was to check how my long_description will show on pypi before I upload the egg. What's the best way do this? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From pje at telecommunity.com Thu Jul 24 22:18:53 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 24 Jul 2008 16:18:53 -0400 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <4888DAC3.4070001@simplistix.co.uk> References: <4888DAC3.4070001@simplistix.co.uk> Message-ID: <20080724201805.DB55C3A406B@sparrow.telecommunity.com> At 08:40 PM 7/24/2008 +0100, Chris Withers wrote: >Hi All, > >I was to check how my long_description will show on pypi before I >upload the egg. > >What's the best way do this? Use "setup.py register", then view the page on PyPI. Repeat until working. :) From tseaver at palladion.com Thu Jul 24 22:21:12 2008 From: tseaver at palladion.com (Tres Seaver) Date: Thu, 24 Jul 2008 16:21:12 -0400 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <4888DAC3.4070001@simplistix.co.uk> References: <4888DAC3.4070001@simplistix.co.uk> Message-ID: <4888E438.3020200@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote: > Hi All, > > I was to check how my long_description will show on pypi before I upload > the egg. > > What's the best way do this? How about the following? $ python setup.py --long-description | rst2html > long_desc.html Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiOQ4+gerLs4ltQ4RAmvfAJ9aJKJatra0nX9X/S+zPa9ruGhjRQCeNSA0 9OdQNVGVS/v36qDph+3nCVQ= =v4zb -----END PGP SIGNATURE----- From marius at pov.lt Thu Jul 24 22:29:19 2008 From: marius at pov.lt (Marius Gedminas) Date: Thu, 24 Jul 2008 23:29:19 +0300 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <4888D0D6.1080105@simplistix.co.uk> References: <4885EDB1.4010002@simplistix.co.uk> <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> <4885F86F.4040402@simplistix.co.uk> <52C6347F-BF98-4FAC-BF5B-F6133D8AC6BE@zope.com> <4888D0D6.1080105@simplistix.co.uk> Message-ID: <20080724202919.GA7696@fridge.pov.lt> On Thu, Jul 24, 2008 at 07:58:30PM +0100, Chris Withers wrote: > Jim Fulton wrote: > > > >Don't know. Must be a windows thing. ;) > > > >I tried your buildout -- even on windows :) -- at it worked fine for me. > >The test ran find (with a test failure). I suggest making sure your > >Python is clean. > > Well, I just tried this on linux on both python2.4 and python2.5, source > built pythons and got very similar results to those on windows. > (with the testrunner tripping up on stuff in the egg cache) What does your buildout.cfg look like? > PS: The buildout.cfg I'm now using is also checked in and the svn path > is https://secure.simplistix.co.uk/svn/Simplistix/twiddler/trunk Ah, I see you anticipated my question. > I've also attached the bin/test script. It'd be interesting to know if > this differs from yours. And here it is: > #!/usr/local/bin/python2.4 > > import sys > sys.path[0:0] = [ > '/home/chris/twiddler', > '/home/chris/twiddler/eggs/zope.testing-3.6.0-py2.4.egg', > '/home/chris/twiddler/eggs/zope.interface-3.4.1-py2.4-linux-i686.egg', > '/home/chris/twiddler/eggs/setuptools-0.6c8-py2.4.egg', > '/home/chris/twiddler/eggs/elementtree-1.2.7_20070827_preview-py2.4.egg', > ] > > import os > sys.argv[0] = os.path.abspath(sys.argv[0]) > os.chdir('/home/chris/twiddler/parts/test') > > > import zope.testing.testrunner > > if __name__ == '__main__': > zope.testing.testrunner.run([ > '--test-path', '/home/chris/twiddler', This is Not Good. You don't want the test runner to look for tests under /home/chris/twiddler/, which contains the egg cache directly under it, as well as your Python packages. People who use an intermediate 'src/' subdir do not get the problem you stumbled upon. I think an intermediate directory is a Very Good Idea, because: * you want to be able to import 'twiddler', which means /home/chris/twiddler/ must be in you sys.path * you don't want setup.py or bootstrap.py to be in your sys.path, which contradicts the above requirement OTOH if you want to keep your current package layout, you need to convince zc.recipe.testrunner to use a different --test-path (specifically, '/home/chris/twiddler/twiddler'). I've no idea how to achieve this. I'd choose the other solution (insert a src/ subdir into my tree, above the twiddler subdir). > ]) > The only other thing I can think of: do you maybe have "default user > config files" living in ~ that are influencing zope.testing or > zc.recipe.testrunner in some way? You can override the egg cache location in a dotfile in your home. Power users do that to avoid downloading the same eggs over and over again for each project they're working on. HTH, Marius Gedminas -- Most security experts REALLY believe in firewalls. The expect that, when they die, arrive at the great firewall in the sky where Saint Peter is running a default policy of REJECT. --- Sander Plomp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From chris at simplistix.co.uk Thu Jul 24 23:23:19 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 24 Jul 2008 22:23:19 +0100 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <20080724201805.DB55C3A406B@sparrow.telecommunity.com> References: <4888DAC3.4070001@simplistix.co.uk> <20080724201805.DB55C3A406B@sparrow.telecommunity.com> Message-ID: <4888F2C7.7010107@simplistix.co.uk> Phillip J. Eby wrote: > At 08:40 PM 7/24/2008 +0100, Chris Withers wrote: >> Hi All, >> >> I was to check how my long_description will show on pypi before I >> upload the egg. >> >> What's the best way do this? > > Use "setup.py register", then view the page on PyPI. Repeat until > working. :) Wow, is that really the best you can offer? :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Thu Jul 24 23:33:31 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 24 Jul 2008 22:33:31 +0100 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <20080724202919.GA7696@fridge.pov.lt> References: <4885EDB1.4010002@simplistix.co.uk> <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> <4885F86F.4040402@simplistix.co.uk> <52C6347F-BF98-4FAC-BF5B-F6133D8AC6BE@zope.com> <4888D0D6.1080105@simplistix.co.uk> <20080724202919.GA7696@fridge.pov.lt> Message-ID: <4888F52B.2070402@simplistix.co.uk> Marius Gedminas wrote: >> if __name__ == '__main__': >> zope.testing.testrunner.run([ >> '--test-path', '/home/chris/twiddler', > > This is Not Good. Right, although Jim said he tried this with the same buildout.cfg and didn't experience the problem. I'd love to know what caused that different behaviour... > You don't want the test runner to look for tests > under /home/chris/twiddler/, which contains the egg cache directly under > it, as well as your Python packages. But these module names don't match any test pattern so why would they be found? > People who use an intermediate 'src/' subdir do not get the problem you > stumbled upon. I think an intermediate directory is a Very Good Idea, > because: I don't. I hate intermediate directories. I actually hate not being able to just put setup.py and buildout.py in the twiddler package and distributing one zipped up folder, however I gave up trying to bash distutils to do this... > * you want to be able to import 'twiddler', which means > /home/chris/twiddler/ must be in you sys.path Right. > * you don't want setup.py or bootstrap.py to be in your sys.path, which > contradicts the above requirement Why don't I want them in my sys.path? > OTOH if you want to keep your current package layout, you need to > convince zc.recipe.testrunner to use a different --test-path > (specifically, '/home/chris/twiddler/twiddler'). I've no idea how to > achieve this. I'd choose the other solution (insert a src/ subdir into > my tree, above the twiddler subdir). I'm not sure I quite by this, I don't understand why zope.testing is trying to import something like: eggs.zc.buildout-1.1.0-py2.5.egg.zc.buildout.tests >> The only other thing I can think of: do you maybe have "default user >> config files" living in ~ that are influencing zope.testing or >> zc.recipe.testrunner in some way? > > You can override the egg cache location in a dotfile in your home. > Power users do that to avoid downloading the same eggs over and over > again for each project they're working on. That sounds like a good idea, but I'd prefer to solve this problem for anyone who might want to develop packages of mine. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Thu Jul 24 23:37:46 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 24 Jul 2008 22:37:46 +0100 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <4888E438.3020200@palladion.com> References: <4888DAC3.4070001@simplistix.co.uk> <4888E438.3020200@palladion.com> Message-ID: <4888F62A.70504@simplistix.co.uk> Tres Seaver wrote: > How about the following? > > $ python setup.py --long-description | rst2html > long_desc.html Where does rst2html come from? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From ziade.tarek at gmail.com Thu Jul 24 23:51:31 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 24 Jul 2008 23:51:31 +0200 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <4888F62A.70504@simplistix.co.uk> References: <4888DAC3.4070001@simplistix.co.uk> <4888E438.3020200@palladion.com> <4888F62A.70504@simplistix.co.uk> Message-ID: <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> On Thu, Jul 24, 2008 at 11:37 PM, Chris Withers wrote: > Tres Seaver wrote: > >> How about the following? >> >> $ python setup.py --long-description | rst2html > long_desc.html >> > > Where does rst2html come from? $ easy_install docutils on my laptop the script is "rst2html.py" though > > > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Fri Jul 25 00:07:38 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 24 Jul 2008 18:07:38 -0400 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <4888F2C7.7010107@simplistix.co.uk> References: <4888DAC3.4070001@simplistix.co.uk> <20080724201805.DB55C3A406B@sparrow.telecommunity.com> <4888F2C7.7010107@simplistix.co.uk> Message-ID: <20080724220653.DF5C23A406B@sparrow.telecommunity.com> At 10:23 PM 7/24/2008 +0100, Chris Withers wrote: >Phillip J. Eby wrote: >>At 08:40 PM 7/24/2008 +0100, Chris Withers wrote: >>>Hi All, >>> >>>I was to check how my long_description will show on pypi before I >>>upload the egg. >>> >>>What's the best way do this? >>Use "setup.py register", then view the page on PyPI. Repeat until >>working. :) > >Wow, is that really the best you can offer? :-( It's what I use, personally. In fact, I don't even bother with that most of the time; I just check the PyPI page after uploading and then re-run "register" if I don't like it. :) Of course, I also use "wikiup" to update my rst-based wiki pages, and usually at least one of those is being updated from my README so I already know the reST is valid... From chris at simplistix.co.uk Fri Jul 25 00:21:25 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 24 Jul 2008 23:21:25 +0100 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> References: <4888DAC3.4070001@simplistix.co.uk> <4888E438.3020200@palladion.com> <4888F62A.70504@simplistix.co.uk> <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> Message-ID: <48890065.9080705@simplistix.co.uk> Tarek Ziad? wrote: > > > On Thu, Jul 24, 2008 at 11:37 PM, Chris Withers > wrote: > > Tres Seaver wrote: > > How about the following? > > $ python setup.py --long-description | rst2html > long_desc.html > > > Where does rst2html come from? > > > $ easy_install docutils > > on my laptop the script is "rst2html.py" though Indeed, and the following seems to give a close-enough approximation of what will show on PyPI: bin/buildout -q setup setup.py --long-description | rst2html.py --link-stylesheet --stylesheet=http://www.python.org/styles/styles.css > dist/desc.html cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From marius at pov.lt Fri Jul 25 11:49:05 2008 From: marius at pov.lt (Marius Gedminas) Date: Fri, 25 Jul 2008 12:49:05 +0300 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> References: <4888DAC3.4070001@simplistix.co.uk> <4888E438.3020200@palladion.com> <4888F62A.70504@simplistix.co.uk> <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> Message-ID: <20080725094905.GA18997@fridge.pov.lt> On Thu, Jul 24, 2008 at 11:51:31PM +0200, Tarek Ziad? wrote: > On Thu, Jul 24, 2008 at 11:37 PM, Chris Withers > wrote: > > > Tres Seaver wrote: > > > >> How about the following? > >> > >> $ python setup.py --long-description | rst2html > long_desc.html > > > > Where does rst2html come from? > > $ easy_install docutils > > on my laptop the script is "rst2html.py" though If you have the ReST text in a separate file, you may find restview useful (http://mg.pov.lt/restview/; easy_install restview). Marius Gedminas -- Unix for stability; Macs for productivity; Palm for mobility; Windows for Solitaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From marius at pov.lt Fri Jul 25 12:02:54 2008 From: marius at pov.lt (Marius Gedminas) Date: Fri, 25 Jul 2008 13:02:54 +0300 Subject: [Distutils] [zc.buildout] building a testrunner In-Reply-To: <4888F52B.2070402@simplistix.co.uk> References: <4888D0D6.1080105@simplistix.co.uk> <20080724202919.GA7696@fridge.pov.lt> <4888F52B.2070402@simplistix.co.uk> <4885EDB1.4010002@simplistix.co.uk> <02126F48-3CFE-4965-8F87-A7A40FF62ABA@zope.com> <4885F86F.4040402@simplistix.co.uk> <52C6347F-BF98-4FAC-BF5B-F6133D8AC6BE@zope.com> <4888D0D6.1080105@simplistix.co.uk> <20080724202919.GA7696@fridge.pov.lt> Message-ID: <20080725100254.GB18997@fridge.pov.lt> Context: Test runner gets confused by the egg cache that lives under its --test-path. On Thu, Jul 24, 2008 at 05:14:33PM -0400, Jim Fulton wrote: > Arguably, the test runner recipe should be able to deal with this > case. I view this as a bug. It would be great if someone reported > it. :) I'll report it. On Thu, Jul 24, 2008 at 10:33:31PM +0100, Chris Withers wrote: > Marius Gedminas wrote: > >>if __name__ == '__main__': > >> zope.testing.testrunner.run([ > >> '--test-path', '/home/chris/twiddler', > > >You don't want the test runner to look for tests > >under /home/chris/twiddler/, which contains the egg cache directly under > >it, as well as your Python packages. > > But these module names don't match any test pattern so why would they be > found? Because they contain submodules that do match the test pattern, IIUC. > >* you want to be able to import 'twiddler', which means > > /home/chris/twiddler/ must be in you sys.path > > Right. > > >* you don't want setup.py or bootstrap.py to be in your sys.path, which > > contradicts the above requirement > > Why don't I want them in my sys.path? Uh, because otherwise my argument breaks down completely. ;-) I suppose it's a matter of purity. I feel about extra files lying on my sys.path about the same as I feel about ending statements with semicolons in Python. > I'm not sure I quite by this, I don't understand why zope.testing is > trying to import something like: > > eggs.zc.buildout-1.1.0-py2.5.egg.zc.buildout.tests It found a directory named 'tests' under eggs/zc.buildout-1.1.0-py2.5.egg/zc/buildout/tests and naively converted the slashes to periods, assuming that the root of the search three (i.e. the path passed with --test-path) is on your $PYTHONPATH. I agree that this is a bug. It can be fixed by: - not recursing into subdirectories with names that are invalid Python module names - not recursing into subdirectories that don't have a __init__ (and eggs/ certainly doesn't, I hope) > That sounds like a good idea, but I'd prefer to solve this problem for > anyone who might want to develop packages of mine. Agreed. Bug filed as https://bugs.launchpad.net/zope.testing/+bug/251759 Marius Gedminas -- The memory management on the PowerPC can be used to frighten small children. -- Linus Torvalds -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From chris at simplistix.co.uk Fri Jul 25 18:20:11 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 25 Jul 2008 17:20:11 +0100 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <20080725094905.GA18997@fridge.pov.lt> References: <4888DAC3.4070001@simplistix.co.uk> <4888E438.3020200@palladion.com> <4888F62A.70504@simplistix.co.uk> <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> <20080725094905.GA18997@fridge.pov.lt> Message-ID: <4889FD3B.4050408@simplistix.co.uk> Marius Gedminas wrote: > If you have the ReST text in a separate file, you may find restview > useful (http://mg.pov.lt/restview/; easy_install restview). Is there any way I can get this to use the CSS from PyPI? My hack with rst2html does a half-decent job of using PyPI's css... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From marius at pov.lt Sat Jul 26 13:29:16 2008 From: marius at pov.lt (Marius Gedminas) Date: Sat, 26 Jul 2008 14:29:16 +0300 Subject: [Distutils] how to get pypi-equivalent rendering of long_description? In-Reply-To: <4889FD3B.4050408@simplistix.co.uk> References: <4888DAC3.4070001@simplistix.co.uk> <4888E438.3020200@palladion.com> <4888F62A.70504@simplistix.co.uk> <94bdd2610807241451r66cd1dcdja0a7f0a33ef6479f@mail.gmail.com> <20080725094905.GA18997@fridge.pov.lt> <4889FD3B.4050408@simplistix.co.uk> Message-ID: <20080726112916.GA5405@fridge.pov.lt> On Fri, Jul 25, 2008 at 05:20:11PM +0100, Chris Withers wrote: > Marius Gedminas wrote: > >If you have the ReST text in a separate file, you may find restview > >useful (http://mg.pov.lt/restview/; easy_install restview). > > Is there any way I can get this to use the CSS from PyPI? Hm. PyPI uses three or four stylesheets at once, and then puts the rendered document inside a couple of divs with classes. You can get some sort of an approximation with restview *.rst --css http://www.python.org/styles/screen-switcher-default.css if you upgrade to restview 1.0.1 that I just released. > My hack with rst2html does a half-decent job of using PyPI's css... If it suits you, great. I was unsatisfied by rst2html because that introduces an extra step in my editing workflow: * save .rst file in text editor * run rst2html on it * reload page in web browser (Plus, the default CSS wasn't shiny enough for me.) Marius Gedminas -- Change is inevitable, except from a vending machine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From setuptools at bugs.python.org Mon Jul 28 03:29:24 2008 From: setuptools at bugs.python.org (Ian Bicking) Date: Mon, 28 Jul 2008 01:29:24 +0000 Subject: [Distutils] [issue28] Error message is confusing if you accidentally try to instal a directory In-Reply-To: <1217208564.76.0.661406409415.issue28@psf.upfronthosting.co.za> Message-ID: <1217208564.76.0.661406409415.issue28@psf.upfronthosting.co.za> New submission from Ian Bicking : I commonly encounter a problem where a person creates a directory with a name, then tries to install a package with the same name as the directory. easy_install then things they were referring to the directory name. For instance: $ mkdir Pylons $ mkdir Pylons/src/MyProject # etc... $ easy_install Pylons Processing Pylons error: couldn't find a setup script in Pylons I think the error message could just be changed, first to make sure the directory ends with os.path.sep and then saying "error: couldn't find a setup script in the directory Pylons/" -- with that error message most people would figure out the problem quickly. ---------- messages: 63 nosy: ianb at colorstudy.com priority: bug status: unread title: Error message is confusing if you accidentally try to instal a directory _______________________________________________ Setuptools tracker _______________________________________________ From d.w.morriss at gmail.com Mon Jul 28 17:28:40 2008 From: d.w.morriss at gmail.com (whit morriss) Date: Mon, 28 Jul 2008 10:28:40 -0500 Subject: [Distutils] buildout directory computation change Message-ID: it looks like something changes in how some vars (ie buildout:egg-directory) gets computed between 1.0.2 and 1.1.0 OSError: [Errno 2] No such file or directory: '/Users/whit/dev/geo/alm3//Users/whit/dev/geo/alm3/develop-eggs' is the resulting error for: eggs-directory = ${buildout:directory}/develop-eggs instead of: '/Users/whit/dev/geo/alm3/develop-eggs' (which I believe works until at least 1.0.2) buildout seems to implicitly assume I want buildout:directory appended. is this a feature, bug, or something I can turn off? -w From d.w.morriss at gmail.com Mon Jul 28 17:42:47 2008 From: d.w.morriss at gmail.com (whit morriss) Date: Mon, 28 Jul 2008 10:42:47 -0500 Subject: [Distutils] upgrading buildout Message-ID: I'm perhaps running buildout in a bit of unusual fashion (from my virtual env bin rather than the builds bin) and updated it recently from 1.0.2 to 1.1.0 to debug some issue folks were having with fresh checkouts of one of my builds (see previous message). I was suprised when all my zc.recipe.cmmi deps were recompiled. not a huge deal due to the unusual circumstances, but seemed avoidable. I realize my upgrade is dependent on my virtualenv setup and was wondering if there is some standard way to upgrade a build's buildout version while avoiding unnecessary rebuilding. -w From jim at zope.com Mon Jul 28 17:57:56 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 28 Jul 2008 11:57:56 -0400 Subject: [Distutils] upgrading buildout In-Reply-To: References: Message-ID: <6C908CF9-D905-4B99-8162-4A84E762BD3A@zope.com> On Jul 28, 2008, at 11:42 AM, whit morriss wrote: > I'm perhaps running buildout in a bit of unusual fashion (from my > virtual env bin rather than the builds bin) and updated it recently > from 1.0.2 to 1.1.0 to debug some issue folks were having with fresh > checkouts of one of my builds (see previous message). > > I was suprised when all my zc.recipe.cmmi deps were recompiled. not > a huge deal due to the unusual circumstances, but seemed avoidable. > > I realize my upgrade is dependent on my virtualenv setup and was > wondering if there is some standard way to upgrade a build's > buildout version while avoiding unnecessary rebuilding. Buildout is very conservative about rebuilding things -- erring on the side of rebuilding. IOW, if in doubt, builout will rebuild a part. When you upgrade buildout, it's possible that a change in buildout will affect how a part is built, so upgrading generally results on parts being rebuilt. There isn't currently a way to prevent this. Jim -- Jim Fulton Zope Corporation From jim at zope.com Mon Jul 28 18:03:23 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 28 Jul 2008 12:03:23 -0400 Subject: [Distutils] buildout directory computation change In-Reply-To: References: Message-ID: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> On Jul 28, 2008, at 11:28 AM, whit morriss wrote: > it looks like something changes in how some vars (ie buildout:egg- > directory) gets computed between 1.0.2 and 1.1.0 > > OSError: [Errno 2] No such file or directory: '/Users/whit/dev/geo/ > alm3//Users/whit/dev/geo/alm3/develop-eggs' > > is the resulting error for: > > eggs-directory = ${buildout:directory}/develop-eggs > > instead of: > > '/Users/whit/dev/geo/alm3/develop-eggs' > > (which I believe works until at least 1.0.2) > > buildout seems to implicitly assume I want buildout:directory > appended. is this a feature, bug, or something I can turn off? The way buildout normalizes buildout paths did change in 1.1.0. I haven't seen this error and can't see, in the code, while this error would occur. Can you provide a buildout I can use to reproduce this problem? Jim -- Jim Fulton Zope Corporation From kiorky at cryptelium.net Mon Jul 28 19:14:52 2008 From: kiorky at cryptelium.net (kiorky) Date: Mon, 28 Jul 2008 19:14:52 +0200 Subject: [Distutils] buildout directory computation change In-Reply-To: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> References: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> Message-ID: <488DFE8C.2000902@cryptelium.net> Jim Fulton a ?crit : > > On Jul 28, 2008, at 11:28 AM, whit morriss wrote: > >> it looks like something changes in how some vars (ie >> buildout:egg-directory) gets computed between 1.0.2 and 1.1.0 >> >> OSError: [Errno 2] No such file or directory: >> '/Users/whit/dev/geo/alm3//Users/whit/dev/geo/alm3/develop-eggs' >> >> is the resulting error for: >> >> eggs-directory = ${buildout:directory}/develop-eggs >> >> instead of: >> >> '/Users/whit/dev/geo/alm3/develop-eggs' >> >> (which I believe works until at least 1.0.2) >> >> buildout seems to implicitly assume I want buildout:directory >> appended. is this a feature, bug, or something I can turn off? > > > The way buildout normalizes buildout paths did change in 1.1.0. I > haven't seen this error and can't see, in the code, while this error > would occur. > > Can you provide a buildout I can use to reproduce this problem? > > Jim > > -- > Jim Fulton > Zope Corporation > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig I saw this problem which broke minitage too a week ago. Jim, you can see all the buildouts in there : http://trac.minitage.org/trac/browser like:http://trac.minitage.org/trac/browser/minitage/buildouts/dependencies/bzip2-1.0.4/buildout.cfg. They will all fail with zc.buildout >= 1.1 What fails there : eggs-directory and develop-directory will compute both to: buildoutdir/buildoutdir/../../eggs/*cache instead of : buildoutdir/../../eggs/*cache I work arounded them with a relative path. In zc/buildout/buildout.py, at l.135 , you assume buildout path is a prefix for all directories which causes this problem. -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jim at zope.com Mon Jul 28 19:28:29 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 28 Jul 2008 13:28:29 -0400 Subject: [Distutils] buildout directory computation change In-Reply-To: <488DFE8C.2000902@cryptelium.net> References: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> <488DFE8C.2000902@cryptelium.net> Message-ID: <83C2EC49-8377-4EFB-A537-FAE916619DB9@zope.com> On Jul 28, 2008, at 1:14 PM, kiorky wrote: ... >> Can you provide a buildout I can use to reproduce this problem? ... > I saw this problem which broke minitage too a week ago. > > Jim, you can see all the buildouts in there : http://trac.minitage.org/trac/browser > > like:http://trac.minitage.org/trac/browser/minitage/buildouts/dependencies/bzip2-1.0.4/buildout.cfg > . > > > They will all fail with zc.buildout >= 1.1 Great! Thanks. I'll look at that. > > > What fails there : > eggs-directory and develop-directory will compute both to: > buildoutdir/buildoutdir/../../eggs/*cache > instead of : > buildoutdir/../../eggs/*cache > > I work arounded them with a relative path. > > In zc/buildout/buildout.py, at l.135 , you assume buildout path is a > prefix for all directories which causes this problem. Not exactly. Buildout treats these as relative to the buildout directory. It uses os.path.join to prepend the buildout directory. os.path.join is a noop if the second argument is an absolute path. Anyway, I'll debug this using your buildout. Jim -- Jim Fulton Zope Corporation From jim at zope.com Mon Jul 28 19:58:39 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 28 Jul 2008 13:58:39 -0400 Subject: [Distutils] buildout directory computation change In-Reply-To: <488DFE8C.2000902@cryptelium.net> References: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> <488DFE8C.2000902@cryptelium.net> Message-ID: On Jul 28, 2008, at 1:14 PM, kiorky wrote: > Jim Fulton a ?crit : >> On Jul 28, 2008, at 11:28 AM, whit morriss wrote: >>> it looks like something changes in how some vars (ie buildout:egg- >>> directory) gets computed between 1.0.2 and 1.1.0 >>> >>> OSError: [Errno 2] No such file or directory: '/Users/whit/dev/geo/ >>> alm3//Users/whit/dev/geo/alm3/develop-eggs' >>> >>> is the resulting error for: >>> >>> eggs-directory = ${buildout:directory}/develop-eggs >>> >>> instead of: >>> >>> '/Users/whit/dev/geo/alm3/develop-eggs' >>> >>> (which I believe works until at least 1.0.2) >>> >>> buildout seems to implicitly assume I want buildout:directory >>> appended. is this a feature, bug, or something I can turn off? >> The way buildout normalizes buildout paths did change in 1.1.0. I >> haven't seen this error and can't see, in the code, while this >> error would occur. >> Can you provide a buildout I can use to reproduce this problem? >> Jim >> -- >> Jim Fulton >> Zope Corporation >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG at python.org >> http://mail.python.org/mailman/listinfo/distutils-sig > I saw this problem which broke minitage too a week ago. > > Jim, you can see all the buildouts in there : http://trac.minitage.org/trac/browser > > like:http://trac.minitage.org/trac/browser/minitage/buildouts/dependencies/bzip2-1.0.4/buildout.cfg > . > > They will all fail with zc.buildout >= 1.1 Not for me. :) I've tried on both Ubuntu and Mac OS X. Jim -- Jim Fulton Zope Corporation From jim at zope.com Mon Jul 28 20:32:02 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 28 Jul 2008 14:32:02 -0400 Subject: [Distutils] buildout directory computation change In-Reply-To: References: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> <488DFE8C.2000902@cryptelium.net> Message-ID: <51E306FE-04ED-4431-B474-91533258035B@zope.com> On Jul 28, 2008, at 1:58 PM, Jim Fulton wrote: > > On Jul 28, 2008, at 1:14 PM, kiorky wrote: > >> Jim Fulton a ?crit : >>> On Jul 28, 2008, at 11:28 AM, whit morriss wrote: >>>> it looks like something changes in how some vars (ie buildout:egg- >>>> directory) gets computed between 1.0.2 and 1.1.0 >>>> >>>> OSError: [Errno 2] No such file or directory: '/Users/whit/dev/ >>>> geo/alm3//Users/whit/dev/geo/alm3/develop-eggs' >>>> >>>> is the resulting error for: >>>> >>>> eggs-directory = ${buildout:directory}/develop-eggs >>>> >>>> instead of: >>>> >>>> '/Users/whit/dev/geo/alm3/develop-eggs' >>>> >>>> (which I believe works until at least 1.0.2) >>>> >>>> buildout seems to implicitly assume I want buildout:directory >>>> appended. is this a feature, bug, or something I can turn off? >>> The way buildout normalizes buildout paths did change in 1.1.0. I >>> haven't seen this error and can't see, in the code, while this >>> error would occur. >>> Can you provide a buildout I can use to reproduce this problem? >>> Jim >>> -- >>> Jim Fulton >>> Zope Corporation >>> _______________________________________________ >>> Distutils-SIG maillist - Distutils-SIG at python.org >>> http://mail.python.org/mailman/listinfo/distutils-sig >> I saw this problem which broke minitage too a week ago. >> >> Jim, you can see all the buildouts in there : http://trac.minitage.org/trac/browser >> >> like:http://trac.minitage.org/trac/browser/minitage/buildouts/dependencies/bzip2-1.0.4/buildout.cfg >> . >> >> They will all fail with zc.buildout >= 1.1 > > > Not for me. :) I've tried on both Ubuntu and Mac OS X. But I've been able to create another buildout that seems to exhibit the same symptom. Jim -- Jim Fulton Zope Corporation From kiorky at cryptelium.net Mon Jul 28 21:51:14 2008 From: kiorky at cryptelium.net (kiorky) Date: Mon, 28 Jul 2008 21:51:14 +0200 Subject: [Distutils] buildout directory computation change In-Reply-To: <51E306FE-04ED-4431-B474-91533258035B@zope.com> References: <69EC9FED-A917-4599-8C9E-361ADD4D2EF2@zope.com> <488DFE8C.2000902@cryptelium.net> <51E306FE-04ED-4431-B474-91533258035B@zope.com> Message-ID: <488E2332.2030609@cryptelium.net> Jim Fulton a ?crit : > > On Jul 28, 2008, at 1:58 PM, Jim Fulton wrote: > >> >> On Jul 28, 2008, at 1:14 PM, kiorky wrote: >> >>> Jim Fulton a ?crit : >>>> On Jul 28, 2008, at 11:28 AM, whit morriss wrote: >>>>> it looks like something changes in how some vars (ie >>>>> buildout:egg-directory) gets computed between 1.0.2 and 1.1.0 >>>>> >>>>> OSError: [Errno 2] No such file or directory: >>>>> '/Users/whit/dev/geo/alm3//Users/whit/dev/geo/alm3/develop-eggs' >>>>> >>>>> is the resulting error for: >>>>> >>>>> eggs-directory = ${buildout:directory}/develop-eggs >>>>> >>>>> instead of: >>>>> >>>>> '/Users/whit/dev/geo/alm3/develop-eggs' >>>>> >>>>> (which I believe works until at least 1.0.2) >>>>> >>>>> buildout seems to implicitly assume I want buildout:directory >>>>> appended. is this a feature, bug, or something I can turn off? >>>> The way buildout normalizes buildout paths did change in 1.1.0. I >>>> haven't seen this error and can't see, in the code, while this error >>>> would occur. >>>> Can you provide a buildout I can use to reproduce this problem? >>>> Jim >>>> -- >>>> Jim Fulton >>>> Zope Corporation >>>> _______________________________________________ >>>> Distutils-SIG maillist - Distutils-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/distutils-sig >>> I saw this problem which broke minitage too a week ago. >>> >>> Jim, you can see all the buildouts in there : >>> http://trac.minitage.org/trac/browser >>> like:http://trac.minitage.org/trac/browser/minitage/buildouts/dependencies/bzip2-1.0.4/buildout.cfg. >>> >>> >>> They will all fail with zc.buildout >= 1.1 >> >> >> Not for me. :) I've tried on both Ubuntu and Mac OS X. > > > But I've been able to create another buildout that seems to exhibit the > same symptom. > > Jim > > -- > Jim Fulton > Zope Corporation > > You may have tested the fixed buildout ;) . see: http://hg.minitage.org/hg/minitage/buildouts/dependencies/bzip2-1.0.4/file/2e3ea95738e5/buildout.cfg By prefixing, yes i meaned to prepend the buildout path to the variables in buildout part but i might not been enought clear. The problem is not the join(), but with variables substition. I may be wrong but it s how i understand things happen: The sample buildout snippet: [project] foo = /abspath/a [buildout] eggs = ${project:foo} Then we run buildout: li.135 No substitution there, we use data. >>> os.path.join( '/abs/path/to/buildout/', '${project:foo}') '/abs/path/to/buildout/${project:foo}' li.172 Substitution there, we use self['buildout']: # '/abs/path/to/buildout/${project:foo}' -> '/abs/path/to/buildout//abspath/a' >>> options['eggs'+'-directory'] '/abs/path/to/buildout//abspath/a' >>> os.path.join( '/abs/path/to/buildout/', '/abs/path/to/buildout//abspath/a') '/abs/path/to/buildout//abspath/a' -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From setuptools at bugs.python.org Mon Jul 28 23:50:12 2008 From: setuptools at bugs.python.org (Nathan R. Yergler) Date: Mon, 28 Jul 2008 21:50:12 +0000 Subject: [Distutils] [issue29] SVN detection for package indices breaks on Sourceforge.net In-Reply-To: <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> Message-ID: <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> New submission from Nathan R. Yergler : PackageIndex._download_html (setuptools/package_index.py) attempts to detect if an HTML page is a Subversion repository using the regular expression r'Revision \d+:'. This breaks for Sourceforge subversion repositories, which include the project name before the "Revision" text (see http://cctools.svn.sourceforge.net/svnroot/cctools/vendorlibs/utidylib/ for an arbitrary example). ---------- messages: 64 nosy: nyergler priority: bug status: unread title: SVN detection for package indices breaks on Sourceforge.net _______________________________________________ Setuptools tracker <setuptools at bugs.python.org> <http://bugs.python.org/setuptools/issue29> _______________________________________________ From d.w.morriss at gmail.com Tue Jul 29 05:14:23 2008 From: d.w.morriss at gmail.com (whit morriss) Date: Mon, 28 Jul 2008 22:14:23 -0500 Subject: [Distutils] [issue29] SVN detection for package indices breaks on Sourceforge.net In-Reply-To: <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> References: <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> <1217281812.05.0.803508785546.issue29@psf.upfronthosting.co.za> Message-ID: <g6m1uf$4hb$1@ger.gmane.org> Nathan R. Yergler wrote: > New submission from Nathan R. Yergler <nathan at yergler.net>: > > PackageIndex._download_html (setuptools/package_index.py) attempts to detect if > an HTML page is a Subversion repository using the regular expression > r'<title>Revision \d+:'. This breaks for Sourceforge subversion repositories, > which include the project name before the "Revision" text (see > http://cctools.svn.sourceforge.net/svnroot/cctools/vendorlibs/utidylib/ for an > arbitrary example). > > ---------- > messages: 64 > nosy: nyergler > priority: bug > status: unread > title: SVN detection for package indices breaks on Sourceforge.net > > _______________________________________________ > Setuptools tracker <setuptools at bugs.python.org> > <http://bugs.python.org/setuptools/issue29> > _______________________________________________ > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > looks like sf upgraded to svn 1.5? this issue actually breaks setuptools for anyone using the default xslt template for svn 1.5 (though that template is inadequate for fixing it) r'<title>\s*[a-zA-Z]+\s*\-?\s*Revision \d+:' will match both old and new: <title>almanac - Revision 1179: / <title>Revision 19507: / seems like there ought to be a better way to do this than sniffing title tags though... especially since svn offers easy ways to break this via the svnindex.xsl template. -w From cz at gocept.com Tue Jul 29 08:38:16 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Tue, 29 Jul 2008 08:38:16 +0200 Subject: [Distutils] A release to at least stop crashing on Subversion 1.5 would be nice References: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local> <4888C2EF.1030707@cryptelium.net> Message-ID: <g6mdso$u09$1@ger.gmane.org> On 2008-07-24 19:59:11 +0200, kiorky <kiorky at cryptelium.net> said: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > Arlo Belshee a =E9crit : >> In command/sdist.py, line 90 refers to a global log function which does= > not exist. Thus, instead of logging a warning about not understanding Su= > bversion, setuptools crashes. >> =20 >> The default setup scripts for Pylons (and probably others) use svn revi= > sion tagging. Thus, the following causes a crash: >> =20 >> easy_install Pylons >> paster create -t Pylons proj >> setup.py develop >> =20 >> And, since the user hasn't done any config (or anything but follow a tu= > torial), he isn't able to easily figure out what went wrong. Also, since = > setuptools was likely installed automatically for him via the egg in the = > cheeseshop, he isn't aware of anything that may be in dev for setuptools.= > A new user's likely response is to get frustrated for 15 minutes, then m= > ove on to another web framework / language. >> =20 >> Even if you don't provide svn 1.5 support, can you at least post an egg= > that won't crash in the presence of svn 1.5? >> =20 >> Thanks. >> =20 >> Arlo >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG at python.org >> http://mail.python.org/mailman/listinfo/distutils-sig > > You can easy_install -U "setuptools =3D=3D dev" > It is fixed on trunk as far as i know. That does not really help with an empty python. I'm not going to install anything with easy_install to have no sideeffects when using buildout. -- Christian Zagrodnick ? cz at gocept.com gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany http://gocept.com ? tel +49 345 1229889 4 ? fax +49 345 1229889 1 Zope and Plone consulting and development From d.w.morriss at gmail.com Tue Jul 29 16:39:56 2008 From: d.w.morriss at gmail.com (whit morriss) Date: Tue, 29 Jul 2008 09:39:56 -0500 Subject: [Distutils] upgrading buildout In-Reply-To: <g6kpdm$4pe$1@ger.gmane.org> References: <g6kpdm$4pe$1@ger.gmane.org> Message-ID: <g6na3t$rkl$1@ger.gmane.org> whit morriss wrote: > I'm perhaps running buildout in a bit of unusual fashion (from my > virtual env bin rather than the builds bin) and updated it recently from > 1.0.2 to 1.1.0 to debug some issue folks were having with fresh > checkouts of one of my builds (see previous message). as a caveat for others, we also noticed a number of older recipes which are cached don't take the new allowed hosts arg. It looks like older copies (in this case zc.recipe.egg) got installed in the virtualenv sitepackages (probably for the purposes of investigation) or egg caches and did not get updated. In systems like buildout where every buildout is necessarily a patch work of called dependencies (most frameworks or component systems are like this in one way or another, sometimes referred as what separates frameworks from libs), it would be useful to have some mechanism for propagate an update of a downstream component. Does setuptool support anything like this (I'm doubting it?)? could or does zc.buildout? for builds, I could see this being handled more as a migration. Update the framework library, run a migration to upgrade all the component libraries, rebuild. -w From jim at zope.com Tue Jul 29 17:30:00 2008 From: jim at zope.com (Jim Fulton) Date: Tue, 29 Jul 2008 11:30:00 -0400 Subject: [Distutils] upgrading buildout In-Reply-To: <g6na3t$rkl$1@ger.gmane.org> References: <g6kpdm$4pe$1@ger.gmane.org> <g6na3t$rkl$1@ger.gmane.org> Message-ID: <FC78285A-EFEC-4799-A6FD-3258FAC795F9@zope.com> On Jul 29, 2008, at 10:39 AM, whit morriss wrote: > whit morriss wrote: >> I'm perhaps running buildout in a bit of unusual fashion (from my >> virtual env bin rather than the builds bin) and updated it recently >> from 1.0.2 to 1.1.0 to debug some issue folks were having with >> fresh checkouts of one of my builds (see previous message). > > as a caveat for others, we also noticed a number of older recipes > which are cached don't take the new allowed hosts arg. It looks > like older copies (in this case zc.recipe.egg) got installed in the > virtualenv sitepackages (probably for the purposes of investigation) > or egg caches and did not get updated. This sounds like a bug. I expect buildout to get and use the newest distributions that satisfy its requirements regardless of whether older versions are in site-packages. One way that this would fail is if eggs are installed into site-packages as develop eggs, aka "single- version-externally-managed". buildout gives preference to develop eggs even if there are newer non-develop eggs. Distributions installed using -single-version-externally-managed are tagged by setuptools as develop eggs. I really wish setuptools made a distinction between single-version-externally-managed and develop eggs. Was the zc.recipe.egg distribution installed into your site- packages using -single-version-externally-managed? (This will be the case if the egg contents are stored directly in site-packages rather than having egg files or directories.) > In systems like buildout where every buildout is necessarily a patch > work of called dependencies (most frameworks or component systems > are like this in one way or another, sometimes referred as what > separates frameworks from libs), it would be useful to have some > mechanism for propagate an update of a downstream component. By "downstream", do you mean a dependency? > Does setuptool support anything like this (I'm doubting it?)? > could or does zc.buildout? > > for builds, I could see this being handled more as a migration. > Update the framework library, run a migration to upgrade all the > component libraries, rebuild. As a general rule, buildout always tries to find the latest versions of all distributions used, including dependencies. One exception to this is that it prefers develop eggs. Jim -- Jim Fulton Zope Corporation From dpeterson at enthought.com Thu Jul 31 02:05:37 2008 From: dpeterson at enthought.com (Dave Peterson) Date: Wed, 30 Jul 2008 19:05:37 -0500 Subject: [Distutils] Bug in setuptools version parsing when appending '.dev'? Message-ID: <489101D1.3030903@enthought.com> Am I missing something or is the following a bug whereby adding the '.dev' tag is doing something weird? >>> from pkg_resources import parse_requirement as pv >>> pv('1.0a1.dev') < pv('1.0a1') True >>> pv('1.0a1') < pv('1.0') True >>> pv('1.0a1.dev') < pv('1.0.dev') False >>> pv('1.0a1') < pv('1.0.dev') False >>> import setuptools >>> setuptools.__version__ '0.6c8' This is mainly causing us problems when projects try to track alpha and beta level bumps in dependencies, such as when project Foo requires project Bar version 3.0b1 via a requirement like 'Bar >= 3.0b1' (which means we don't want the development prereleases of Bar's first beta release, but anything after that should be okay.) But then when we actually want to release Bar 3.0 and change the version number to just '3.0', suddenly installs fail while we try to run the last set of tests because '3.0.dev' is older than '3.0b1'. If it is not a bug, how do you handle situations where you want to run that last round of testing prior to tagging and building releases? I'd rather do that AFTER making all source changes, and not have to change the version number after the testing. -- Dave From lumir.jasiok at vsb.cz Thu Jul 31 11:46:59 2008 From: lumir.jasiok at vsb.cz (=?ISO-8859-1?Q?Lum=EDr_Jasiok?=) Date: Thu, 31 Jul 2008 11:46:59 +0200 Subject: [Distutils] How to create deb package Message-ID: <48918A13.1000903@vsb.cz> Hi, I need to create .deb package from source package. I am using distutils. Is there some working bdist_deb extension? What is best practices at this case? Any useful comments will be appreciate. Best Regards Lumir -- Lum?r Jasiok VSB-TU Ostrava - Computer centre Tel: +420 59 732 3189 E-mail: lumir.jasiok at vsb.cz http://www.vsb.cz