From ianb at colorstudy.com Tue Jun 1 05:12:17 2010 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 31 May 2010 22:12:17 -0500 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> Message-ID: On Mon, May 31, 2010 at 10:11 AM, Tarek Ziad? wrote: > On Mon, May 31, 2010 at 4:55 PM, Ian Bicking wrote: > [..] > > Well, I could list the problems, but basically I strongly dislike the > idea > > that, say, Python 3.2 will ship distutils2 with a certain version of pip, > > and that people would have to upgrade Python or wait for a Python release > to > > get upgrades of pip. > > .. or allow people to configure in distutils2 an alternative > installer. That is: a newer version of Pip. > So they don't suffer from the Python release cycle by being able to > upgrade the installer. > The biggest advantage I see of directly merging pip and distutils2 is that they could share code... but if you can upgrade pip without distutils2 then pip will have to work around any bugs in distutils2 to maintain compatibility with old versions of distutils2 (assuming it supports upgrading *only* pip). At which point they aren't "merged" at all, and pip is exactly where it is now. If distutils2 *and* pip were upgrading together consistently (i.e., they were actually merged), and if releases were essentially a superset of both projects' releases, then I'd have no problem with that. I think we can offer *some* backward compatibility guarantees for pip, like command-line interface (but not for any internal interfaces at this time, though maybe some in the future). In terms of release cycles I'm also somewhat uncomfortable with the extraction of the VCS support... it feels more like a political concession than a good technical decision. I don't want the brokenness of the stdlib process to drive choices in pip. I also don't think it should drive choices in distutils2, and I don't think it's healthy for distutils2, but it's not my project so I'll only offer that as advice. I strongly support the addition of a new category of library that is somewhere between the standard library and just-another-library, a library with some authority and support in the community, but with a separate release cycle entirely. There's a lot of libraries that should be like this, but it's not too painful because most of them are pretty much "done" -- they've had very few changes or additions (maybe for good reasons, maybe not). I think distutils/setuptools/distutils2/pip reveal the need for this category more than many packages because they are both important and need community approval, but are very much Not Done and I think will probably never be done (since they interact with so many moving parts some of which aren't part of Python at all). -- Ian Bicking | http://blog.ianbicking.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziade.tarek at gmail.com Tue Jun 1 10:27:11 2010 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Tue, 1 Jun 2010 10:27:11 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> Message-ID: On Tue, Jun 1, 2010 at 5:12 AM, Ian Bicking wrote: [..] > In terms of release cycles I'm also somewhat uncomfortable with the > extraction of the VCS support... it feels more like a political concession > than a good technical decision.? I don't want the brokenness of the stdlib > process to drive choices in pip.? I also don't think it should drive choices > in distutils2, and I don't think it's healthy for distutils2, but it's not > my project so I'll only offer that as advice. Sounds like the stdlib is hell to you ;) More seriously, how do you define a package that is a good candidate for the stdlib in that case? If there's no good definition, doesn't it mean that there's a higher level problem ? Like, the length of the release cycle of the sdtlib itself ? > > I strongly support the addition of a new category of library that is > somewhere between the standard library and just-another-library, a library > with some authority and support in the community, but with a separate > release cycle entirely.? There's a lot of libraries that should be like > this, but it's not too painful because most of them are pretty much "done" > -- they've had very few changes or additions (maybe for good reasons, maybe > not).? I think distutils/setuptools/distutils2/pip reveal the need for this > category more than many packages because they are both important and need > community approval, but are very much Not Done and I think will probably > never be done (since they interact with so many moving parts some of which > aren't part of Python at all). I am not sure what this would mean for the end-user (a fat release of Python ?) and maybe Pip belongs to that category. For Distutils2 though, most part of it will not change a lot within a Python release, (beside bugfix of course). For example, modules like "version", or "metadata" won't move too much. I guess we will work on a lighter script on our side then. Regards Tarek -- Tarek Ziad? | http://ziade.org From chris at simplistix.co.uk Tue Jun 1 14:05:38 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 01 Jun 2010 13:05:38 +0100 Subject: [Distutils] [buildout/easyinstall] downloading from a url Message-ID: <4C04F792.7010002@simplistix.co.uk> Hi All, We have a collection of private eggs served from a simple folder served up by Apache. The following works fine to get these eggs via buildout: [buildout] find-links = http://username:password at server/eggs-index/ However, the following does not find the eggs: bin/easy_install --find-links=http://username:password at server/eggs-index/ eggname However, if I mount up the folder served by apache and do: bin/easy_install --find-links=/mnt/path/to/eggs-index/ eggname ...it works fine. bin/easy_install --find-links=http://username:password at server/eggs-index/eggname-version.tar.gz ...bombs out complaining that authorization is required. So, how come the behaviour of all of these is different? cheers, Chris From chris at simplistix.co.uk Tue Jun 1 15:22:31 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 01 Jun 2010 14:22:31 +0100 Subject: [Distutils] [buildout] develop vs extends/default.cfg Message-ID: <4C050997.1050909@simplistix.co.uk> Hi All, What is the expected behaviour when the following are all true: - default.cfg has a develop key - buildout.cfg has a develop key, and extends a base.bfg - base.cfg has a develop key My hope is that all 3 should be set unioned for the develop options. However, my experience so far is that, at the least, the one in default.cfg is ignored... Chris From jbaker at zeomega.com Tue Jun 1 15:42:57 2010 From: jbaker at zeomega.com (Jason Baker) Date: Tue, 1 Jun 2010 08:42:57 -0500 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: Message-ID: On Fri, May 28, 2010 at 6:13 PM, Tarek Ziad? wrote: > Hello, > > Distutils2 is going to be added back in Python (hopefully in 3.2) and > without an install script, it's pretty useless as-is. > > We've discussed during the summit at Pycon to create some kind of > bootstrap script in Python, to allow people to > set up an installer of their choice, but I think it's a bad idea. > > = summary of the summit proposal = > > IIRC: > > - an "install" script is added in the scripts, for people to install > distributions in Python. Could be called "pyinstall" for example. > > - when first used, it would ask the user to choose a third-party > installer (like Pip). Then it would download it and > install it with a simple "python setup.py install" > > - from there, the install script would be linked to that installer. > > If I recall it correctly, this feature was proposed to be able to have > a "modern" installer in Python without > including it in the standard library. (so it can have its own shorter > release cycles). The bootstrap story > would just make it easier for people to get an installer, without > having to do extra manual steps. > > The problem I have with this approach is that we need to manage > somewhere at PyPI a list of potential installers, > and maybe deal with upgrades and replacements. Plus, I am not sure > that a user will really understand what to > do when he's asked to chose an installer. Sounds like something we > should only ask to power users, and > people that know what they are doing with p7g. So a bootstrap script > is useless for them. > > = alternative proposal = > > Let's add that script but powered by Distutils2. It could be Pip if > people from this project think it's a good idea and want to merge, or > an easy_install derivation, or a new script from scratch. > > IOW: you get an installer for free in the stdlib without having to think. > > Now for the problem of the release cycle (e.g. once in the standard > library it has to wait 18 months for a new version), > I propose that Distutils2 allow the usage of a third party installer > through configuration. IOW, Distutils2 would ship with an installer, > but could use through a simple change in distutils.cfg, another one > installed by a third party project that is more recent. > > For this to work, we can define an installer standard interface ala > wsgi. Basically, we state that an installer has to implement a simple > function that takes a name of a project to install, and an optional > version predicate: > > def install(name, version=None): # if version is None, it means > the latest one. > ... > > This needs more work, uninstall is missing in that description, and > what about the script options, etc. but you get the idea: make sure > people can use the installer of their choice, if it turns out that the > one provided by Distutils2 is not good enough anymore for any reason. > > Any opinion ? > One possible route would be to have distutils2 have an API that's similar in concept to Apache Ivy[1] (but being pythonic, rather than requiring XML and being Java oriented :-) ). This way, people can build tools like pip and easy_install with more standard behavior to make installing packages easier. That said, you wouldn't really *need* those packages. The only thing that you would really need is the Python interpreter and distutils2. This would make it fairly easy to customize the build and installation process as well (especially for tools like buildout or envbuilder). [1] http://ant.apache.org/ivy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at zope.com Tue Jun 1 16:14:40 2010 From: jim at zope.com (Jim Fulton) Date: Tue, 1 Jun 2010 10:14:40 -0400 Subject: [Distutils] [buildout] develop vs extends/default.cfg In-Reply-To: <4C050997.1050909@simplistix.co.uk> References: <4C050997.1050909@simplistix.co.uk> Message-ID: On Tue, Jun 1, 2010 at 9:22 AM, Chris Withers wrote: > Hi All, > > What is the expected behaviour when the following are all true: > > - default.cfg has a develop key > - buildout.cfg has a develop key, and extends a base.bfg > - base.cfg has a develop key > > My hope is that all 3 should be set unioned for the develop options. > > However, my experience so far is that, at the least, the one in default.cfg > is ignored... When a file extends another, it's options *override* options in the extended file unless you use += in the extending file, as in: develop += foo In which case, the new option values are appended to the ones from the extended file. Jim -- Jim Fulton From pje at telecommunity.com Tue Jun 1 19:28:07 2010 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 01 Jun 2010 13:28:07 -0400 Subject: [Distutils] [buildout/easyinstall] downloading from a url In-Reply-To: <4C04F792.7010002@simplistix.co.uk> References: <4C04F792.7010002@simplistix.co.uk> Message-ID: <20100601172817.53AD93A402D@sparrow.telecommunity.com> At 01:05 PM 6/1/2010 +0100, Chris Withers wrote: >Hi All, > >We have a collection of private eggs served from a simple folder >served up by Apache. > >The following works fine to get these eggs via buildout: > >[buildout] >find-links = http://username:password at server/eggs-index/ > >However, the following does not find the eggs: > >bin/easy_install >--find-links=http://username:password at server/eggs-index/ eggname > >However, if I mount up the folder served by apache and do: > >bin/easy_install --find-links=/mnt/path/to/eggs-index/ eggname > >...it works fine. > >bin/easy_install >--find-links=http://username:password at server/eggs-index/eggname-version.tar.gz > >...bombs out complaining that authorization is required. > >So, how come the behaviour of all of these is different? I can't speak to the buildout part, but if you can do an 'easy_install -vvn ...' with the others, I'd like to see what it's doing. From chris at simplistix.co.uk Tue Jun 1 19:32:56 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 01 Jun 2010 18:32:56 +0100 Subject: [Distutils] [buildout] develop vs extends/default.cfg In-Reply-To: References: <4C050997.1050909@simplistix.co.uk> Message-ID: <4C054448.5080608@simplistix.co.uk> Jim Fulton wrote: > On Tue, Jun 1, 2010 at 9:22 AM, Chris Withers wrote: >> Hi All, >> >> What is the expected behaviour when the following are all true: >> >> - default.cfg has a develop key >> - buildout.cfg has a develop key, and extends a base.bfg >> - base.cfg has a develop key >> >> My hope is that all 3 should be set unioned for the develop options. >> >> However, my experience so far is that, at the least, the one in default.cfg >> is ignored... > > When a file extends another, it's options *override* options in the ...except extends, which does appear to overlay, right? > extended file unless you use += in the extending file, as in: > > develop += foo Hmm, okay, I think there's a bug lurking, please see attached .tgz When I run the buildout in package1, only package1's folde ends up being develop'ed. The key appears to be the += for the develop key in base.bfg. If I change that to just =, the behaviour seems as expected. However, The += was very deliberate, so as to allow develop paths to be specified user-wide in default.cfg, based on your advice above. Interestingly, any paths in default.cfg's develop *do* end up being used in the attached example. Where/how should I report this? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.tgz Type: application/x-compressed Size: 451 bytes Desc: not available URL: From chris at simplistix.co.uk Tue Jun 1 19:51:05 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 01 Jun 2010 18:51:05 +0100 Subject: [Distutils] [buildout/easyinstall] downloading from a url In-Reply-To: <20100601172817.53AD93A402D@sparrow.telecommunity.com> References: <4C04F792.7010002@simplistix.co.uk> <20100601172817.53AD93A402D@sparrow.telecommunity.com> Message-ID: <4C054889.2090901@simplistix.co.uk> P.J. Eby wrote: > At 01:05 PM 6/1/2010 +0100, Chris Withers wrote: >> Hi All, >> >> We have a collection of private eggs served from a simple folder >> served up by Apache. >> >> However, the following does not find the eggs: > > I can't speak to the buildout part, but if you can do an 'easy_install > -vvn ...' with the others, I'd like to see what it's doing. Heh, okay, got to the bottom of this. The username is an Active Directory username, and so has a domain in it, meaning it also has a forward slash in it... Doubling the forward slash solved the problem... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From chris at simplistix.co.uk Tue Jun 1 19:56:04 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 01 Jun 2010 18:56:04 +0100 Subject: [Distutils] [buildout/easyinstall] downloading from a url In-Reply-To: <4C054889.2090901@simplistix.co.uk> References: <4C04F792.7010002@simplistix.co.uk> <20100601172817.53AD93A402D@sparrow.telecommunity.com> <4C054889.2090901@simplistix.co.uk> Message-ID: <4C0549B4.7000100@simplistix.co.uk> Chris Withers wrote: > > Heh, okay, got to the bottom of this. > The username is an Active Directory username, and so has a domain in it, > meaning it also has a forward slash in it... > > Doubling the forward slash solved the problem... ...and by "forward slash", I do of course mean "backslash" :-S Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From ronaldoussoren at mac.com Thu Jun 3 09:15:25 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 03 Jun 2010 09:15:25 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> Message-ID: <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> On 31 May, 2010, at 19:10, Tarek Ziad? wrote: > On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote: >> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote: >>> Nope, pip's used --record on installation for years, and the above has >>> been true since the moment uninstall landed in pip. There are enough >>> different ways things can get installed that it's not surprising that >>> some discussions may have been confused ;-) >> >> That may be it. Forcing --record in Python 3.2 would be a step forward then? :-) > > You mean in the current distutils ? Because distutils2 will have the > PEP 376 implementation, > where we create a RECORD file for each installed project in its dist-info/ I haven't carefully read the entire discussion, but do you mean that distutils won't follow PEP 376 during installation? Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From ziade.tarek at gmail.com Thu Jun 3 09:50:43 2010 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 3 Jun 2010 09:50:43 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> Message-ID: On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren wrote: > > On 31 May, 2010, at 19:10, Tarek Ziad? wrote: > >> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote: >>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote: >>>> Nope, pip's used --record on installation for years, and the above has >>>> been true since the moment uninstall landed in pip. There are enough >>>> different ways things can get installed that it's not surprising that >>>> some discussions may have been confused ;-) >>> >>> That may be it. Forcing --record in Python 3.2 would be a step forward then? :-) >> >> You mean in the current distutils ? Because distutils2 will have the >> PEP 376 implementation, >> where we create a RECORD file for each installed project in its dist-info/ > > I haven't carefully read the entire discussion, but do you mean that distutils won't follow PEP 376 during installation? If people use the old Distutils, (what I've called the current distutils), and trigger an installation via 'python setup.py install'. It'll use the existing code, so install it the 'old' way. > > Ronald > > -- Tarek Ziad? | http://ziade.org From ziade.tarek at gmail.com Thu Jun 3 10:10:55 2010 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 3 Jun 2010 10:10:55 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> Message-ID: On Thu, Jun 3, 2010 at 10:02 AM, Ronald Oussoren wrote: > > On 3 Jun, 2010, at 9:50, Tarek Ziad? wrote: > >> On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren wrote: >>> >>> On 31 May, 2010, at 19:10, Tarek Ziad? wrote: >>> >>>> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote: >>>>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote: >>>>>> Nope, pip's used --record on installation for years, and the above has >>>>>> been true since the moment uninstall landed in pip. There are enough >>>>>> different ways things can get installed that it's not surprising that >>>>>> some discussions may have been confused ;-) >>>>> >>>>> That may be it. Forcing --record in Python 3.2 would be a step forward then? :-) >>>> >>>> You mean in the current distutils ? Because distutils2 will have the >>>> PEP 376 implementation, >>>> where we create a RECORD file for each installed project in its dist-info/ >>> >>> I haven't carefully read the entire discussion, but do you mean that distutils won't follow PEP 376 during installation? >> >> If people use the old Distutils, (what I've called the current >> distutils), and trigger an installation via 'python setup.py install'. >> It'll use the existing code, so install it the 'old' way. > > I know that distutils in python 2. 6 and 3.1 won't support PEP 376, but why won't distutils conform to PEP 376 in python 2.7 and 3.2? > The RECORD file from PEP 376 would allow ?manually installed package (e.g. "python setup.py install") to be further managed by a PEP 376 compliant install tool. ?This should be pretty easy to add if it isn't in already, although 2.7rc1 is awfully close. Are you thinking about a full implicit switch to PEP 376, or an optional behavior ? -- Tarek Ziad? | http://ziade.org From ronaldoussoren at mac.com Thu Jun 3 10:24:09 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 03 Jun 2010 10:24:09 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> Message-ID: On 3 Jun, 2010, at 10:10, Tarek Ziad? wrote: > On Thu, Jun 3, 2010 at 10:02 AM, Ronald Oussoren wrote: >> >> On 3 Jun, 2010, at 9:50, Tarek Ziad? wrote: >> >>> On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren wrote: >>>> >>>> On 31 May, 2010, at 19:10, Tarek Ziad? wrote: >>>> >>>>> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote: >>>>>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote: >>>>>>> Nope, pip's used --record on installation for years, and the above has >>>>>>> been true since the moment uninstall landed in pip. There are enough >>>>>>> different ways things can get installed that it's not surprising that >>>>>>> some discussions may have been confused ;-) >>>>>> >>>>>> That may be it. Forcing --record in Python 3.2 would be a step forward then? :-) >>>>> >>>>> You mean in the current distutils ? Because distutils2 will have the >>>>> PEP 376 implementation, >>>>> where we create a RECORD file for each installed project in its dist-info/ >>>> >>>> I haven't carefully read the entire discussion, but do you mean that distutils won't follow PEP 376 during installation? >>> >>> If people use the old Distutils, (what I've called the current >>> distutils), and trigger an installation via 'python setup.py install'. >>> It'll use the existing code, so install it the 'old' way. >> >> I know that distutils in python 2. 6 and 3.1 won't support PEP 376, but why won't distutils conform to PEP 376 in python 2.7 and 3.2? >> The RECORD file from PEP 376 would allow manually installed package (e.g. "python setup.py install") to be further managed by a PEP 376 compliant install tool. This should be pretty easy to add if it isn't in already, although 2.7rc1 is awfully close. > > Are you thinking about a full implicit switch to PEP 376, or an > optional behavior ? A full switch to PEP 376. An option to enable/disable would just be confusing, any option increases the mental load of developers (and anyone that just wants to install a python package to use its functionality) and in this case I don't think adding an option would be worth that. This would break current releases of tools that use the current "egg-info" information due to the different filesystem name (currently .egg-info, .dist-info in PEP 376), but those tools will have to be updated sometime anyway. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From regebro at gmail.com Thu Jun 3 10:25:51 2010 From: regebro at gmail.com (Lennart Regebro) Date: Thu, 3 Jun 2010 10:25:51 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> Message-ID: On Thu, Jun 3, 2010 at 10:02, Ronald Oussoren wrote: > I know that distutils in python 2. 6 and 3.1 won't support PEP 376, but why won't distutils conform to PEP 376 in python 2.7 and 3.2? Correct me if I'm wrong here, but there is a lot of PEPs regarding distutils, and it was simply decided to move all that work out from trunk into distutils2, as I understand it. Makes sense to me anyway. :) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 From ziade.tarek at gmail.com Thu Jun 3 10:38:32 2010 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 3 Jun 2010 10:38:32 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> Message-ID: On Thu, Jun 3, 2010 at 10:24 AM, Ronald Oussoren wrote: [..] > A full switch to PEP 376. ?An option to enable/disable would just be confusing, any option increases the mental load of developers (and anyone that just wants to install a python package to use its functionality) and in this case I don't think adding an option would be worth that. > > This would break current releases of tools that use the current "egg-info" information due to the different filesystem name (currently .egg-info, .dist-info in PEP 376), but those tools will have to be updated sometime anyway. I don't see what would be the advantage, since we are adding in pkgutil APIs (PEP 376 implementation) the ability to read old formats as well, to make it easier to query what's installed. Plus, distutils was marked "frozen" to avoid instability (any change in distutils potentially breaks tools out there, even internal changes). Regards Tarek From ronaldoussoren at mac.com Thu Jun 3 10:48:20 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 03 Jun 2010 10:48:20 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> Message-ID: <05B82F7A-9C77-4831-85D5-0DF9DCA6FD86@mac.com> On 3 Jun, 2010, at 10:38, Tarek Ziad? wrote: > On Thu, Jun 3, 2010 at 10:24 AM, Ronald Oussoren wrote: > [..] >> A full switch to PEP 376. An option to enable/disable would just be confusing, any option increases the mental load of developers (and anyone that just wants to install a python package to use its functionality) and in this case I don't think adding an option would be worth that. >> >> This would break current releases of tools that use the current "egg-info" information due to the different filesystem name (currently .egg-info, .dist-info in PEP 376), but those tools will have to be updated sometime anyway. > > I don't see what would be the advantage, since we are adding in > pkgutil APIs (PEP 376 implementation) the ability to read old formats > as well, to make it easier to query what's installed. Plus, distutils > was marked "frozen" to avoid instability (any change in distutils > potentially breaks tools out there, even internal changes). The RECORD file in PEP 376 enables scripted removal of a distribution, which cannot be done without PEP 376 unless the user that installed the distribution was careful enough to use either the --record option or a tool like pip. I agree that the fragility of distutils is a problem, which would making changing it this far along the 2.7 release process rather dangerous. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From ronaldoussoren at mac.com Thu Jun 3 10:02:32 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 03 Jun 2010 10:02:32 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <4C029CCC.4080508@oddbird.net> <4C03CDCD.1060300@oddbird.net> <4C03EBB9.10308@oddbird.net> <95C64D2C-5FCE-45D5-A73F-633F0175BAE8@mac.com> Message-ID: <9A04F990-F9A1-4751-B47E-1FEB57E7F769@mac.com> On 3 Jun, 2010, at 9:50, Tarek Ziad? wrote: > On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren wrote: >> >> On 31 May, 2010, at 19:10, Tarek Ziad? wrote: >> >>> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote: >>>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote: >>>>> Nope, pip's used --record on installation for years, and the above has >>>>> been true since the moment uninstall landed in pip. There are enough >>>>> different ways things can get installed that it's not surprising that >>>>> some discussions may have been confused ;-) >>>> >>>> That may be it. Forcing --record in Python 3.2 would be a step forward then? :-) >>> >>> You mean in the current distutils ? Because distutils2 will have the >>> PEP 376 implementation, >>> where we create a RECORD file for each installed project in its dist-info/ >> >> I haven't carefully read the entire discussion, but do you mean that distutils won't follow PEP 376 during installation? > > If people use the old Distutils, (what I've called the current > distutils), and trigger an installation via 'python setup.py install'. > It'll use the existing code, so install it the 'old' way. I know that distutils in python 2. 6 and 3.1 won't support PEP 376, but why won't distutils conform to PEP 376 in python 2.7 and 3.2? The RECORD file from PEP 376 would allow manually installed package (e.g. "python setup.py install") to be further managed by a PEP 376 compliant install tool. This should be pretty easy to add if it isn't in already, although 2.7rc1 is awfully close. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From chris at simplistix.co.uk Thu Jun 3 11:13:32 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 03 Jun 2010 10:13:32 +0100 Subject: [Distutils] [buildout] problems moving from a develop'ed egg to a release Message-ID: <4C07723C.6000203@simplistix.co.uk> Hi All, I've been working with svn checkouts of a couple of packages by placing them in the develop key of my default.cfg. Now, I want to stop doing that, so I removed the lines from default.cfg and re-ran the buildout. I was expecting to have complaints about packages not being available, but instead, the develop eggs (ie: the svn checkouts) just kept on being used... ...I ever tried putting in specific requirements in the versions section of my buildout, that I knew the develop eggs wouldn't meet (r100000 wont' exist for a while yet!) No dice, the develop eggs in the checkouts still get used! Here's selected output: $ bin/buildout -vv ... Configuration data: ... [versions] ... repoze.bfg.chameleon_genshi = 0.1-r9432 repoze.bfg.xmlrpc = 0.3 ... We have a develop egg: demo release Getting required 'repoze.bfg.chameleon-genshi' required by demo release. We have a develop egg: repoze.bfg.chameleon-genshi 0.1-r9431 Getting required 'repoze.bfg.xmlrpc==0.3' We have a develop egg: repoze.bfg.xmlrpc 0.3 How do I get buildout to stop using these develop'ed checkouts and go get a package from an index? cheers, Chris From barry at python.org Thu Jun 3 15:38:53 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Jun 2010 09:38:53 -0400 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> Message-ID: <20100603093853.40761f81@heresy> On May 29, 2010, at 10:19 AM, Tarek Ziad? wrote: >I think separating the concerns and letting the end user pick/use >explicitly *one* installer globally is better because several >installers won't compete on the target system (even if we supposely >want them all to be compatible in the future). Of course, this is only >true for source distributions. > >It will also allow distributions to be "dumb" envelopes with static >metadata that are the same all the time, no matter which tool created >them, and eventually remove setup.py in favor of statically described >metadata using PEP 345. > >Today, for instance, if an installer wants to install a distribution >based on setuptools, it has to run the "egg_info" command to extract >the metadata, on the target system. Being able to get those metadata >without running any code would be better. For instance, installers >could list all dependencies for a project by querying PyPI with zero >download/execution. (thanks to PEP 345 environment markers) > >What would make more sense I think, would be to have all installers an >identical archive for a given project, that doesn't need more code to >be run to get all the metadata. > >So at the end, the end user would chose an installer that is >compatible with these archive, and know how to install them. In other >words, have ez_setup for example, run once for all at the Python >level, and be THE installer. Or run a pip_setup or whatever. How would OS vendors get into the game? I could imagine that Ubuntu would want to make an opinionated choice for our users, and maybe even set things up so that packages are installed from our archives (as .deb packages) by default. This would make things very easy for the majority of users, though of course we'd have to allow experts to customize it to grab from the Cheeseshop or use a different installer. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Thu Jun 3 15:43:41 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Jun 2010 09:43:41 -0400 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> Message-ID: <20100603094341.7331d712@heresy> On May 29, 2010, at 09:12 PM, Tarek Ziad? wrote: >That's the point I am trying to express: it's "implicit, embed, >installers in project's setup.py" vs "an installer globally installed, >knowing how to install projects that follows a given standard" I feel pretty firmly that the choice of installer should /not/ be left up to the project's setup.py. That's within the domain of the user, or by proxy, their operating system. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ben+python at benfinney.id.au Thu Jun 3 17:10:57 2010 From: ben+python at benfinney.id.au (Ben Finney) Date: Fri, 04 Jun 2010 01:10:57 +1000 Subject: [Distutils] pip vs easy_install vs distutils2 References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <20100603094341.7331d712@heresy> Message-ID: <87aarccfsu.fsf@benfinney.id.au> Barry Warsaw writes: > On May 29, 2010, at 09:12 PM, Tarek Ziad? wrote: > > >That's the point I am trying to express: it's "implicit, embed, > >installers in project's setup.py" vs "an installer globally installed, > >knowing how to install projects that follows a given standard" > > I feel pretty firmly that the choice of installer should /not/ be left > up to the project's setup.py. That's within the domain of the user, or > by proxy, their operating system. That is the ideal, yes. We need to get to the point where the packaging data stops being an executable program, and is instead purely declarative metadata with a well-defined format and semantic speification. -- \ ?Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.? ?Anthony Taylor | Ben Finney -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From barry at python.org Thu Jun 3 17:36:53 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Jun 2010 11:36:53 -0400 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: <87aarccfsu.fsf@benfinney.id.au> References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100529163220.6A3BF3A405F@sparrow.telecommunity.com> <20100603094341.7331d712@heresy> <87aarccfsu.fsf@benfinney.id.au> Message-ID: <20100603113653.0276847c@heresy> On Jun 04, 2010, at 01:10 AM, Ben Finney wrote: >Barry Warsaw writes: > >> On May 29, 2010, at 09:12 PM, Tarek Ziad? wrote: >> >> >That's the point I am trying to express: it's "implicit, embed, >> >installers in project's setup.py" vs "an installer globally installed, >> >knowing how to install projects that follows a given standard" >> >> I feel pretty firmly that the choice of installer should /not/ be left >> up to the project's setup.py. That's within the domain of the user, or >> by proxy, their operating system. > >That is the ideal, yes. We need to get to the point where the packaging >data stops being an executable program, and is instead purely >declarative metadata with a well-defined format and semantic >speification. As Tarek knows I'd say: +1 :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From cool-rr at cool-rr.com Thu Jun 3 19:48:44 2010 From: cool-rr at cool-rr.com (cool-RR) Date: Thu, 3 Jun 2010 19:48:44 +0200 Subject: [Distutils] Having a Python package install itself under a different name In-Reply-To: References: <20100528003642.AD2243A409D@sparrow.telecommunity.com> Message-ID: On Fri, May 28, 2010 at 2:53 AM, cool-RR wrote: > On Fri, May 28, 2010 at 2:36 AM, P.J. Eby wrote: > >> At 01:11 AM 5/28/2010 +0200, cool-RR wrote: >> >>> The thing I want the most right now is anyone's opinion of what could >>> possibly go wrong with the scheme that P.J. offered, before I start moving >>> my codebase to it. >>> >> >> It's quite routine. Certainly, few of my PyPI projects have the same >> project and package name. For example, 'Importing' contains the module >> 'peak.util.imports'. >> >> To anyone else listening: If you think of ANYTHING that can go wrong with > this scheme, please speak up. I really like knowing about possible problems > in advance. > > Ram. > Hey, I just want to follow up on this issue: I renamed the package to `garlicsim` as suggested, and everything worked out smoothly with no problems. Thanks for your help! Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianb at colorstudy.com Fri Jun 4 20:07:41 2010 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 4 Jun 2010 13:07:41 -0500 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: <20100603093853.40761f81@heresy> References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100603093853.40761f81@heresy> Message-ID: On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw wrote: > >So at the end, the end user would chose an installer that is > >compatible with these archive, and know how to install them. In other > >words, have ez_setup for example, run once for all at the Python > >level, and be THE installer. Or run a pip_setup or whatever. > > How would OS vendors get into the game? I could imagine that Ubuntu would > want to make an opinionated choice for our users, and maybe even set things > up > so that packages are installed from our archives (as .deb packages) by > default. This would make things very easy for the majority of users, > though > of course we'd have to allow experts to customize it to grab from the > Cheeseshop or use a different installer. > I could see how a deb might make sense for an unqualified installation, i.e., one where no specific version or location is indicated. *Probably* a specific version would be okay, but the way deb archives work it seems like the archive would usually be unable to satisfy the request. It would be interesting if you could also hook into a deb generation script, and install ad hoc packages as debs. This really isn't a system choice, but a where-the-package-is-installed choice. If installing in /usr/lib/* then using the system package makes sense. If installing anywhere else it doesn't make sense (home directory, virtualenv environment, something ad hoc using install options). I wonder if it would work best to control this through some distutils.cfg-like file (distutils.cfg is terrible though), that would be looked up based on the installation location. -- Ian Bicking | http://blog.ianbicking.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.cavallo at cavallinux.eu Fri Jun 4 20:50:29 2010 From: a.cavallo at cavallinux.eu (Antonio Cavallo) Date: Fri, 4 Jun 2010 20:50:29 +0200 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100603093853.40761f81@heresy> Message-ID: <7BC7EEDF-FB34-401E-825E-1A233C177489@cavallinux.eu> On 4 Jun 2010, at 20:07, Ian Bicking wrote: SuSE sponsored the opensuse build server for that purpose: providing a build server insulated from the developers environment. https://build.opensuse.org/ They provide yum/yast repositories so binaries can be downloaded automatically (like in the easy_xxx style). I have done some work with it in the recent past if somebody is interested: http://pyvm.sf.net Regards, Antonio Cavallo > On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw wrote: > >So at the end, the end user would chose an installer that is > >compatible with these archive, and know how to install them. In other > >words, have ez_setup for example, run once for all at the Python > >level, and be THE installer. Or run a pip_setup or whatever. > > How would OS vendors get into the game? I could imagine that Ubuntu would > want to make an opinionated choice for our users, and maybe even set things up > so that packages are installed from our archives (as .deb packages) by > default. This would make things very easy for the majority of users, though > of course we'd have to allow experts to customize it to grab from the > Cheeseshop or use a different installer. > > I could see how a deb might make sense for an unqualified installation, i.e., one where no specific version or location is indicated. *Probably* a specific version would be okay, but the way deb archives work it seems like the archive would usually be unable to satisfy the request. It would be interesting if you could also hook into a deb generation script, and install ad hoc packages as debs. > > This really isn't a system choice, but a where-the-package-is-installed choice. If installing in /usr/lib/* then using the system package makes sense. If installing anywhere else it doesn't make sense (home directory, virtualenv environment, something ad hoc using install options). I wonder if it would work best to control this through some distutils.cfg-like file (distutils.cfg is terrible though), that would be looked up based on the installation location. > > -- > Ian Bicking | http://blog.ianbicking.org > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From regebro at gmail.com Fri Jun 4 22:25:09 2010 From: regebro at gmail.com (Lennart Regebro) Date: Fri, 4 Jun 2010 22:25:09 +0200 Subject: [Distutils] Having a Python package install itself under a different name In-Reply-To: References: Message-ID: I just had an idea, no idea if it's good or not: You could try including both the Python 2 and Python 3 source code in the sdist, but select different ones for install depending on the Python version. I haven't tried this, but I can't come up with a reason it wouldn't work. If anyone else can, please tell me before Thursday. ;-) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 On Thu, May 27, 2010 at 22:40, cool-RR wrote: > Hello all! > I want to ask you a question regarding something I want to do with my app. > The reason I'm asking here is because I understand that Distribute somehow > installs itself as "setuptools". (I've never looked into the details of it.) > And I want something similar, so maybe you can advise me how to do it. > I'm developing a package called `garlicsim`. The package is intended for > Python 2.X, but I am also offerring Python 3 support on a different fork > called `garlicsim_py3`.(1) > So both of these packages live side by side on PyPI, and Python 3 users > install `garlicsim_py3`, and Python 2 users install `garlicsim`. > The problem is: When third party modules want to use garlicsim, they should > have one package name to refer to, not two. Sure, they can do something like > this: > ?? ?try: > ?? ? ? ?import garlicsim > ?? ?except ImportError: > ?? ? ? ?import garlicsim_py3 as garlicsim > But I would prefer not to make the developers of these modules do this. > Is there a way that `garlicsim_py3` will install itself under the alias > `garlicsim`? What I want is for a Python 3 user to be able to `import > garlicsim` and refer to the module all the time as `garlicsim`, but that it > will really be `garlicsim_py3`. > ---------- > (1) I've reached the decision to support Python 3 on a fork instead of in > the same code base; It's important for me that the code base will be clean, > and I would really not want to introduce compatibilty hacks. > Thanks, > Ram Rachum. From cool-rr at cool-rr.com Fri Jun 4 22:36:49 2010 From: cool-rr at cool-rr.com (cool-RR) Date: Fri, 4 Jun 2010 22:36:49 +0200 Subject: [Distutils] Having a Python package install itself under a different name In-Reply-To: References: Message-ID: On Fri, Jun 4, 2010 at 10:25 PM, Lennart Regebro wrote: > I just had an idea, no idea if it's good or not: > > You could try including both the Python 2 and Python 3 source code in > the sdist, but select different ones for install depending on the > Python version. > > I haven't tried this, but I can't come up with a reason it wouldn't > work. If anyone else can, please tell me before Thursday. ;-) > -- > Lennart Regebro It would be pretty cool, since I won't have to confuse users with the `_py3` thing, but here are 2 problems: 1. I find it a little dirty that one single package has two different code bases. 2. I like having the Python 3 fork as an actual fork, (i.e. separate repo,) so I can easily merge changes from the main fork. If I keep them next to each other like this, it will be hard for me to keep them as separate repos and therefore hard to do merges. (Keep in mind that the main fork contains three packages, `garlicsim`, `garlicsim_lib` and `garlicsim_wx`, and the Python 3 fork contains `garlicsim` and `garlicsim_lib`, so trying to weave them together will be nontrivial.) Sure, I can figure out some scheme to do this, but it will be messy. Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Fri Jun 4 22:53:23 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Jun 2010 16:53:23 -0400 Subject: [Distutils] pip vs easy_install vs distutils2 In-Reply-To: References: <20100528235508.DDBC93A411E@sparrow.telecommunity.com> <20100603093853.40761f81@heresy> Message-ID: <20100604165323.6f2a8a5c@heresy> On Jun 04, 2010, at 01:07 PM, Ian Bicking wrote: >On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw wrote: > >> >So at the end, the end user would chose an installer that is >> >compatible with these archive, and know how to install them. In other >> >words, have ez_setup for example, run once for all at the Python >> >level, and be THE installer. Or run a pip_setup or whatever. >> >> How would OS vendors get into the game? I could imagine that Ubuntu would >> want to make an opinionated choice for our users, and maybe even set things >> up >> so that packages are installed from our archives (as .deb packages) by >> default. This would make things very easy for the majority of users, >> though >> of course we'd have to allow experts to customize it to grab from the >> Cheeseshop or use a different installer. >> > >I could see how a deb might make sense for an unqualified installation, >i.e., one where no specific version or location is indicated. *Probably* a >specific version would be okay, but the way deb archives work it seems like >the archive would usually be unable to satisfy the request. That seems about right. >It would be interesting if you could also hook into a deb generation script, >and install ad hoc packages as debs. I have evil plans... :) >This really isn't a system choice, but a where-the-package-is-installed >choice. If installing in /usr/lib/* then using the system package makes >sense. If installing anywhere else it doesn't make sense (home directory, >virtualenv environment, something ad hoc using install options). I wonder >if it would work best to control this through some distutils.cfg-like file >(distutils.cfg is terrible though), that would be looked up based on the >installation location. I'd agree. There's definitely a difference between *development* and *deployment*. When I'm developing some library or app, I'm living in my own little world of virtualenv or something similar. I definitely do not want any of that to influence my system Python, at least for the package under development. It's possible that I'll want some of the dependencies installed in my system Python, but then only the ones blessed by my OS, or at least that play my OS package manager's games properly (e.g. an on-demand spun .deb). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From regebro at gmail.com Sat Jun 5 07:22:34 2010 From: regebro at gmail.com (Lennart Regebro) Date: Sat, 5 Jun 2010 07:22:34 +0200 Subject: [Distutils] Having a Python package install itself under a different name In-Reply-To: References: Message-ID: On Fri, Jun 4, 2010 at 22:36, cool-RR wrote: > ?It would be pretty cool, since I won't have to confuse users with the > `_py3` thing, but here are 2 problems: > 1. I find it a little dirty that one single package has two different code > bases. Well, sure, but having two packages is also dirty. :-) It's a matter of taste. > 2. I like having the Python 3 fork as an actual fork, (i.e. separate repo,) > so I can easily merge changes from the main fork. If I keep them next to > each other like this, it will be hard for me to keep them as separate repos > and therefore hard to do merges. Aha, so you use mercurial or? It's hard to do merges between folders there? I'm used to svn, where that wouldn't be a problem. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 From cool-rr at cool-rr.com Sat Jun 5 11:23:19 2010 From: cool-rr at cool-rr.com (cool-RR) Date: Sat, 5 Jun 2010 11:23:19 +0200 Subject: [Distutils] Having a Python package install itself under a different name In-Reply-To: References: Message-ID: On Sat, Jun 5, 2010 at 7:22 AM, Lennart Regebro wrote: > On Fri, Jun 4, 2010 at 22:36, cool-RR wrote: > > It would be pretty cool, since I won't have to confuse users with the > > `_py3` thing, but here are 2 problems: > > 1. I find it a little dirty that one single package has two different > code > > bases. > > Well, sure, but having two packages is also dirty. :-) It's a matter of > taste. > > > 2. I like having the Python 3 fork as an actual fork, (i.e. separate > repo,) > > so I can easily merge changes from the main fork. If I keep them next to > > each other like this, it will be hard for me to keep them as separate > repos > > and therefore hard to do merges. > > Aha, so you use mercurial or? It's hard to do merges between folders > there? I'm used to svn, where that wouldn't be a problem. > > -- > Lennart Regebro > I probably won't take this approach, but thank you Lennart for the tip. Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Sun Jun 6 17:16:04 2010 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 6 Jun 2010 18:16:04 +0300 Subject: [Distutils] bdist_wininst compatibility with pythons and windows versions Message-ID: While Trac 0.12 is about to be released, there is some uncertainty whenever new Distutils-generated installers are compatible with old versions of Windows and Python. There are some fears that installers generated on Vista and Windows 7 won't run on XP or 2000. Is that true? Also is there a limit on the lowest version of Python that installer generated with Distutils to say 2.6.5 will run? [1] http://trac.edgewall.org/ticket/9404#comment:7 [2] http://scons.tigris.org/issues/show_bug.cgi?id=2533 -- anatoly t. From skippy.hammond at gmail.com Mon Jun 7 09:01:55 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Mon, 07 Jun 2010 17:01:55 +1000 Subject: [Distutils] bdist_wininst compatibility with pythons and windows versions In-Reply-To: References: Message-ID: <4C0C9963.9000203@gmail.com> On 7/06/2010 1:16 AM, anatoly techtonik wrote: > While Trac 0.12 is about to be released, there is some uncertainty > whenever new Distutils-generated installers are compatible with old > versions of Windows and Python. There are some fears that installers > generated on Vista and Windows 7 won't run on XP or 2000. Is that > true? That should be fine. pywin32 has used Vista to generate the last few releases and it installs fine on XP (and probably 2000, but I can't say I actually tested that recently) > Also is there a limit on the lowest version of Python that installer > generated with Distutils to say 2.6.5 will run? I'm not aware of any limitations from 2.2 forwards - if you use the --target-version option, bdist_wininst should select the appropriate 'stub' executable for the version you specify (Python 2.6 includes stubs suitable for most 2.2-ish onwards) Mark From benliles at gmail.com Thu Jun 10 18:41:25 2010 From: benliles at gmail.com (Benjamin Liles) Date: Thu, 10 Jun 2010 11:41:25 -0500 Subject: [Distutils] Multiple index server support in setuptools/buildout Message-ID: Is there any plan to add support for multiple index servers or for the find-links to act as index server links in addition to dumb links to an individual package? Thanks, Ben Liles -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Jun 10 23:20:58 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 10 Jun 2010 17:20:58 -0400 Subject: [Distutils] stdeb followup Message-ID: <20100610172058.55ee3298@heresy> Hi Andrew, I just wanted to follow up on stdeb and the debianize command you added. First of all, thanks! I've just pulled your git head and tried this out in a virtualenv, and it works exactly the way I'd hoped. Combined with some of the other things I'm working out[1] I think this is the way I intend to go. Kudos. I do have a few minor issues, and I'll file bugs on github for each. Also, I'm wondering if you've released a version with the debianize command, and if not when you might do that. I'd like to work on getting that available in Debian, Ubuntu, and my PPA. Cheers, -Barry [1] http://www.wefearchange.org/2010/05/from-python-package-to-ubuntu-package.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From techtonik at gmail.com Fri Jun 11 10:43:29 2010 From: techtonik at gmail.com (anatoly techtonik) Date: Fri, 11 Jun 2010 11:43:29 +0300 Subject: [Distutils] bdist_wininst compatibility with pythons and windows versions In-Reply-To: <4C0C9963.9000203@gmail.com> References: <4C0C9963.9000203@gmail.com> Message-ID: On Mon, Jun 7, 2010 at 10:01 AM, Mark Hammond wrote: >> >> While Trac 0.12 is about to be released, there is some uncertainty >> whenever new Distutils-generated installers are compatible with old >> versions of Windows and Python. There are some fears that installers >> generated on Vista and Windows 7 won't run on XP or 2000. Is that >> true? > > That should be fine. ?pywin32 has used Vista to generate the last few > releases and it installs fine on XP (and probably 2000, but I can't say I > actually tested that recently) > >> Also is there a limit on the lowest version of Python that installer >> generated with Distutils to say 2.6.5 will run? > > I'm not aware of any limitations from 2.2 forwards - if you use the > --target-version option, bdist_wininst should select the appropriate 'stub' > executable for the version you specify (Python 2.6 includes stubs suitable > for most 2.2-ish onwards) build_wininst code [1] function get_exe_bytes() used to fetch appropriate stub, doesn't seem to be cross-platform. More than that - generated installer depends on specific version of MSVC compiler that was used to compile Python. So it seems that there is no compatibility even between one Python version. In addition bdist_wininst generates spurious warning about missing "necessary compiler setting" when run on Linux with an instruction to make sure win32* modules are installed (which are of course not). Even if wininst is strictly windows bdist, the generated .exe contains 'linux' suffix. Given all the above it doesn't really seem that generated installer should work on windows at all. Not even speaking about compatibilities between Python versions or OS versions. Clearly that folks generating installers on Linux doesn't have any way to check this compatibility, so they use an older version that has all sorts of problems with Windows UAC [3]. [1] http://svn.python.org/view/python/trunk/Lib/distutils/command/bdist_wininst.py?revision=77761&view=markup [2] http://bugs.python.org/issue8954 [3] http://bugs.python.org/issue8928 -- anatoly t. From cournape at gmail.com Fri Jun 11 12:39:59 2010 From: cournape at gmail.com (David Cournapeau) Date: Fri, 11 Jun 2010 19:39:59 +0900 Subject: [Distutils] bdist_wininst compatibility with pythons and windows versions In-Reply-To: References: <4C0C9963.9000203@gmail.com> Message-ID: On Fri, Jun 11, 2010 at 5:43 PM, anatoly techtonik wrote: > > In addition bdist_wininst generates spurious warning about missing > "necessary compiler setting" when run on Linux with an instruction to > make sure win32* modules are installed (which are of course not). Use wine and the issue disappears. I built a few official numpy/scipy releases this way, and it works very well. There are issues on 64 bits, but I doubt that's an issue for scons or trac, cheers, David From mhammond at skippinet.com.au Fri Jun 11 12:01:55 2010 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 11 Jun 2010 20:01:55 +1000 Subject: [Distutils] bdist_wininst compatibility with pythons and windows versions In-Reply-To: References: <4C0C9963.9000203@gmail.com> Message-ID: <4C120993.8000707@skippinet.com.au> On 11/06/2010 6:43 PM, anatoly techtonik wrote: > On Mon, Jun 7, 2010 at 10:01 AM, Mark Hammond wrote: > > build_wininst code [1] function get_exe_bytes() used to fetch > appropriate stub, doesn't seem to be cross-platform. Sorry, I must have misunderstood the original question - I was assuming the question was regarding using Windows to generate Windows installers, but for versions of Python other than the version being used to create the installer. > More than that - > generated installer depends on specific version of MSVC compiler that > was used to compile Python. So it seems that there is no compatibility > even between one Python version. That is correct - you can't generate a single exe that works on all Python versions. However, you can use an arbitrary version of Python to create an installer for a different arbitrary version of Python. This is what pywin32 does - it uses Python 2.6/2.7 to create installers for Python 2.3 -> 2.7 - this results in multiple installers, but they are all created using a single python version. The thorn in all this is related to the build process of the extensions - even though Python 2.6 can be used to create all the *installers*, they can't be used to build the individual components inside the installer. ie, the process pywin32 uses for, eg, Python 2.3 is: % python-2.3 setup.py build % python-2.6 setup,py bdist_wininst --target-version=2.3 and the only reason this is done is that the bdist_wininst command in Python 2.6 has enhancements which aren't in 2.3, and the technique above allows me to take advantage of those features in those older versions. > In addition bdist_wininst generates spurious warning about missing > "necessary compiler setting" when run on Linux with an instruction to > make sure win32* modules are installed (which are of course not). Even > if wininst is strictly windows bdist, the generated .exe contains > 'linux' suffix. Given all the above it doesn't really seem that > generated installer should work on windows at all. Not even speaking > about compatibilities between Python versions or OS versions. Clearly > that folks generating installers on Linux doesn't have any way to > check this compatibility, so they use an older version that has all > sorts of problems with Windows UAC [3]. Right - but I think this problem can be considered a bug in distutils rather than an inherent limitation - but in practice you are correct that the inability to build the C components used in the installer means that in practice this really isn't cross-platform. Mark From rambham at gmail.com Sat Jun 12 18:27:13 2010 From: rambham at gmail.com (Ram Bhamidipaty) Date: Sat, 12 Jun 2010 09:27:13 -0700 Subject: [Distutils] need help extending distutils clean class Message-ID: Hi, I am trying to create a custom clean class to use with distutils. The custom class works fine - it does what I want when I run it. But I ran into another problem - if I use the "--help-commands" option I get an exception related to my new class: Traceback (most recent call last): File "./setup.py", line 130, in cmdclass = {"clean" : clean} ) File "/tools/pytoken/python-2.6.2-pytoken/lib/python2.6/distutils/core.py", line 138, in setup ok = dist.parse_command_line() File "/tools/pytoken/python-2.6.2-pytoken/lib/python2.6/distutils/dist.py", line 456, in parse_command_line if self.handle_display_options(option_order): File "/tools/pytoken/python-2.6.2-pytoken/lib/python2.6/distutils/dist.py", line 681, in handle_display_options self.print_commands() File "/tools/pytoken/python-2.6.2-pytoken/lib/python2.6/distutils/dist.py", line 759, in print_commands max_length) File "/tools/pytoken/python-2.6.2-pytoken/lib/python2.6/distutils/dist.py", line 721, in print_command_list klass = self.get_command_class(cmd) File "/tools/pytoken/python-2.6.2-pytoken/lib/python2.6/distutils/dist.py", line 852, in get_command_class raise DistutilsModuleError("invalid command '%s'" % command) distutils.errors.DistutilsModuleError: invalid command 'register' My setup looks like this: setup(name = 'pytoken', version = '1.01', description = 'Generates scanners for python.', author = 'Ram Bhamidipaty', author_email = 'rambham at gmail.com', url = 'http://code.google.com/p/pytoken/', ext_modules = mlist, py_modules = ['pytoken', 'pytoken_ply_lex'], cmdclass = {"clean" : clean} ) my clean class derives from distutils.command.clean. Any suggestions on how to fix this? Thanks for any help. -Ram From aljosa.mohorovic at gmail.com Sun Jun 13 17:12:39 2010 From: aljosa.mohorovic at gmail.com (=?UTF-8?B?QWxqb8WhYSBNb2hvcm92acSH?=) Date: Sun, 13 Jun 2010 17:12:39 +0200 Subject: [Distutils] stable and dev packages - how to always install stable? Message-ID: if i have stable release mypkg with version="0.9" in setup.py and a dev release with version="1.0.dev14" in setup.py how can i make sure that whenever somebody runs "pip install mypkg" it will always install the stable package? Aljosa Mohorovic From merwok at netwok.org Sun Jun 13 21:50:01 2010 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 13 Jun 2010 21:50:01 +0200 Subject: [Distutils] bdist_deb - Debian packager In-Reply-To: <4BDE5509.1060901@astraw.com> References: <4BD9E904.3000509@netwok.org> <4BDE5509.1060901@astraw.com> Message-ID: <4C153669.6040903@netwok.org> Hello again, and sorry for the hiatus > I see, thanks for pointing this out. I thought pkg_resources was in the > stdlib (or on that track). I will investigate. pkg_resources is not in the stdlib. The good ideas from it are moved into pkgutil as we speak , and will be in the standard library when distutils2 is merged back. >> The py2dsc script seems to be obsoleted by the >> to-be ?debian? command. > Can you refer me to the source code and/or documentation for that > command? I was not previously aware of it. I?m sorry, I was referring to a future (?to-be?) distutils2 command based on your work. >> The pypi-install script seems dangerous to me, >> because downloading unverified software and putting it into the system >> seems a rather bad idead (a.k.a. ?sudo ./setup.py install considered >> harmful?). > Yes, some might consider it dangerous, although it does of course > require root privileges before installing anything system-wide (and only > builds the .deb file with user privileges). Nevertheless, it is a useful > tool and safer than "sudo python ./setup.py install" because one can > always do "sudo dpkg --purge python-some-package" to remove that package > again. Well, I?m against sudo too (it trains unix beginners to type their password when asked, and we know that people don?t read text when they just want stuff done), and against doing too much with admin rights :) That said, unix philosophy is about consenting adults (a.k.a. ?yes, you can shoot yourself in the foot?), and since dpkg is able to remove installed files, I have to agree with you that your script can be useful, at least to a class of users that don?t want to use the per-user site-packages directory (assuming they know about it). Also, note that there is ongoing effort to write a generic client to query PyPI, so Alexis (a GSoC student, like me) will probably be interested in your work. I see in stdeb?s README that there are at least two other projects with the same goals. Have you had the opportunity to make a comparison? >> python-debian provides useful support code for generating and reading >> debian formats. A quick read show the code would benefit from some 2.6 >> modernizing (i.e. gain in simplicity and readability by using modern >> idioms and stdlib functions). > Yes, I'm not particularly proud of the code in stdeb -- please feel free > to hack away. Any and all improvements accepted, preferably in > bite-sized commits to a fork on github. I?ve looked at your code once, I think it would benefit from using distutils2. It?s a moving target right now though, perhaps polishing the requirements and waiting before coding is the safe option. Regarding debian-python, its code is under GPLv2 or v3, so inaccessible for Python?s stdlib. We may perhaps ask for relicensing of specific really helpful bits if needs be. Kind regards From cournape at gmail.com Mon Jun 14 08:59:19 2010 From: cournape at gmail.com (David Cournapeau) Date: Mon, 14 Jun 2010 15:59:19 +0900 Subject: [Distutils] Design rationale for the egg format ? Message-ID: Hi, I have a few questions about the egg format implementation, and was hoping people who designed it could answer them: - why does the filename encode some metadata (which python version if the package contains extensions, platform specifier) ? - why are the metadata split into files instead of one single metadata file ? I tried to find a rationale for those, but could not find much info on distutils-sig or setuptools doc, thanks, David From p.f.moore at gmail.com Mon Jun 14 09:34:28 2010 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 14 Jun 2010 08:34:28 +0100 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: References: Message-ID: On 14 June 2010 07:59, David Cournapeau wrote: > Hi, > > I have a few questions about the egg format implementation, and was > hoping people who designed it could answer them: > ?- why does the filename encode some metadata (which python version if > the package contains extensions, platform specifier) ? I'm not one of the designers, nor an expert, but I believe that this is so that the basic metadata can be obtained as part of an initial listdir(), without needing to open and read a file at all - so essentially it's to reduce the number of OS calls needed in certain key cases. Paul. From cournape at gmail.com Mon Jun 14 11:38:48 2010 From: cournape at gmail.com (David Cournapeau) Date: Mon, 14 Jun 2010 18:38:48 +0900 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: References: Message-ID: On Mon, Jun 14, 2010 at 4:34 PM, Paul Moore wrote: > On 14 June 2010 07:59, David Cournapeau wrote: >> Hi, >> >> I have a few questions about the egg format implementation, and was >> hoping people who designed it could answer them: >> ?- why does the filename encode some metadata (which python version if >> the package contains extensions, platform specifier) ? > > I'm not one of the designers, nor an expert, but I believe that this > is so that the basic metadata can be obtained as part of an initial > listdir(), without needing to open and read a file at all - so > essentially it's to reduce the number of OS calls needed in certain > key cases. Do you happen to know what those key cases are ? cheers, David From ben+python at benfinney.id.au Mon Jun 14 12:05:05 2010 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 14 Jun 2010 20:05:05 +1000 Subject: [Distutils] Design rationale for the egg format ? References: Message-ID: <87k4q22alq.fsf@benfinney.id.au> David Cournapeau writes: > I have a few questions about the egg format implementation, and was > hoping people who designed it could answer them: [?] > I tried to find a rationale for those, but could not find much info on > distutils-sig or setuptools doc, You might find it useful to read this archived thread: I've noticed that there seems to be a lot of confusion out there about what setuptools is and/or does, at least among Python-Dev folks, so I thought it might be a good idea to give an overview of its structure, so that people have a better idea of what is and isn't "magic". [?] It goes into some amount of detail on the background and rationale for Setuptools and its early design decisions. -- \ ?Sane people have an appropriate perspective on the relative | `\ importance of foodstuffs and human beings. Crazy people can't | _o__) tell the difference.? ?Paul Z. Myers, 2010-04-18 | Ben Finney From pje at telecommunity.com Mon Jun 14 16:28:03 2010 From: pje at telecommunity.com (P.J. Eby) Date: Mon, 14 Jun 2010 10:28:03 -0400 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: References: Message-ID: <20100614142809.682E63A4119@sparrow.telecommunity.com> At 03:59 PM 6/14/2010 +0900, David Cournapeau wrote: >Hi, > >I have a few questions about the egg format implementation, and was >hoping people who designed it could answer them: > - why does the filename encode some metadata (which python version if >the package contains extensions, platform specifier) ? As Paul mentioned, it's so that discovery can happen without needing anything more than a listdir(). (A legacy of eggs' origin as a binary plugin format.) > - why are the metadata split into files instead of one single > metadata file ? Because that's simpler than trying to define a single universal file format that's forward and backward-compatible with every possible feature and use case. Each use case can have an optimized file format. It also scales better for performance when you have multiple things you might (or might not) be reading. For example, since entry points are separate from dependencies, you you don't need to read the dependencies from an egg that doesn't have an entry point you're scanning for. From NSeigal at lcog.org Mon Jun 14 21:54:55 2010 From: NSeigal at lcog.org (SEIGAL Nick) Date: Mon, 14 Jun 2010 12:54:55 -0700 Subject: [Distutils] Easy install problems Message-ID: <506F591A54F21D4480EE337F77369C0513FE4F70@LCEXG03.lc100.net> I am having trouble using easy install on a Windows Server 2008 server. It seems as thought I am getting blocked from downloading the dependencies. At the command line I get this: C:\Users>easy_install camelot Searching for camelot Best match: camelot 09.12.07 Processing camelot-09.12.07-py2.6.egg camelot 09.12.07 is already the active version in easy-install.pth Installing camelot_manage-script.py script to C:\Python26\Scripts Installing camelot_manage.exe script to C:\Python26\Scripts Installing camelot_manage.exe.manifest script to C:\Python26\Scripts Installing camelot_admin-script.py script to C:\Python26\Scripts Installing camelot_admin.exe script to C:\Python26\Scripts Installing camelot_admin.exe.manifest script to C:\Python26\Scripts Using c:\python26\lib\site-packages\camelot-09.12.07-py2.6.egg Processing dependencies for camelot Searching for Babel>=0.9.4 Reading http://pypi.python.org/simple/Babel/ Download error: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond -- Some packages may not be found! Couldn't find index page for 'Babel' (maybe misspelled?) This process results in a long series of errors at this point. Any suggestions? Nick Seigal GIS Analyst/Application Developer Lane Council of Governments - 859 Willamette Street, Suite 500 - Eugene, Oregon 97401-2910 (541) 682-6733 - (541) 682-4099 (fax) - www.lcog.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Tue Jun 15 03:31:06 2010 From: pje at telecommunity.com (P.J. Eby) Date: Mon, 14 Jun 2010 21:31:06 -0400 Subject: [Distutils] Easy install problems In-Reply-To: <506F591A54F21D4480EE337F77369C0513FE4F70@LCEXG03.lc100.net > References: <506F591A54F21D4480EE337F77369C0513FE4F70@LCEXG03.lc100.net> Message-ID: <20100615013125.BFBC93A4119@sparrow.telecommunity.com> At 12:54 PM 6/14/2010 -0700, SEIGAL Nick wrote: >I am having trouble using easy install on a Windows Server 2008 >server. It seems as thought I am getting blocked from downloading >the dependencies. > >At the command line I get this: > >C:\Users>easy_install camelot >Searching for camelot >Best match: camelot 09.12.07 >Processing camelot-09.12.07-py2.6.egg >camelot 09.12.07 is already the active version in easy-install.pth >Installing camelot_manage-script.py script to C:\Python26\Scripts >Installing camelot_manage.exe script to C:\Python26\Scripts >Installing camelot_manage.exe.manifest script to C:\Python26\Scripts >Installing camelot_admin-script.py script to C:\Python26\Scripts >Installing camelot_admin.exe script to C:\Python26\Scripts >Installing camelot_admin.exe.manifest script to C:\Python26\Scripts > >Using c:\python26\lib\site-packages\camelot-09.12.07-py2.6.egg >Processing dependencies for camelot >Searching for Babel>=0.9.4 >Reading >http://pypi.python.org/simple/Babel/ >Download error: [Errno 10060] A connection attempt failed because >the connected >party did not properly respond after a period of time, or >established connection >failed because connected host has failed to respond -- Some packages >may not be >found! >Couldn't find index page for 'Babel' (maybe misspelled?) > >This process results in a long series of errors at this point. > >Any suggestions? Check your internet settings to see if they're going through a proxy; if so, you'll need to set the http_proxy environment variable, so Python knows how to access the 'net from there. From pje at telecommunity.com Tue Jun 15 03:36:49 2010 From: pje at telecommunity.com (P.J. Eby) Date: Mon, 14 Jun 2010 21:36:49 -0400 Subject: [Distutils] Design rationale for the egg format ? Message-ID: <20100615013652.42F0B3A4119@sparrow.telecommunity.com> At 08:29 AM 6/15/2010 +0900, David Cournapeau wrote: >On Mon, Jun 14, 2010 at 11:28 PM, P.J. Eby wrote: > > At 03:59 PM 6/14/2010 +0900, David Cournapeau wrote: > >> ? - why are the metadata split into files instead of one single metadata > >> file ? > > > > Because that's simpler than trying to define a single universal file format > > that's forward and backward-compatible with every possible feature and use > > case. ? Each use case can have an optimized file format. > > > > It also scales better for performance when you have multiple things you > > might (or might not) be reading. ? For example, since entry points are > > separate from dependencies, you you don't need to read the > dependencies from > > an egg that doesn't have an entry point you're scanning for. > >What I am interested in is the exact situations where this happens >(there is the case where eggs are used as plugins, the case where eggs >are namespace packages, etc...). For example, I don't quite understand >why reading dependencies need to be fast (it does not matter at >install time, so I guess I am missing some usecases) ? As I said above, "it *also* scales better for performance" -- i.e., it's a secondary concern. The #1 reason for separating metadata files is that it makes the addition of new metadata much easier than maintaining a single monolithic format. That is, programs that don't understand new metadata don't have to read it. Plugins that write metadata don't need to co-operate with others - they can just write their own files. And so on. That is the original reason for making separate metadata files: i.e. simplicity. It just turned out to also provide a performance benefit in the case of cross-egg scanning for distinct types of metadata. From greg.ewing at canterbury.ac.nz Tue Jun 15 01:01:08 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 15 Jun 2010 11:01:08 +1200 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: References: Message-ID: <4C16B4B4.1020007@canterbury.ac.nz> Paul Moore wrote: > On 14 June 2010 07:59, David Cournapeau wrote: > >> - why does the filename encode some metadata (which python version if >>the package contains extensions, platform specifier) ? > > I believe that this > is so that the basic metadata can be obtained as part of an initial > listdir() It would also seem useful to be able to keep a collection of versions of a package for different python configurations in the same directory without their names clashing. -- Greg From cournape at gmail.com Tue Jun 15 06:25:28 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 15 Jun 2010 13:25:28 +0900 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: <20100615013633.1B4C63A4119@sparrow.telecommunity.com> References: <20100614142809.682E63A4119@sparrow.telecommunity.com> <20100615013633.1B4C63A4119@sparrow.telecommunity.com> Message-ID: On Tue, Jun 15, 2010 at 10:36 AM, P.J. Eby wrote: > As I said above, "it *also* scales better for performance" -- i.e., it's a > secondary concern. ok. > ?The #1 reason for separating metadata files is that it > makes the addition of new metadata much easier than maintaining a single > monolithic format. Do you still think it is true today ? I am asking because AFAIK, there aren't many packages besides setuptools which use those metadata ? I don't mean to criticize the design, just to see if you would do things differently today. cheers, David From cournape at gmail.com Tue Jun 15 07:51:38 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 15 Jun 2010 14:51:38 +0900 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? Message-ID: Hi, I am interested in adding some metadata in the installers generated by bdist_wininst. I did it through a hack: base64-encoding the medata in a new section in the embedded cfgdata. From my understanding the installer.c sources, this seems safe, and the generated installer does work, but I am wondering whether there is a better way of doing it, and whether it could potentially breaks something, cheers, David From martin at v.loewis.de Tue Jun 15 08:13:34 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 15 Jun 2010 08:13:34 +0200 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? In-Reply-To: References: Message-ID: <4C171A0E.6080203@v.loewis.de> > I am interested in adding some metadata in the installers generated by > bdist_wininst. I did it through a hack: base64-encoding the medata in > a new section in the embedded cfgdata. From my understanding the > installer.c sources, this seems safe, and the generated installer does > work, but I am wondering whether there is a better way of doing it, > and whether it could potentially breaks something, Why not use a file that gets installed in the system? Regards, Martin From cournape at gmail.com Tue Jun 15 08:23:54 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 15 Jun 2010 15:23:54 +0900 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? In-Reply-To: <4C171A0E.6080203@v.loewis.de> References: <4C171A0E.6080203@v.loewis.de> Message-ID: On Tue, Jun 15, 2010 at 3:13 PM, "Martin v. L?wis" wrote: >> I am interested in adding some metadata in the installers generated by >> bdist_wininst. I did it through a hack: base64-encoding the medata in >> a new section in the embedded cfgdata. From my understanding the >> installer.c sources, this seems safe, and the generated installer does >> work, but I am wondering whether there is a better way of doing it, >> and whether it could potentially breaks something, > > Why not use a file that gets installed in the system? Because I don't want the file installed. I am interested in doing this for arbitrary packages (the goal is to add support for egg <-> windows installer conversion in my packaging solution) David From martin at v.loewis.de Tue Jun 15 08:39:39 2010 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 15 Jun 2010 08:39:39 +0200 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? In-Reply-To: References: <4C171A0E.6080203@v.loewis.de> Message-ID: <4C17202B.2030106@v.loewis.de> Am 15.06.2010 08:23, schrieb David Cournapeau: > On Tue, Jun 15, 2010 at 3:13 PM, "Martin v. L?wis" wrote: >>> I am interested in adding some metadata in the installers generated by >>> bdist_wininst. I did it through a hack: base64-encoding the medata in >>> a new section in the embedded cfgdata. From my understanding the >>> installer.c sources, this seems safe, and the generated installer does >>> work, but I am wondering whether there is a better way of doing it, >>> and whether it could potentially breaks something, >> >> Why not use a file that gets installed in the system? > > Because I don't want the file installed. I am interested in doing this > for arbitrary packages (the goal is to add support for egg<-> windows > installer conversion in my packaging solution) Ah. I would then add a prefix META to the scheme, and modify bdist_wininst to skip all files with that prefix. Regards, Martin From cournape at gmail.com Tue Jun 15 08:53:48 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 15 Jun 2010 15:53:48 +0900 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? In-Reply-To: <4C17202B.2030106@v.loewis.de> References: <4C171A0E.6080203@v.loewis.de> <4C17202B.2030106@v.loewis.de> Message-ID: On Tue, Jun 15, 2010 at 3:39 PM, "Martin v. L?wis" wrote: > Am 15.06.2010 08:23, schrieb David Cournapeau: >> >> On Tue, Jun 15, 2010 at 3:13 PM, "Martin v. L?wis" >> ?wrote: >>>> >>>> I am interested in adding some metadata in the installers generated by >>>> bdist_wininst. I did it through a hack: base64-encoding the medata in >>>> a new section in the embedded cfgdata. From my understanding the >>>> installer.c sources, this seems safe, and the generated installer does >>>> work, but I am wondering whether there is a better way of doing it, >>>> and whether it could potentially breaks something, >>> >>> Why not use a file that gets installed in the system? >> >> Because I don't want the file installed. I am interested in doing this >> for arbitrary packages (the goal is to add support for egg<-> ?windows >> installer conversion in my packaging solution) > > Ah. I would then add a prefix META to the scheme, and modify bdist_wininst > to skip all files with that prefix. I did not want to go that road because of the need to recompile bdist_wininst for all python versions, but maybe that's the best solution. Do you think it would make sense to do it for python itself proper (in distutils), so that different implementations could put whatever they want there for their purpose ? cheers, David From martin at v.loewis.de Tue Jun 15 09:33:50 2010 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 15 Jun 2010 09:33:50 +0200 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? In-Reply-To: References: <4C171A0E.6080203@v.loewis.de> <4C17202B.2030106@v.loewis.de> Message-ID: <4C172CDE.2070309@v.loewis.de> > Do you think it would make sense to do it for python itself proper (in > distutils), so that different implementations could put whatever they > want there for their purpose ? I personally never had a need for this. But if you do, go ahead and propose a patch. Regards, Martin From simon at ikanobori.jp Tue Jun 15 17:02:26 2010 From: simon at ikanobori.jp (Simon de Vlieger) Date: Tue, 15 Jun 2010 17:02:26 +0200 Subject: [Distutils] [Catalog-sig] Proposal: Move PyPI static data to the cloud for better availability In-Reply-To: References: <4C1768AF.9040606@egenix.com> <201006160033.46095.steve@pearwood.info> Message-ID: <0E24C79C-F17B-46E3-AA3A-C8CD32C64EF2@ikanobori.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 jun 2010, at 16:42, Mathieu Leduc-Hamel wrote: > I think the most important missed fact is, just how unreliable is PyPI > currently? Does anyone know? > > Exactly my point, right now, since the code is not completely clear > and not tested we don't really know what's supposed to worked and how. > > It's really a problem when the only way you have to know if > something goes wrong is when your users start complaining... Is there any Nagios monitoring in place or is there the need to have some external reliability monitoring in place? I can set up a Nagios machine to check the HTTP status of PyPi. Also, if the earlier described path of PyPi mirroring my the community is chosen I can happily have a server serving PyPi packages in the Netherlands. > > > I don't think this means what you seem to think it means. If you > replace > a single point of failure with N points of failure, your overall > reliability goes down, not up, since there are now more things to go > wrong. Assuming that they're independent points of failure, that means > your total number of failures will increase by a factor of N. > > > This is why we should work on the heart the problem problem, pypi > itself and why it's down sometime. > > Nobody know exactly what happen, maybe it's not a performance > problems. > > As you said, we may have the same problem in the future on all > mirroring nodes ... Yes, there should be some more investigative work be done on the reason of the apparent unreliability. Regards, Simon de Vlieger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJMF5YCAAoJEBBSHP7i+JXfGysP/0IKUsf0KTvjrXn50RvrH2gp jwIpkVfmzbXNGx2EfSywDFNv9neyKqDF844kR2+Vsr96jFnA0EQyUW3nGy7G9q0q bOc2e2GxCauYXDJoGdxGs1S1aS+1z2oyNd2qYZdFDJM236JnKSLHlA3r383cAfDJ bL46SRDeq19IEgOuwjAU9z74+y7t95tomlYX+DgcB4n7cuePCFTym4nWoavjPyE5 4JLN0+Oo6jBf5FwE4WH3e1HWdrbDck7LJTMltB1W2ex6DUPTW9u+tfpc0Bd8DDjP LPcZN2smyqJEFRI89VmLMvwh91wYhAWqGnm42FmgLaKha06SsxxO8b28SSSywYca TZcv+72d59mZSDkF94DtD9CY0Q0feMKN2+O5d3JA8OTb7QosCUNSH8FGE0A3dOk9 jDVlHoQSqYv4FDHrQbLy8pG6A8z9nJK+8Gk3b55mKcfTIFAcYs94WYprY1ZrO42r YLwwF1ngQ9LUuQcJ+7XFpzS/DbNPmXdo5QJuI48usjZrdh6Dub0N0ruaqxWRNOh6 lYz2djbUgUd5xRjG43b0MemRbyiWbb2eZBnvj2+aoCVNXE6xxBpUzzA7FoQvKfSa mF+i//1xKNRxw9ms7WVMDL+FzIxjRrVyEpW0MDKwB3sWkMjjQh8ag2aqIMr6vWKY djCUFH87ofhC+oIIu8Lh =1sDK -----END PGP SIGNATURE----- From agroszer at gmail.com Tue Jun 15 17:20:30 2010 From: agroszer at gmail.com (Adam GROSZER) Date: Tue, 15 Jun 2010 17:20:30 +0200 Subject: [Distutils] setuptools for py 2.7 windows Message-ID: <1026258979.20100615172030@gmail.com> Hello, Someone please make a setuptools-0.6c11.win32-py2.7.exe. -- Best regards, Adam GROSZER mailto:agroszer at gmail.com -- Quote of the day: To do injustice is more disgraceful than to suffer it. - Plato From pje at telecommunity.com Tue Jun 15 20:11:25 2010 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 15 Jun 2010 14:11:25 -0400 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: References: <20100614142809.682E63A4119@sparrow.telecommunity.com> <20100615013633.1B4C63A4119@sparrow.telecommunity.com> Message-ID: <20100615181130.AA73E3A40A5@sparrow.telecommunity.com> At 01:25 PM 6/15/2010 +0900, David Cournapeau wrote: >On Tue, Jun 15, 2010 at 10:36 AM, P.J. Eby wrote: > > > As I said above, "it *also* scales better for performance" -- i.e., it's a > > secondary concern. > >ok. > > > ? The #1 reason for separating metadata files is that it > > makes the addition of new metadata much easier than maintaining a single > > monolithic format. > >Do you still think it is true today ? I am asking because AFAIK, there >aren't many packages besides setuptools which use those metadata ? That depends on what you mean "besides setuptools". Entry points, for example, are used by various apps and frameworks that implement plugins, and these in turn are used by app and plugin developers. There's also a package (EggTranslations I think?) that uses metadata files for i18n discovery, allowing plugins to provide translations for an app, or translations for other plugins. So, it's true that it's not very common that a library or app would directly use metadata files -- in general, you'll go through an intermediary such as setuptools or EggTranslations... or even a third level, such as an app framework that then uses setuptools internally to implement a plugin API. >I >don't mean to criticize the design, just to see if you would do things >differently today. Oh, many things. But separating metadata files is definitely NOT one of them. As you might notice, PEP 376 and Distutils2 build even further on this pattern, with roughly the same rationale(s). From merwok at netwok.org Tue Jun 15 20:15:42 2010 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Tue, 15 Jun 2010 20:15:42 +0200 Subject: [Distutils] Design rationale for the egg format ? In-Reply-To: <20100615181130.AA73E3A40A5@sparrow.telecommunity.com> References: <20100614142809.682E63A4119@sparrow.telecommunity.com> <20100615013633.1B4C63A4119@sparrow.telecommunity.com> <20100615181130.AA73E3A40A5@sparrow.telecommunity.com> Message-ID: <4C17C34E.5000006@netwok.org> >> I don't mean to criticize the design, just to see if you would do things >> differently today. > > Oh, many things. That would make for an interesting read. Regards From pje at telecommunity.com Tue Jun 15 20:15:41 2010 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 15 Jun 2010 14:15:41 -0400 Subject: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ? In-Reply-To: References: Message-ID: <20100615181545.D56E83A40A5@sparrow.telecommunity.com> At 02:51 PM 6/15/2010 +0900, David Cournapeau wrote: >I am interested in doing this for arbitrary packages (the goal is to >add support for egg <-> windows installer conversion in my packaging solution) If your goal is to convert between eggs and bdist_wininst installers, you might want to take a look at the code that already exists in easy_install to convert bdist_wininst .exe files to .egg files -- even ones that weren't built by setuptools. Converting the other way should also be similarly straightforward, so I'm curious what this other metadata is that you're asking about. From pje at telecommunity.com Tue Jun 15 20:16:39 2010 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 15 Jun 2010 14:16:39 -0400 Subject: [Distutils] setuptools for py 2.7 windows In-Reply-To: <1026258979.20100615172030@gmail.com> References: <1026258979.20100615172030@gmail.com> Message-ID: <20100615181643.3724C3A40A5@sparrow.telecommunity.com> At 05:20 PM 6/15/2010 +0200, Adam GROSZER wrote: >Hello, > >Someone please make a setuptools-0.6c11.win32-py2.7.exe. Unzip or untar the source version, then run "setup.py bdist_wininst" - one will then be waiting for you in the dist/ subdirectory. From agroszer at gmail.com Tue Jun 15 21:19:48 2010 From: agroszer at gmail.com (Adam GROSZER) Date: Tue, 15 Jun 2010 21:19:48 +0200 Subject: [Distutils] setuptools for py 2.7 windows In-Reply-To: <20100615181643.3724C3A40A5@sparrow.telecommunity.com> References: <1026258979.20100615172030@gmail.com> <20100615181643.3724C3A40A5@sparrow.telecommunity.com> Message-ID: <357379419.20100615211948@gmail.com> Hello, Well, if you'd be so kind to do the exe and upload it to pypi, you'd save the day for some 50k+ python users (according to the download count of the 2.6 version). Tuesday, June 15, 2010, 8:16:39 PM, you wrote: PJE> At 05:20 PM 6/15/2010 +0200, Adam GROSZER wrote: >>Hello, >> >>Someone please make a setuptools-0.6c11.win32-py2.7.exe. PJE> Unzip or untar the source version, then run "setup.py bdist_wininst" PJE> - one will then be waiting for you in the dist/ subdirectory. PJE> _______________________________________________ PJE> Distutils-SIG maillist - Distutils-SIG at python.org PJE> http://mail.python.org/mailman/listinfo/distutils-sig -- Best regards, Adam GROSZER mailto:agroszer at gmail.com -- Quote of the day: Any sufficiently advanced technology is indistinguishable from magic. From martin at v.loewis.de Tue Jun 15 22:00:18 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 15 Jun 2010 22:00:18 +0200 Subject: [Distutils] [Catalog-sig] Proposal: Move PyPI static data to the cloud for better availability In-Reply-To: <0E24C79C-F17B-46E3-AA3A-C8CD32C64EF2@ikanobori.jp> References: <4C1768AF.9040606@egenix.com> <201006160033.46095.steve@pearwood.info> <0E24C79C-F17B-46E3-AA3A-C8CD32C64EF2@ikanobori.jp> Message-ID: <4C17DBD2.20509@v.loewis.de> > Is there any Nagios monitoring in place or is there the need to have > some external reliability monitoring in place? There is no external monitoring in place that I know of. I know ZC had some monitoring that was supposed to send me an email, but that was setup a few years ago, and recently didn't report the downtime. My own mirroring reported the downtime (indirectly, by reporting that it couldn't mirror anymore); this is how I noticed one of the recent outages. > I can set up a Nagios machine to check the HTTP status of PyPi. If it's easy to setup: why not? What exactly would that check? >> As you said, we may have the same problem in the future on all >> mirroring nodes ... > > Yes, there should be some more investigative work be done on the reason > of the apparent unreliability. The pep381mirror software produces a set of static files on the mirror, so you don't need to run PyPI itself. I merely use Apache to serve the PyPI mirrors. Regards, Martin From dionysos_13 at yahoo.fr Wed Jun 16 00:26:18 2010 From: dionysos_13 at yahoo.fr (Denis Jasselette) Date: Wed, 16 Jun 2010 00:26:18 +0200 Subject: [Distutils] Equivalent of config.h? Message-ID: <1276640778.10526.21.camel@denis-laptop> Hi, I use the GNU Autotools when I program in C. They generate a config.h file containing useful information such as the PACKAGE_VERSION that can be retrieved by simply including the file. I'd like to know if there exists anything similar with distutils. I am trying to distribute a script where I should be able to output the current version number. I thought that I could do things in an opposite way as in C. Rather than having the building system to create the config.h, I could import a config.py in my setup.py and distribute it as a py_module along with the script. Do you have better solutions? From pje at telecommunity.com Wed Jun 16 01:43:41 2010 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 15 Jun 2010 19:43:41 -0400 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <1276640778.10526.21.camel@denis-laptop> References: <1276640778.10526.21.camel@denis-laptop> Message-ID: <20100615234346.B03E13A40A5@sparrow.telecommunity.com> At 12:26 AM 6/16/2010 +0200, Denis Jasselette wrote: >I am trying to distribute a >script where I should be able to output the current version number. > >I thought that I could do things in an opposite way as in C. Rather than >having the building system to create the config.h, I could import a >config.py in my setup.py and distribute it as a py_module along with the >script. > >Do you have better solutions? Yes. Use setuptools in your setup.py, and declare the version there. Then, in your script, use: from pkg_resources import require my_version = require('MyProjectName')[0].version Where 'MyProjectName' is whatever 'name=' argument you passed to setup() in your setup.py. From merwok at netwok.org Wed Jun 16 01:49:07 2010 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 16 Jun 2010 01:49:07 +0200 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <1276640778.10526.21.camel@denis-laptop> References: <1276640778.10526.21.camel@denis-laptop> Message-ID: <4C181173.8010001@netwok.org> Hello If your script has taken care of separating functions and the mail call in a ?if __name__ == '__main__'? block, you can just import your script and get its __version__ attribute. Regards From merwok at netwok.org Wed Jun 16 02:00:46 2010 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 16 Jun 2010 02:00:46 +0200 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <4C181173.8010001@netwok.org> References: <1276640778.10526.21.camel@denis-laptop> <4C181173.8010001@netwok.org> Message-ID: <4C18142E.8090609@netwok.org> Duh. s/mail call/main call/ From cournape at gmail.com Wed Jun 16 03:55:32 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 16 Jun 2010 10:55:32 +0900 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <1276640778.10526.21.camel@denis-laptop> References: <1276640778.10526.21.camel@denis-laptop> Message-ID: On Wed, Jun 16, 2010 at 7:26 AM, Denis Jasselette wrote: > > Do you have better solutions? This is a perfectly fine solution. It is simple, and does not requires any 3rd party code. David From dionysos_13 at yahoo.fr Wed Jun 16 16:29:37 2010 From: dionysos_13 at yahoo.fr (Denis Jasselette) Date: Wed, 16 Jun 2010 16:29:37 +0200 Subject: [Distutils] Equivalent of config.h? In-Reply-To: References: <1276640778.10526.21.camel@denis-laptop> Message-ID: <1276698577.1672.51.camel@denis-laptop> ?ric Araujo wrote: > If your script has taken care of separating functions and the mail > call > in a ?if __name__ == '__main__'? block, you can just import your > script > and get its __version__ attribute. It was my first guess but then, I would have to rename my script with a .py extension. Which is not great in an executable name. P.J. Eby wrote: > Yes. Use setuptools in your setup.py, and declare the version > there. Then, in your script, use: > > from pkg_resources import require > my_version = require('MyProjectName')[0].version > > Where 'MyProjectName' is whatever 'name=' argument you passed to > setup() in your setup.py. It works. However, I'd rather not force users to install setuptools if possible. David Cournapeau wrote: > This is a perfectly fine solution. It is simple, and does not requires > any 3rd party code. It doesn't seem very clean though. But I suppose I could live with that. I have another problem with this solution. Distutils seems to set permissions of py_modules to non-world-readable. Meaning that, as I have to launch the installation as root, I can't read it unless I launch the script as root as well. The weird part is that the script's permissions are just fine. From cournape at gmail.com Wed Jun 16 16:52:27 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 16 Jun 2010 23:52:27 +0900 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <1276698577.1672.51.camel@denis-laptop> References: <1276640778.10526.21.camel@denis-laptop> <1276698577.1672.51.camel@denis-laptop> Message-ID: On Wed, Jun 16, 2010 at 11:29 PM, Denis Jasselette wrote: > ?ric Araujo wrote: >> If your script has taken care of separating functions and the mail >> call >> in a ?if __name__ == '__main__'? block, you can just import your >> script >> and get its __version__ attribute. > > It was my first guess but then, I would have to rename my script with > a .py extension. Which is not great in an executable name. > > P.J. Eby wrote: >> Yes. ?Use setuptools in your setup.py, and declare the version >> there. ?Then, in your script, use: >> >> ? ? from pkg_resources import require >> ? ? my_version = require('MyProjectName')[0].version >> >> Where 'MyProjectName' is whatever 'name=' argument you passed to >> setup() in your setup.py. > > It works. However, I'd rather not force users to install setuptools if > possible. > > David Cournapeau wrote: >> This is a perfectly fine solution. It is simple, and does not requires >> any 3rd party code. > > It doesn't seem very clean though. I guess it is a matter of opinion, but I find it clearer than the other suggested solutions. > I have another problem with this solution. Distutils seems to set > permissions of py_modules to non-world-readable. Meaning that, as I have > to launch the installation as root, I can't read it unless I launch the > script as root as well. The weird part is that the script's permissions > are just fine. What OS are you using and which set of commands did you exactly use ? David From dionysos_13 at yahoo.fr Wed Jun 16 17:19:06 2010 From: dionysos_13 at yahoo.fr (Denis Jasselette) Date: Wed, 16 Jun 2010 17:19:06 +0200 Subject: [Distutils] Equivalent of config.h? In-Reply-To: References: <1276640778.10526.21.camel@denis-laptop> <1276698577.1672.51.camel@denis-laptop> Message-ID: <1276701546.1672.75.camel@denis-laptop> > What OS are you using and which set of commands did you exactly use ? I am using Ubuntu 10.04 (python 2.6). And here is what I did: $ ll -rwxr-xr-x 1 denis denis 396 2010-06-16 14:39 setup.py -rwxr-xr-x 1 denis denis 10K 2010-06-16 14:13 teqhtml -rw-r--r-- 1 denis denis 203 2010-06-16 14:11 teqhtml_config.py $ ./setup.py build [...] $ sudo ./setup.py install [...] $ ll /usr/local/bin/ -rwxr-xr-x 1 root root 10K 2010-06-16 17:06 teqhtml $ ll /usr/local/lib/python2.6/dist-packages/ -rw------- 1 root staff 281 2010-06-16 17:06 teqhtml-0.5.egg-info -rw------- 1 root staff 203 2010-06-16 14:11 teqhtml_config.py -rw------- 1 root staff 562 2010-06-16 17:06 teqhtml_config.pyc Actually, install doesn't change permissions, they are set while building. It looks like the umask is taken into account for py_modules but permissions are explicitly changed for scripts. If I set my umask to 0000 for instance, I don't have that problem. From simon at ikanobori.jp Wed Jun 16 23:14:11 2010 From: simon at ikanobori.jp (Simon de Vlieger) Date: Wed, 16 Jun 2010 23:14:11 +0200 Subject: [Distutils] PyPI template improvements Message-ID: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, the recent activity on this mailinglist has kickstarted my contributing sense. As long as the mirroring debate is still ongoing I will focus my efforts somewhere else. Namely: the HTML/Javascript/CSS. In this regard I have a few questions before I really dig into these templates: - - Is there a list of improvements, maybe a nice TODO of points which people want to see improved? - - How are design changes handled, is there a committee to run them through? People who decide on what gets in and what not? (I'll outline some of my first thoughts lower in this mail) - - What are the supported browser versions by PyPI, I reckon it's IE6/7/8+, Fx 2+, Opera 9+ Safari 4+? The changes I have on my personal 'todo list' are: - - Add labels to all forms. - - Make tables consistent width (see for example the table in the top of the "Browse packages" page and compare with the table when you actually select one of the classifiers). - - Restyle the metadata display on package pages and move it up in the page. - - Have downloads readily available on the right side of the screen (at least the latest release). - - Look sternly at the top right floating account information page. - - Look at the your details page where the form does not align with the right floating profile box. - - Make one consistent styling for all forms. Include help texts in all forms. There are more things I want to do, but this is the start. I have already cloned Tarek's PyPI clone on Bitbucket and I'll add my changes there. Is there anything you guys (and the users) would really like to see improved? Regards, Simon de Vlieger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJMGT6kAAoJEBBSHP7i+JXfHmsQALbm5rqRpLdjTDWNHLQHqoVE D4rDht/oaOFwPBfWp2FMRIhqLa9yA2AQfEAWSBFLqNMr2FGwpRPAXGgd38VOKOf0 pTORXM7cw92yjQXFz4J4xvcN7IcmyYEfftbwlITStnAEc5Q/5sl93nxyyigyQr7D y62EfCRGQP/OTfU7PYoj1KS9Qwi4ep6saD1cdL+tM7AgPiGwJMU2f29vElMVvT1G of+3gZjEi/UpsiYP/qD3JW3iFoOKv3KJbMmdHfMaPCa/vyfGRBoM4eGf5XvV+3oy U6EJ3YvvvTTS/w+TR36USxonuspYWKxoku1hUDaRsDgUC1fdW1UWVtocvnGzr1JW j06KN19ypzVK6UFoRTTsbA6K3h/pppgO1MIH9iAQgkvNY/irZiACO//x6bLT7ZFr 3PRt2ZaJzutKpUT0dGf0HjqcXdF6tPGnaQK1kkBGIgJrtXgqHqmc6Ee4S3Kd/boD tS9ZVqtIB2npJR4e0ZA6iqqGCNvpJlQEiUXSIpmTBRIgvpIjGcA/DQ+rQSIY8twS KPMGdnLm9u0HJdmlsRvJvH6/FBYIhoWDYWulil8ZpZnjHsyLAfTQjNeWzQDylEKF O750a9QgRIbeEFIOZK1kkaccy0dL3oX4MqJBfLlaJUlBJ0pYq3jTXf9+kc6g+uGc hutNfaPX84pe/oxL/z8k =hMyY -----END PGP SIGNATURE----- From merwok at netwok.org Wed Jun 16 23:47:41 2010 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 16 Jun 2010 23:47:41 +0200 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <1276640778.10526.21.camel@denis-laptop> References: <1276640778.10526.21.camel@denis-laptop> Message-ID: <4C19467D.4030904@netwok.org> There is another solution that doesn?t require the overkill of adding a mostly useless module or switching away from standard distutils: You can grep for ?__version__ = ? in your script (either with real grep or a few lines of Python). Not sure this caters to your use case, but at least it?s recorded in the thread. Regards From cournape at gmail.com Thu Jun 17 04:00:35 2010 From: cournape at gmail.com (David Cournapeau) Date: Thu, 17 Jun 2010 11:00:35 +0900 Subject: [Distutils] Equivalent of config.h? In-Reply-To: <1276701546.1672.75.camel@denis-laptop> References: <1276640778.10526.21.camel@denis-laptop> <1276698577.1672.51.camel@denis-laptop> <1276701546.1672.75.camel@denis-laptop> Message-ID: On Thu, Jun 17, 2010 at 12:19 AM, Denis Jasselette wrote: >> What OS are you using and which set of commands did you exactly use ? > > I am using Ubuntu 10.04 (python 2.6). And here is what I did: > > ? ? ? ?$ ll > ? ? ? ?-rwxr-xr-x 1 denis denis 396 2010-06-16 14:39 setup.py > ? ? ? ?-rwxr-xr-x 1 denis denis 10K 2010-06-16 14:13 teqhtml > ? ? ? ?-rw-r--r-- 1 denis denis 203 2010-06-16 14:11 teqhtml_config.py > ? ? ? ?$ ./setup.py build > ? ? ? ?[...] > ? ? ? ?$ sudo ./setup.py install > ? ? ? ?[...] > ? ? ? ?$ ll /usr/local/bin/ > ? ? ? ?-rwxr-xr-x 1 root root 10K 2010-06-16 17:06 teqhtml > ? ? ? ?$ ll /usr/local/lib/python2.6/dist-packages/ > ? ? ? ?-rw------- 1 root staff 281 2010-06-16 17:06 > ? ? ? ?teqhtml-0.5.egg-info > ? ? ? ?-rw------- 1 root staff 203 2010-06-16 14:11 teqhtml_config.py > ? ? ? ?-rw------- 1 root staff 562 2010-06-16 17:06 teqhtml_config.pyc > > Actually, install doesn't change permissions, they are set while > building. It looks like the umask is taken into account for py_modules > but permissions are explicitly changed for scripts. If I set my umask to > 0000 for instance, I don't have that problem. What is your umask (when the .py are non world-readable) ? I believe sudo has a different way of handling umask (compared to using straight root account). You could try installing as root instead of using sudo, and/or checking your sudoers for umask settings, David From barry at python.org Thu Jun 17 17:38:20 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 17 Jun 2010 11:38:20 -0400 Subject: [Distutils] PyPI template improvements In-Reply-To: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> References: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> Message-ID: <20100617113820.3c23b7af@heresy> On Jun 16, 2010, at 11:14 PM, Simon de Vlieger wrote: >the recent activity on this mailinglist has kickstarted my >contributing sense. As long as the mirroring debate is still ongoing I >will focus my efforts somewhere else. Namely: the HTML/Javascript/CSS. Hi Simon, nice to see the Cheeseshop get some new love. I can't answer too many of your questions, but here's an issue I would really love to be solved. I can't imagine it's that difficult: https://sourceforge.net/tracker/?func=detail&aid=3017638&group_id=66150&atid=513503 This requests that when a package has uploaded documentation, that the Cheeseshop page for the package automatically link to the documentation page. >- - What are the supported browser versions by PyPI, I reckon it's >IE6/7/8+, Fx 2+, Opera 9+ Safari 4+? Can you add Chromium 5 to that list? Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ianb at colorstudy.com Thu Jun 17 19:56:27 2010 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 17 Jun 2010 12:56:27 -0500 Subject: [Distutils] PyPI template improvements In-Reply-To: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> References: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> Message-ID: Two from me: * Make the textareas not do a hard wrap in the package info edit screen. Right now you can't edit (or even save without editing) the metadata for packages with long lines without breaking them, which includes breaking long URLs. * Kind of relatedly, make long descriptions wrap in some fashion. Right now if you have a plain-text long_description for your project without newlines it just gets really wide. I think that'd be fixable with just CSS. On Wed, Jun 16, 2010 at 4:14 PM, Simon de Vlieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey all, > > the recent activity on this mailinglist has kickstarted my contributing > sense. As long as the mirroring debate is still ongoing I will focus my > efforts somewhere else. Namely: the HTML/Javascript/CSS. > > In this regard I have a few questions before I really dig into these > templates: > > - - Is there a list of improvements, maybe a nice TODO of points which > people want to see improved? > - - How are design changes handled, is there a committee to run them > through? People who decide on what gets in and what not? (I'll outline some > of my first thoughts lower in this mail) > - - What are the supported browser versions by PyPI, I reckon it's > IE6/7/8+, Fx 2+, Opera 9+ Safari 4+? > > The changes I have on my personal 'todo list' are: > - - Add labels to all forms. > - - Make tables consistent width (see for example the table in the top of > the "Browse packages" page and compare with the table when you actually > select one of the classifiers). > - - Restyle the metadata display on package pages and move it up in the > page. > - - Have downloads readily available on the right side of the screen (at > least the latest release). > - - Look sternly at the top right floating account information page. > - - Look at the your details page where the form does not align with the > right floating profile box. > - - Make one consistent styling for all forms. Include help texts in all > forms. > > There are more things I want to do, but this is the start. > > I have already cloned Tarek's PyPI clone on Bitbucket and I'll add my > changes there. > > Is there anything you guys (and the users) would really like to see > improved? > > Regards, > > Simon de Vlieger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > > iQIcBAEBAgAGBQJMGT6kAAoJEBBSHP7i+JXfHmsQALbm5rqRpLdjTDWNHLQHqoVE > D4rDht/oaOFwPBfWp2FMRIhqLa9yA2AQfEAWSBFLqNMr2FGwpRPAXGgd38VOKOf0 > pTORXM7cw92yjQXFz4J4xvcN7IcmyYEfftbwlITStnAEc5Q/5sl93nxyyigyQr7D > y62EfCRGQP/OTfU7PYoj1KS9Qwi4ep6saD1cdL+tM7AgPiGwJMU2f29vElMVvT1G > of+3gZjEi/UpsiYP/qD3JW3iFoOKv3KJbMmdHfMaPCa/vyfGRBoM4eGf5XvV+3oy > U6EJ3YvvvTTS/w+TR36USxonuspYWKxoku1hUDaRsDgUC1fdW1UWVtocvnGzr1JW > j06KN19ypzVK6UFoRTTsbA6K3h/pppgO1MIH9iAQgkvNY/irZiACO//x6bLT7ZFr > 3PRt2ZaJzutKpUT0dGf0HjqcXdF6tPGnaQK1kkBGIgJrtXgqHqmc6Ee4S3Kd/boD > tS9ZVqtIB2npJR4e0ZA6iqqGCNvpJlQEiUXSIpmTBRIgvpIjGcA/DQ+rQSIY8twS > KPMGdnLm9u0HJdmlsRvJvH6/FBYIhoWDYWulil8ZpZnjHsyLAfTQjNeWzQDylEKF > O750a9QgRIbeEFIOZK1kkaccy0dL3oX4MqJBfLlaJUlBJ0pYq3jTXf9+kc6g+uGc > hutNfaPX84pe/oxL/z8k > =hMyY > -----END PGP SIGNATURE----- > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Ian Bicking | http://blog.ianbicking.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Jun 17 20:15:20 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 17 Jun 2010 14:15:20 -0400 Subject: [Distutils] PyPI template improvements In-Reply-To: References: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> Message-ID: <20100617141520.52168739@heresy> On Jun 17, 2010, at 12:56 PM, Ian Bicking wrote: >* Kind of relatedly, make long descriptions wrap in some fashion. Right now >if you have a plain-text long_description for your project without newlines >it just gets really wide. I think that'd be fixable with just CSS. How about supporting reST in descriptions? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ianb at colorstudy.com Thu Jun 17 20:29:36 2010 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 17 Jun 2010 13:29:36 -0500 Subject: [Distutils] PyPI template improvements In-Reply-To: <20100617141520.52168739@heresy> References: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp> <20100617141520.52168739@heresy> Message-ID: On Thu, Jun 17, 2010 at 1:15 PM, Barry Warsaw wrote: > On Jun 17, 2010, at 12:56 PM, Ian Bicking wrote: > > >* Kind of relatedly, make long descriptions wrap in some fashion. Right > now > >if you have a plain-text long_description for your project without > newlines > >it just gets really wide. I think that'd be fixable with just CSS. > > How about supporting reST in descriptions? > It is supported, but if something doesn't render cleanly as reST it is treated as plain text and wrapped in an unwrapping 
.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From regebro at gmail.com  Fri Jun 18 08:24:39 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Jun 2010 08:24:39 +0200
Subject: [Distutils] setuptools for py 2.7 windows
In-Reply-To: <1026258979.20100615172030@gmail.com>
References: <1026258979.20100615172030@gmail.com>
Message-ID: 

On Tue, Jun 15, 2010 at 17:20, Adam GROSZER  wrote:
> Hello,
>
> Someone please make a setuptools-0.6c11.win32-py2.7.exe.

Just out of interest: Why are these versions needed? Their isn't any
C-code in setuptools, doesn't the source version work just as well?

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From martin at v.loewis.de  Fri Jun 18 08:35:00 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 18 Jun 2010 08:35:00 +0200
Subject: [Distutils] setuptools for py 2.7 windows
In-Reply-To: 
References: <1026258979.20100615172030@gmail.com>
	
Message-ID: <4C1B1394.3030107@v.loewis.de>

Am 18.06.2010 08:24, schrieb Lennart Regebro:
> On Tue, Jun 15, 2010 at 17:20, Adam GROSZER  wrote:
>> Hello,
>>
>> Someone please make a setuptools-0.6c11.win32-py2.7.exe.
>
> Just out of interest: Why are these versions needed? Their isn't any
> C-code in setuptools, doesn't the source version work just as well?

You get uninstallation through add-remove-programs.

Of course, users could create them easily themselves if they knew how to 
(python setup.py bdist_wininst).

Regards,
Martin

From simon at ikanobori.jp  Fri Jun 18 08:51:34 2010
From: simon at ikanobori.jp (Simon de Vlieger)
Date: Fri, 18 Jun 2010 08:51:34 +0200
Subject: [Distutils] PyPI template improvements
In-Reply-To: <20100617113820.3c23b7af@heresy>
References: <4BB43B0A-94C0-4C44-849D-0CEC47D8F958@ikanobori.jp>
	<20100617113820.3c23b7af@heresy>
Message-ID: <9FB7DCF5-AD7B-4552-8646-5BB248EDED13@ikanobori.jp>

On 17 jun 2010, at 17:38, Barry Warsaw wrote:

> This requests that when a package has uploaded documentation, that the
> Cheeseshop page for the package automatically link to the  
> documentation page.

I'll look into this.

On 17 jun 2010, at 17:38, Barry Warsaw wrote:

> Can you add Chromium 5 to that list?

This as well (it's another webkit browser but I will test it  
specifically).

On 17 jun 2010, at 19:56, Ian Bicking wrote:

> * Make the textareas not do a hard wrap in the package info edit  
> screen.  Right now you can't edit (or even save without editing) the  
> metadata for packages with long lines without breaking them, which  
> includes breaking long URLs.

I'll look into this.


> * Kind of relatedly, make long descriptions wrap in some fashion.   
> Right now if you have a plain-text long_description for your project  
> without newlines it just gets really wide.  I think that'd be  
> fixable with just CSS.

It will be fixable with just CSS.

It seems I have compiled a nice list of things to fix over the weekend  
and I'll rummage in the sourceforge issues list to find some more HTML- 
related issues.  I'll let the appropriate people know when I finish my  
patches and I'll discuss further template adjustments (in the design  
area) with the more appropriate catalog-sig list.

Regards,

Simon de Vlieger




From agroszer at gmail.com  Fri Jun 18 09:13:14 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Fri, 18 Jun 2010 09:13:14 +0200
Subject: [Distutils] setuptools for py 2.7 windows
In-Reply-To: <4C1B1394.3030107@v.loewis.de>
References: <1026258979.20100615172030@gmail.com>
	
	<4C1B1394.3030107@v.loewis.de>
Message-ID: <1548890243.20100618091314@gmail.com>

Hello,

It's also like a habit... installers exist for 2.4, 2.5, ...
One just misses 2.7.

Friday, June 18, 2010, 8:35:00 AM, you wrote:

MvL> Am 18.06.2010 08:24, schrieb Lennart Regebro:
>> On Tue, Jun 15, 2010 at 17:20, Adam GROSZER  wrote:
>>> Hello,
>>>
>>> Someone please make a setuptools-0.6c11.win32-py2.7.exe.
>>
>> Just out of interest: Why are these versions needed? Their isn't any
>> C-code in setuptools, doesn't the source version work just as well?

MvL> You get uninstallation through add-remove-programs.

MvL> Of course, users could create them easily themselves if they knew how to
MvL> (python setup.py bdist_wininst).

MvL> Regards,
MvL> Martin


-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Courage is your greatest present need.


From p.f.moore at gmail.com  Fri Jun 18 09:35:30 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 18 Jun 2010 08:35:30 +0100
Subject: [Distutils] setuptools for py 2.7 windows
In-Reply-To: <1548890243.20100618091314@gmail.com>
References: <1026258979.20100615172030@gmail.com>
	
	<4C1B1394.3030107@v.loewis.de>
	<1548890243.20100618091314@gmail.com>
Message-ID: 

On 18 June 2010 08:13, Adam GROSZER  wrote:
> Hello,
>
> It's also like a habit... installers exist for 2.4, 2.5, ...
> One just misses 2.7.

And of course, the irony is that "pure distutils" bdist_wininst
installers are not python version specific. It's setuptools itself
that modifies bdist_wininst to make the installers it builds python
version specific ;-)

Paul.

From gnarea at tech.2degreesnetwork.com  Fri Jun 18 18:11:04 2010
From: gnarea at tech.2degreesnetwork.com (Gustavo Narea)
Date: Fri, 18 Jun 2010 17:11:04 +0100
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
Message-ID: <4C1B9A98.2030905@tech.2degreesnetwork.com>

Hello,

I have a Bash script that wraps our custom-compiled Python interpreter
to set a couple of required variables, but Buildout is failing to
install dependencies when that wrapper is used.

The Bash script looks like this:
----
#!/bin/bash
export PYTHONHOME="${HOME}/.twod/pythons/2.5.5"
export LD_LIBRARY_PATH="${PYTHONHOME}/lib:${LD_LIBRARY_PATH}"

exec ${PYTHONHOME}/bin/python "$@"
---

It works like a charm for everything but Buildout. This is what I get
when I run it with log-level=DEBUG:
---
...
Getting required 'django-audit==1.0b1'
   required by foo.
We have no distributions for django-audit that satisfies
'django-audit==1.0b1'.
Getting distribution for 'django-audit==1.0b1'.
Running
easy_install:                                                                                                                                                                         

/bin/bash /home/gustavo/.twod/pythons/2.5.5/bin/python-wrapper "-c"
"from setuptools.command.easy_install import main; main()" "-mUNxd"
"/home/gustavo/.twod/pythons/2.5.5/buildout-eggs/tmp4binwi" "-Z" "-q"
"/home/gustavo/.buildout/downloads/dist/django-audit-1.0b1.tar.gz"                                                                                                                         

path=/home/gustavo/System/Pyenvs/twod-trunk/eggs/distribute-0.6.13-py2.5.egg                                                                                                                  

                                                                                                                                                                                              

An error occured when trying to install django-audit 1.0b1. Look above
this message for any errors that were output by
easy_install.                                                          
While:                                                                                                                                                                                        

 
Installing.                                                                                                                                                                                 

  Getting section
scripts.                                                                                                                                                                    

  Initializing section
scripts.                                                                                                                                                               

  Getting option
scripts:initialization.                                                                                                                                                      

  Getting section
twod_vars.                                                                                                                                                                  

  Initializing part
twod_vars.                                                                                                                                                                

  Getting distribution for
'django-audit==1.0b1'.                                                                                                                                             

Error: Couldn't install: django-audit 1.0b1
---

If I run manually the command Buildout is running, it works:
/bin/bash /home/gustavo/.twod/pythons/2.5.5/bin/python-wrapper "-c"
"from setuptools.command.easy_install import main; main()" "-mUNxd"
"/home/gustavo/.twod/pythons/2.5.5/buildout-eggs/tmp4binwi" "-Z" "-q"
"/home/gustavo/.buildout/downloads/dist/django-audit-1.0b1.tar.gz"

Why doesn't it work within Buildout? How can I make it give a more
detailed description of the error?

I have the following in buildout.cfg:
---
[buildout]
...
executable = /bin/bash /home/gustavo/.twod/pythons/2.5.5/bin/python-wrapper
---

Thanks in advance.

PS: I need to set $PYTHONHOME and $LD_LIBRARY_PATH because we require
Python 2.5.5 with --enable-shared.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .


From gnarea at tech.2degreesnetwork.com  Fri Jun 18 18:19:35 2010
From: gnarea at tech.2degreesnetwork.com (Gustavo Narea)
Date: Fri, 18 Jun 2010 17:19:35 +0100
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <4C1B9A98.2030905@tech.2degreesnetwork.com>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>
Message-ID: <4C1B9C97.50200@tech.2degreesnetwork.com>

On 18/06/10 17:11, Gustavo Narea wrote:
> It works like a charm for everything but Buildout. This is what I get
> when I run it with log-level=DEBUG:
> ---
> ...
> Getting required 'django-audit==1.0b1'
>    required by foo.
> We have no distributions for django-audit that satisfies
> 'django-audit==1.0b1'.
> Getting distribution for 'django-audit==1.0b1'.
> Running
> easy_install:               
> /bin/bash /home/gustavo/.twod/pythons/2.5.5/bin/python-wrapper "-c"
> "from setuptools.command.easy_install import main; main()" "-mUNxd"
> "/home/gustavo/.twod/pythons/2.5.5/buildout-eggs/tmp4binwi" "-Z" "-q"
> "/home/gustavo/.buildout/downloads/dist/django-audit-1.0b1.tar.gz"            
> path=/home/gustavo/System/Pyenvs/twod-trunk/eggs/distribute-0.6.13-py2.5.egg                     
> An error occured when trying to install django-audit 1.0b1. Look above
> this message for any errors that were output by
> easy_install.                                                          
> While:                      
> Installing.      
>   Getting section
> scripts.              
>   Initializing section
> scripts.                
>   Getting option
> scripts:initialization.    
>   Getting section
> twod_vars.        
>   Initializing part
> twod_vars.         
>   Getting distribution for
> 'django-audit==1.0b1'.                                                                                                                                             
>
> Error: Couldn't install: django-audit 1.0b1
>   

By the way, this problem occurs with a few packages. django-audit is one
of them and it used to be installed perfectly before introducing the
wrapper.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From marius at pov.lt  Fri Jun 18 18:38:42 2010
From: marius at pov.lt (Marius Gedminas)
Date: Fri, 18 Jun 2010 19:38:42 +0300
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <4C1B9A98.2030905@tech.2degreesnetwork.com>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>
Message-ID: <20100618163842.GA28991@fridge.pov.lt>

On Fri, Jun 18, 2010 at 05:11:04PM +0100, Gustavo Narea wrote:
> I have a Bash script that wraps our custom-compiled Python interpreter
> to set a couple of required variables, but Buildout is failing to
> install dependencies when that wrapper is used.

Unfortunately this approach will not work.

Buildout generates scripts in bin/ that will try to use your Python as
the interpreter in the #! line.  Linux requires that the interpreter be
a real executable and won't accept a script there.

Marius Gedminas
-- 
Si fractum non sit, noli id reficere.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 

From dionysos_13 at yahoo.fr  Fri Jun 18 19:14:48 2010
From: dionysos_13 at yahoo.fr (Denis Jasselette)
Date: Fri, 18 Jun 2010 19:14:48 +0200
Subject: [Distutils] Equivalent of config.h?
In-Reply-To: 
References: <1276640778.10526.21.camel@denis-laptop>
	
	<1276698577.1672.51.camel@denis-laptop>
	
	<1276701546.1672.75.camel@denis-laptop>
	
Message-ID: <1276881288.6380.13.camel@denis-laptop>

David Cournapeau wrote : 
> What is your umask (when the .py are non world-readable) ? I believe
> sudo has a different way of handling umask (compared to using straight
> root account). You could try installing as root instead of using sudo,
> and/or checking your sudoers for umask settings,

My umask is 0077 and it's set globally, i.e., for the root account as
well. I don't know exactly how sudo deals with it. However, I don't
think sudo is the problem here, as I said before, permissions are set
during the building.

Anyway, I solved this by setting a less restrictive umask (if available)
explicitly in setup.py.


From suresh_vv at yahoo.com  Fri Jun 18 19:12:05 2010
From: suresh_vv at yahoo.com (Suresh V.)
Date: Fri, 18 Jun 2010 22:42:05 +0530
Subject: [Distutils] Buildout: Funky syntax for Extending sections (macros)
Message-ID: 

Why does buildout use the "<=" syntax for this? Wouldn't it be nicer to 
just overload "extends"?

I do appreciate this feature!

Suresh


From jim at zope.com  Fri Jun 18 19:20:09 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 18 Jun 2010 13:20:09 -0400
Subject: [Distutils] Buildout: Funky syntax for Extending sections
	(macros)
In-Reply-To: 
References: 
Message-ID: 

On Fri, Jun 18, 2010 at 1:12 PM, Suresh V.  wrote:
> Why does buildout use the "<=" syntax for this? Wouldn't it be nicer to just
> overload "extends"?

Someone might already have been using this name. In fact, I knew of
some recipes that did.

I chose that syntax because it conveyed flow of information from the
named section, as in:

  [bar]
  <= foo

which can be read as "bar gets data from foo".  

Jim

-- 
Jim Fulton

From dionysos_13 at yahoo.fr  Fri Jun 18 19:23:08 2010
From: dionysos_13 at yahoo.fr (Denis Jasselette)
Date: Fri, 18 Jun 2010 19:23:08 +0200
Subject: [Distutils] Equivalent of config.h?
In-Reply-To: <4C19467D.4030904@netwok.org>
References: <1276640778.10526.21.camel@denis-laptop>
	<4C19467D.4030904@netwok.org>
Message-ID: <1276881788.6380.22.camel@denis-laptop>

?ric Araujo wrote : 
> There is another solution that doesn?t require the overkill of adding a
> mostly useless module or switching away from standard distutils: You can
> grep for ?__version__ = ? in your script (either with real grep or a few
> lines of Python). Not sure this caters to your use case, but at least
> it?s recorded in the thread.

`overkill' is just the right term ^^. I like this solution, even though
it's a bit rough. I finally did this (using a python implementation for
portability reasons).


From arfrever.fta at gmail.com  Fri Jun 18 20:20:00 2010
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 18 Jun 2010 20:20:00 +0200
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <20100618163842.GA28991@fridge.pov.lt>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>
	<20100618163842.GA28991@fridge.pov.lt>
Message-ID: <201006182020.33479.Arfrever.FTA@gmail.com>

2010-06-18 18:38:42 Marius Gedminas napisa?(a):
> Linux requires that the interpreter be a real executable and won't accept a script there.

Linux supports interpreters being scrips since 2.6.28.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bf2a9a39639b8b51377905397a5005f444e9a892

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

From fdrake at acm.org  Fri Jun 18 20:51:48 2010
From: fdrake at acm.org (Fred Drake)
Date: Fri, 18 Jun 2010 14:51:48 -0400
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <201006182020.33479.Arfrever.FTA@gmail.com>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>
	<20100618163842.GA28991@fridge.pov.lt> 
	<201006182020.33479.Arfrever.FTA@gmail.com>
Message-ID: 

On Fri, Jun 18, 2010 at 2:20 PM, Arfrever Frehtes Taifersar Arahesis
 wrote:
> Linux supports interpreters being scrips since 2.6.28.

Too recent to be deployed on many production servers, unfortunately.
But progress none-the-less.


  -Fred

-- 
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein

From pje at telecommunity.com  Fri Jun 18 22:23:55 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 18 Jun 2010 16:23:55 -0400
Subject: [Distutils] setuptools for py 2.7 windows
In-Reply-To: 
References: <1026258979.20100615172030@gmail.com>
	
Message-ID: <20100618202405.1917C3A40A5@sparrow.telecommunity.com>

At 08:24 AM 6/18/2010 +0200, Lennart Regebro wrote:
>On Tue, Jun 15, 2010 at 17:20, Adam GROSZER  wrote:
> > Hello,
> >
> > Someone please make a setuptools-0.6c11.win32-py2.7.exe.
>
>Just out of interest: Why are these versions needed?

If you're asking why there are different .exe's for different Python 
versions, it's because currently, different modules and entry points 
are included, based on Python version.  Distutils on Python 2.3, for 
example, does not include an 'upload' command, so setuptools provides 
one there.  But on 2.4+, it is not necessary for setuptools to 
provide it, since it is already included.


>Their isn't any
>C-code in setuptools, doesn't the source version work just as well?

There are .exe's so that Windows users don't have to do a lot of 
extra manual steps to get the installation process started, and so 
that they can uninstall via the Windows control panel.


From pje at telecommunity.com  Fri Jun 18 22:25:04 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 18 Jun 2010 16:25:04 -0400
Subject: [Distutils] setuptools for py 2.7 windows
In-Reply-To: 
References: <1026258979.20100615172030@gmail.com>
	
	<4C1B1394.3030107@v.loewis.de>
	<1548890243.20100618091314@gmail.com>
	
Message-ID: <20100618202514.8274F3A40A5@sparrow.telecommunity.com>

At 08:35 AM 6/18/2010 +0100, Paul Moore wrote:
>And of course, the irony is that "pure distutils" bdist_wininst
>installers are not python version specific. It's setuptools itself
>that modifies bdist_wininst to make the installers it builds python
>version specific ;-)

This is only the case for setuptools' *own* installer, because it 
installs different contents for different Python 
versions.  Setuptools has some modules that are only used in Python 
2.3, for example. 


From strawman at astraw.com  Sat Jun 19 03:01:54 2010
From: strawman at astraw.com (Andrew Straw)
Date: Fri, 18 Jun 2010 18:01:54 -0700
Subject: [Distutils] stdeb followup
In-Reply-To: <20100610172058.55ee3298@heresy>
References: <20100610172058.55ee3298@heresy>
Message-ID: <4C1C1702.9040403@astraw.com>

Barry Warsaw wrote:
> I'm wondering if you've released a version with the debianize command, and if
> not when you might do that.  I'd like to work on getting that available in
> Debian, Ubuntu, and my PPA.
>   
I have just released stdeb 0.6.0 which has the debianize command. Thanks
for the testing, feedback, and ideas.

-Andrew

From barry at python.org  Sat Jun 19 14:39:01 2010
From: barry at python.org (Barry Warsaw)
Date: Sat, 19 Jun 2010 08:39:01 -0400
Subject: [Distutils] stdeb followup
In-Reply-To: <4C1C1702.9040403@astraw.com>
References: <20100610172058.55ee3298@heresy>
	<4C1C1702.9040403@astraw.com>
Message-ID: <20100619083901.3edbbd3d@heresy>

On Jun 18, 2010, at 06:01 PM, Andrew Straw wrote:

>Barry Warsaw wrote:
>> I'm wondering if you've released a version with the debianize command, and if
>> not when you might do that.  I'd like to work on getting that available in
>> Debian, Ubuntu, and my PPA.
>>   
>I have just released stdeb 0.6.0 which has the debianize command. Thanks
>for the testing, feedback, and ideas.

Awesome, thanks Andrew!
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

From suresh_vv at yahoo.com  Sat Jun 19 17:49:11 2010
From: suresh_vv at yahoo.com (Suresh V.)
Date: Sat, 19 Jun 2010 21:19:11 +0530
Subject: [Distutils] Buildout: syntax for Extending sections (macros)
In-Reply-To: 
References: 
	
Message-ID: <4C1CE6F7.3010304@yahoo.com>

The documentation at pypi seems to be missing the "=" from "<=" which 
caused a little bit of added confusion for me (not in the example code 
but in the descriptive part of the documentation).

See:

http://pypi.python.org/pypi/zc.buildout#extending-sections-macros

Suresh


From jim at zope.com  Sat Jun 19 18:17:01 2010
From: jim at zope.com (Jim Fulton)
Date: Sat, 19 Jun 2010 12:17:01 -0400
Subject: [Distutils] Buildout: syntax for Extending sections (macros)
In-Reply-To: <4C1CE6F7.3010304@yahoo.com>
References: 
	 
	<4C1CE6F7.3010304@yahoo.com>
Message-ID: 

On Sat, Jun 19, 2010 at 11:49 AM, Suresh V.  wrote:
> The documentation at pypi seems to be missing the "=" from "<=" which caused
> a little bit of added confusion for me (not in the example code but in the
> descriptive part of the documentation).
>
> See:
>
> http://pypi.python.org/pypi/zc.buildout#extending-sections-macros

Interesting. The '=' is in the examples, but not the prose. Thanks for
pointing that out.

Jim

-- 
Jim Fulton

From gnarea at tech.2degreesnetwork.com  Mon Jun 21 12:28:23 2010
From: gnarea at tech.2degreesnetwork.com (Gustavo Narea)
Date: Mon, 21 Jun 2010 11:28:23 +0100
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: 
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>	<20100618163842.GA28991@fridge.pov.lt>
	<201006182020.33479.Arfrever.FTA@gmail.com>
	
Message-ID: <4C1F3EC7.4050802@tech.2degreesnetwork.com>

Hello.

On -10/01/37 20:59, Fred Drake wrote:
>> Linux supports interpreters being scrips since 2.6.28.
>>     
> Too recent to be deployed on many production servers, unfortunately.
> But progress none-the-less.

I don't know if Debian backported that, but our servers run 2.6.26 and
this works like a charm. And our Ubuntu machines have recent kernels,
so that is not a problem for us.

Anyway, the problem is that some packages (not all) cannot be installed
by Buildout when the wrapper is in use. I've investigated to see what
those packages have in common, but I haven't been able to find anything.

If I remove the packages it complaints about from setup.py, everything works.

One of those packages is django-audit, which we've been using for a while before introducing the wrapper:
http://pypi.python.org/pypi/django-audit/1.0b1

Do you have any idea why this is failing?

Thanks in advance.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .


From gustavonarea at 2degreesnetwork.com  Mon Jun 21 10:57:02 2010
From: gustavonarea at 2degreesnetwork.com (Gustavo Narea)
Date: Mon, 21 Jun 2010 09:57:02 +0100
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <201006182020.33479.Arfrever.FTA@gmail.com>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>	<20100618163842.GA28991@fridge.pov.lt>
	<201006182020.33479.Arfrever.FTA@gmail.com>
Message-ID: <4C1F295E.3020209@2degreesnetwork.com>

Hello,

On -10/01/37 20:59, Arfrever Frehtes Taifersar Arahesis wrote:
>> Linux requires that the interpreter be a real executable and won't accept a script there.
>>     
> Linux supports interpreters being scrips since 2.6.28.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bf2a9a39639b8b51377905397a5005f444e9a892
>   

I don't know if Debian backported that, but our servers run 2.6.26 and
this works like a charm.

Anyway, the problem is that some packages (not all) cannot be installed
by Buildout when the wrapper is in use. I've investigated to see what
those packages have in common, but I haven't been able to find anything.

One of those packages is django-audit:
http://pypi.python.org/pypi/django-audit/1.0b1

Do you have any idea why this is failing?

Thanks in advance.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .


From gustavonarea at 2degreesnetwork.com  Mon Jun 21 12:23:20 2010
From: gustavonarea at 2degreesnetwork.com (Gustavo Narea)
Date: Mon, 21 Jun 2010 11:23:20 +0100
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: 
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>	<20100618163842.GA28991@fridge.pov.lt>
	<201006182020.33479.Arfrever.FTA@gmail.com>
	
Message-ID: <4C1F3D98.5080709@2degreesnetwork.com>

Hello.

On -10/01/37 20:59, Fred Drake wrote:
>> > Linux supports interpreters being scrips since 2.6.28.
>>     
> Too recent to be deployed on many production servers, unfortunately.
> But progress none-the-less.
>   

I don't know if Debian backported that, but our servers run 2.6.26 and
this works like a charm. And our Ubuntu machines have recent kernels,
so that is not a problem for us.

Anyway, the problem is that some packages (not all) cannot be installed
by Buildout when the wrapper is in use. I've investigated to see what
those packages have in common, but I haven't been able to find anything.

One of those packages is django-audit:
http://pypi.python.org/pypi/django-audit/1.0b1

Do you have any idea why this is failing?

Thanks in advance.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .


From fuzzyman at gmail.com  Tue Jun 22 04:04:06 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Tue, 22 Jun 2010 03:04:06 +0100
Subject: [Distutils] Including test and docs in distribution
Message-ID: 

Hey all,

I have a single module I distribute and I would *like* to include the tests
(a package) and docs (sphinx generated - single directory) in the
distribution  - but not have them "installed" by setup.py.

Is this possible with either distutils or distribute?

Anyone able to suggest the right magic incantation for the setup.py? (Or a
better approach - I really don't want to make my 600 line single module a
package though.)

All the best,

Michael Foord

-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From cournape at gmail.com  Tue Jun 22 05:34:46 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 22 Jun 2010 12:34:46 +0900
Subject: [Distutils] Including test and docs in distribution
In-Reply-To: 
References: 
Message-ID: 

On Tue, Jun 22, 2010 at 11:04 AM, Michael Foord  wrote:
> Hey all,
>
> I have a single module I distribute and I would *like* to include the tests
> (a package) and docs (sphinx generated - single directory) in the
> distribution? - but not have them "installed" by setup.py.

By distribution, you mean the tarball generated by sdist ? In that
case, just use the MANIFEST.in, and ensure the doc is build when doing
a sdist. You could for example use paver to do that.

cheers,

David

From flub at devork.be  Tue Jun 22 09:39:17 2010
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 22 Jun 2010 08:39:17 +0100
Subject: [Distutils] Including test and docs in distribution
In-Reply-To: 
References: 
	
Message-ID: <20100622073917.GA27814@laurie.devork.be>

On Tue, Jun 22, 2010 at 12:34:46PM +0900, David Cournapeau wrote:
> On Tue, Jun 22, 2010 at 11:04 AM, Michael Foord  wrote:
> > Hey all,
> >
> > I have a single module I distribute and I would *like* to include the tests
> > (a package) and docs (sphinx generated - single directory) in the
> > distribution? - but not have them "installed" by setup.py.
> 
> By distribution, you mean the tarball generated by sdist ? In that
> case, just use the MANIFEST.in, and ensure the doc is build when doing
> a sdist. You could for example use paver to do that.

MANIFEST.in is indeed the right answer.  If it's simply a single
module package it's easy and low-maintenance to do by hand, e.g.:

include tests/*.py
recursive-include docs/

See http://docs.python.org/distutils/commandref.html#creating-a-source-distribution-the-sdist-command for details of MANIFEST.in

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From chris at simplistix.co.uk  Tue Jun 22 11:24:17 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 22 Jun 2010 10:24:17 +0100
Subject: [Distutils] [buildout] zc.buildout.testing.install(_develop) and
	test setup slowness
Message-ID: <4C208141.2060508@simplistix.co.uk>

Hi All,

Can anyone explain how or why zc.buildout.testing.install and 
zc.buildout.testing.install_develop don't install the dependencies of 
the package you specify?

I'm writing a recipe that requires the Zope2 package to be present, and 
it has rather a lot of dependent packages. The pattern with buildout 
recipe tests seems to be to manually install the package under test with 
zc.buildout.testing.install_develop and then each required package with 
zc.buildout.testing.install.

For Zope2, this doesn't scale so well ;-)

Also, even doing the manual install above is *really* slow, I have a 
test that now takes 20-30 seconds before it even starts running :-(

Any ideas how to make this situation better?

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From fuzzyman at gmail.com  Tue Jun 22 14:00:11 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Tue, 22 Jun 2010 13:00:11 +0100
Subject: [Distutils] Including test and docs in distribution
In-Reply-To: <20100622073917.GA27814@laurie.devork.be>
References: 
	
	<20100622073917.GA27814@laurie.devork.be>
Message-ID: 

On 22 June 2010 08:39, Floris Bruynooghe  wrote:

> On Tue, Jun 22, 2010 at 12:34:46PM +0900, David Cournapeau wrote:
> > On Tue, Jun 22, 2010 at 11:04 AM, Michael Foord 
> wrote:
> > > Hey all,
> > >
> > > I have a single module I distribute and I would *like* to include the
> tests
> > > (a package) and docs (sphinx generated - single directory) in the
> > > distribution  - but not have them "installed" by setup.py.
> >
> > By distribution, you mean the tarball generated by sdist ? In that
> > case, just use the MANIFEST.in, and ensure the doc is build when doing
> > a sdist. You could for example use paver to do that.
>
> MANIFEST.in is indeed the right answer.  If it's simply a single
> module package it's easy and low-maintenance to do by hand, e.g.:
>
> include tests/*.py
> recursive-include docs/
>
> See
> http://docs.python.org/distutils/commandref.html#creating-a-source-distribution-the-sdist-commandfor details of MANIFEST.in
>
>
That's exactly what I need. Thanks very much for your help.

All the best,

Michael Foord


> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
>



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jim at zope.com  Tue Jun 22 15:44:06 2010
From: jim at zope.com (Jim Fulton)
Date: Tue, 22 Jun 2010 09:44:06 -0400
Subject: [Distutils] [buildout] zc.buildout.testing.install(_develop)
	and test setup slowness
In-Reply-To: <4C208141.2060508@simplistix.co.uk>
References: <4C208141.2060508@simplistix.co.uk>
Message-ID: 

On Tue, Jun 22, 2010 at 5:24 AM, Chris Withers  wrote:
> Hi All,
>
> Can anyone explain how or why zc.buildout.testing.install and
> zc.buildout.testing.install_develop don't install the dependencies of the
> package you specify?

It wasn't needed at the time.


> I'm writing a recipe that requires the Zope2 package to be present, and it
> has rather a lot of dependent packages. The pattern with buildout recipe
> tests seems to be to manually install the package under test with
> zc.buildout.testing.install_develop and then each required package with
> zc.buildout.testing.install.
>
> For Zope2, this doesn't scale so well ;-)

Maybe the recipe shouldn't require all of Zope 2. That seems like a rather
heavy dependency for a recipe.

Jim

-- 
Jim Fulton

From chris at simplistix.co.uk  Tue Jun 22 15:45:46 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 22 Jun 2010 14:45:46 +0100
Subject: [Distutils] [buildout] zc.buildout.testing.install(_develop)
 and test setup slowness
In-Reply-To: 
References: <4C208141.2060508@simplistix.co.uk>
	
Message-ID: <4C20BE8A.9070001@simplistix.co.uk>

Jim Fulton wrote:
>> For Zope2, this doesn't scale so well ;-)
> 
> Maybe the recipe shouldn't require all of Zope 2. That seems like a rather
> heavy dependency for a recipe.

The recipe sets up a deployment-based Zope 2 instance, I'm pretty sure 
it needs all of Zope 2 ;-)

...unless I'm missing something, in which case, please let me know!

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Tue Jun 22 19:47:32 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 22 Jun 2010 18:47:32 +0100
Subject: [Distutils] [buildout] good example recipe with tests?
In-Reply-To: <4C20BE8A.9070001@simplistix.co.uk>
References: <4C208141.2060508@simplistix.co.uk>	
	<4C20BE8A.9070001@simplistix.co.uk>
Message-ID: <4C20F734.6010003@simplistix.co.uk>

Chris Withers wrote:
> Jim Fulton wrote:
>>> For Zope2, this doesn't scale so well ;-)
>>
>> Maybe the recipe shouldn't require all of Zope 2. That seems like a 
>> rather
>> heavy dependency for a recipe.
> 
> The recipe sets up a deployment-based Zope 2 instance, I'm pretty sure 
> it needs all of Zope 2 ;-)

I think I could have phrased this better...

Is there a good example buildout recipe you can point me at, that has 
good tests, preferably using Manuel rather than the deprecated 
zope.testing.doctest and also hopefully avoiding the rather strange 
renormalizer usage I've seen in some buildout tests where a normalizer 
is basically used to hide packages that are reported as missing in an index?

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From john at industromatic.com  Wed Jun 23 23:51:43 2010
From: john at industromatic.com (John Griessen)
Date: Wed, 23 Jun 2010 16:51:43 -0500
Subject: [Distutils] buildout behavior as source revisions change
Message-ID: <4C2281EF.1050506@industromatic.com>

Some weeks ago I made a buildout config using mr.developer and djangorecipe extensions
that worked to get a svn trunk version of django-mptt
and now it stops with an error message.

Is there a way to specify sources better so it still works when a rev number changes?  Do I have a syntax error?
The place it has trouble with is     rev=>0.2.2

Now I think I can do without the svn version since django-mptt is now at 0.3.0.

$ bin/buildout output from past the error message
------------------------------------------
    Getting distribution for 'django-mptt-2>0.2.1'.
    zip_safe flag not set; analyzing archive contents...
    mptt.tests.settings: module references __file__
    mptt.tests.test_runner: module references __file__
    Got django-mptt-2 0.3.0.
----------------------------------
The Getting line above says the   rev=>0.2.2 didn't get used anyway?
Know why not?  Is this a mr.developer problem?

Please give my buildout config a look and suggest how I can learn this better.
The config and the error output follow.

Thanks,

John

-------------------
[buildout]
eggs-directory = /home/john/buildout/eggs
extensions = mr.developer
sources = sources
auto-checkout = django-mptt

parts =
     django

eggs =
     mock
     django-notification
     django-page-cms
     django-haystack
     django-messages

[sources]
django-mptt = svn http://django-mptt.googlecode.com/svn/trunk/ rev=>0.2.2 path=src-untouched

[django]
recipe = djangorecipe
version = 1.1.1
settings = development
wsgi = true
eggs = ${buildout:eggs}
project = cottagematic_com
----------------------------------
comand line output
--------------------------
john at toolbench:~/WEBprojects/cottagematic_bld$ bin/buildout
Getting distribution for 'mr.developer'.
Got mr.developer 1.14.
Page at http://pypi.python.org/simple/argparse/ links to .py file(s) without version info; an index scan is required.
Getting distribution for 'argparse'.
zip_safe flag not set; analyzing archive contents...
Got argparse 1.1.
mr.developer: Queued 'django-mptt' for checkout.
Exception in thread Thread-1:
Traceback (most recent call last):
   File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
     self.run()
   File "/usr/lib/python2.6/threading.py", line 484, in run
     self.__target(*self.__args, **self.__kwargs)
   File "/home/john/buildout/eggs/mr.developer-1.14-py2.6.egg/mr/developer/common.py", line 99, in worker
     output = action(**kwargs)
   File "/home/john/buildout/eggs/mr.developer-1.14-py2.6.egg/mr/developer/svn.py", line 263, in checkout
     matches = self.matches()
   File "/home/john/buildout/eggs/mr.developer-1.14-py2.6.egg/mr/developer/svn.py", line 298, in matches
     return (info.get('url') == url) and (int(info.get('revision')) > int(rev[1:]))
ValueError: invalid literal for int() with base 10: '0.2.2'




From gnarea at tech.2degreesnetwork.com  Thu Jun 24 12:06:24 2010
From: gnarea at tech.2degreesnetwork.com (Gustavo Narea)
Date: Thu, 24 Jun 2010 11:06:24 +0100
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <4C1F3EC7.4050802@tech.2degreesnetwork.com>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>	<20100618163842.GA28991@fridge.pov.lt>
	<201006182020.33479.Arfrever.FTA@gmail.com>
	
	<4C1F3EC7.4050802@tech.2degreesnetwork.com>
Message-ID: <4C232E20.6030201@tech.2degreesnetwork.com>

Anyone?

On 21/06/10 11:28, Gustavo Narea wrote:
> Hello.
>
> On -10/01/37 20:59, Fred Drake wrote:
>   
>>> Linux supports interpreters being scrips since 2.6.28.
>>>     
>>>       
>> Too recent to be deployed on many production servers, unfortunately.
>> But progress none-the-less.
>>     
> I don't know if Debian backported that, but our servers run 2.6.26 and
> this works like a charm. And our Ubuntu machines have recent kernels,
> so that is not a problem for us.
>
> Anyway, the problem is that some packages (not all) cannot be installed
> by Buildout when the wrapper is in use. I've investigated to see what
> those packages have in common, but I haven't been able to find anything.
>
> If I remove the packages it complaints about from setup.py, everything works.
>
> One of those packages is django-audit, which we've been using for a while before introducing the wrapper:
> http://pypi.python.org/pypi/django-audit/1.0b1
>
> Do you have any idea why this is failing?
>
> Thanks in advance.
>
>   


-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. .


From jim at zope.com  Thu Jun 24 14:59:22 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 24 Jun 2010 08:59:22 -0400
Subject: [Distutils] Buildout not working with Bash wrapper for `python'
In-Reply-To: <4C1F3EC7.4050802@tech.2degreesnetwork.com>
References: <4C1B9A98.2030905@tech.2degreesnetwork.com>
	<20100618163842.GA28991@fridge.pov.lt> 
	<201006182020.33479.Arfrever.FTA@gmail.com>
	 
	<4C1F3EC7.4050802@tech.2degreesnetwork.com>
Message-ID: 

On Mon, Jun 21, 2010 at 6:28 AM, Gustavo Narea
 wrote:
...
> Do you have any idea why this is failing?

No.  If you send me, in a separate private email, a buildout I can use
to reproduce the problem and your Python wrapper script, I'll spend a
little bit of time to see if I can see what's going on.

Jim

--
Jim Fulton

From jim at zope.com  Thu Jun 24 15:09:50 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 24 Jun 2010 09:09:50 -0400
Subject: [Distutils] [buildout] good example recipe with tests?
In-Reply-To: <4C20F734.6010003@simplistix.co.uk>
References: <4C208141.2060508@simplistix.co.uk>
	 
	<4C20BE8A.9070001@simplistix.co.uk> <4C20F734.6010003@simplistix.co.uk>
Message-ID: 

On Tue, Jun 22, 2010 at 1:47 PM, Chris Withers  wrote:
> Chris Withers wrote:
>>
>> Jim Fulton wrote:
>>>>
>>>> For Zope2, this doesn't scale so well ;-)
>>>
>>> Maybe the recipe shouldn't require all of Zope 2. That seems like a
>>> rather
>>> heavy dependency for a recipe.
>>
>> The recipe sets up a deployment-based Zope 2 instance, I'm pretty sure it
>> needs all of Zope 2 ;-)
>
> I think I could have phrased this better...

Eh.  I understood where you were coming from.  :) It's hard to comment
without studying your recipe, which I don't want to take the time to
do.  It should be possible to rethink the approach to avoid the
dependency. For example, if your recipe is installing the Zope2
software *and* setting up instance config, I think it's doing too
much.

If you disagree, that's fine, but then you might have to do more work
(or maybe not).

> Is there a good example buildout recipe you can point me at, that has good
> tests, preferably using Manuel rather than the deprecated
> zope.testing.doctest and also hopefully avoiding the rather strange
> renormalizer usage I've seen in some buildout tests where a normalizer is
> basically used to hide packages that are reported as missing in an index?

Nope.  Most of the existing recipes were written before manuel was
adopted.  I'd like to figure out where the spurious messages are
coming from, but I have lots of other things I'd like to do that are
more pressing.

One observation is that the testing infrastructure is shaped by a goal
of not wanting to make network connections and download packages in a
test.  This adds lots of complexity.  Maybe you want to relax this.
.

Jim

--
Jim Fulton

From john at industromatic.com  Thu Jun 24 18:09:44 2010
From: john at industromatic.com (John Griessen)
Date: Thu, 24 Jun 2010 11:09:44 -0500
Subject: [Distutils] buildout behavior as source revisions change
In-Reply-To: <4C2281EF.1050506@industromatic.com>
References: <4C2281EF.1050506@industromatic.com>
Message-ID: <4C238348.9020605@industromatic.com>

John Griessen wrote:
> Some weeks ago I made a buildout config using mr.developer and 
> djangorecipe extensions
> that worked to get a svn trunk version of django-mptt
> and now it stops with an error message.
> 
> Is there a way to specify sources better so it still works when a rev 
> number changes?  Do I have a syntax error?
> The place it has trouble with is     rev=>0.2.2

I suppose this is just an off topic mr.developer question.
I've worked around it without an answer.

JG

From chris at simplistix.co.uk  Fri Jun 25 11:34:59 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 25 Jun 2010 10:34:59 +0100
Subject: [Distutils] comparing version strings?
Message-ID: <4C247843.7070000@simplistix.co.uk>

Hi All,

Is there any any in setuptools/distutils/anything else that I can use to 
compare version strings using the same rules as setuptools?

ie: sort the following list of versions:

1.0
2.0dev-r22542-20100623
2.0dev-r22553-20100624
2.0

...etc

cheers,

Chris


From agroszer at gmail.com  Fri Jun 25 11:43:26 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Fri, 25 Jun 2010 11:43:26 +0200
Subject: [Distutils] comparing version strings?
In-Reply-To: <4C247843.7070000@simplistix.co.uk>
References: <4C247843.7070000@simplistix.co.uk>
Message-ID: <502838503.20100625114326@gmail.com>

Hello Chris,

See:
from distutils.version import StrictVersion

and

svn://svn.zope.org/repos/main/Sandbox/adamg/zope.wineggbuilder/trunk/src/zope/wineggbuilder/build.py

Friday, June 25, 2010, 11:34:59 AM, you wrote:

CW> Hi All,

CW> Is there any any in setuptools/distutils/anything else that I can use to
CW> compare version strings using the same rules as setuptools?

CW> ie: sort the following list of versions:

CW> 1.0
CW> 2.0dev-r22542-20100623
CW> 2.0dev-r22553-20100624
CW> 2.0

CW> ...etc

CW> cheers,

CW> Chris

CW> _______________________________________________
CW> Distutils-SIG maillist  -  Distutils-SIG at python.org
CW> http://mail.python.org/mailman/listinfo/distutils-sig


-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
True freedom is frightful


From ametaireau at gmail.com  Fri Jun 25 14:04:58 2010
From: ametaireau at gmail.com (=?UTF-8?Q?Alexis_M=C3=A9taireau?=)
Date: Fri, 25 Jun 2010 14:04:58 +0200
Subject: [Distutils] comparing version strings?
In-Reply-To: <502838503.20100625114326@gmail.com>
References: <4C247843.7070000@simplistix.co.uk>
	<502838503.20100625114326@gmail.com>
Message-ID: 

Chris,

You also can use the distutils2.version module. I've documented them in my
fork [1], waiting to be merged upstream for now, but the codebase of the
first (alpha) release of distutils2 [2] ship with the distutils2.version
module.

This respect version specifiers as described in PEP 354 [3], and I think
it's the good way to compare version numbers for the future.

Hope it helps, bug reports and/or any feedback is welcome !
Cheers,
Alexis

[1]
http://bitbucket.org/ametaireau/distutils2/src/tip/docs/source/version.rst
[2] http://pypi.python.org/pypi/Distutils2/1.0a1
[3] http://www.python.org/dev/peps/pep-0345/#version-specifiers

On Fri, Jun 25, 2010 at 11:43 AM, Adam GROSZER  wrote:

> Hello Chris,
>
> See:
> from distutils.version import StrictVersion
>
> and
>
> svn://
> svn.zope.org/repos/main/Sandbox/adamg/zope.wineggbuilder/trunk/src/zope/wineggbuilder/build.py
>
> Friday, June 25, 2010, 11:34:59 AM, you wrote:
>
> CW> Hi All,
>
> CW> Is there any any in setuptools/distutils/anything else that I can use
> to
> CW> compare version strings using the same rules as setuptools?
>
> CW> ie: sort the following list of versions:
>
> CW> 1.0
> CW> 2.0dev-r22542-20100623
> CW> 2.0dev-r22553-20100624
> CW> 2.0
>
> CW> ...etc
>
> CW> cheers,
>
> CW> Chris
>
> CW> _______________________________________________
> CW> Distutils-SIG maillist  -  Distutils-SIG at python.org
> CW> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
> --
> Best regards,
>  Adam GROSZER                            mailto:agroszer at gmail.com
> --
> Quote of the day:
> True freedom is frightful
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Alexis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chris at simplistix.co.uk  Fri Jun 25 14:35:34 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 25 Jun 2010 13:35:34 +0100
Subject: [Distutils] comparing version strings?
In-Reply-To: 
References: <4C247843.7070000@simplistix.co.uk>
	<502838503.20100625114326@gmail.com>
	
Message-ID: <4C24A296.1020908@simplistix.co.uk>

Alexis M?taireau wrote:
> Chris,
> 
> You also can use the distutils2.version module. I've documented them in 
> my fork [1], waiting to be merged upstream for now, but the codebase of 
> the first (alpha) release of distutils2 [2] ship with the 
> distutils2.version module.

Yes, this is good, but since we're using setuptools, I *really* want to 
compare versions in exactly the same way that it does, for better or 
worse...

I guess I need to go and read the setuptools source, unless anyone has 
some easy answers for me?

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From pje at telecommunity.com  Fri Jun 25 15:09:55 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 25 Jun 2010 09:09:55 -0400
Subject: [Distutils] comparing version strings?
In-Reply-To: <4C247843.7070000@simplistix.co.uk>
References: <4C247843.7070000@simplistix.co.uk>
Message-ID: <20100625131001.7086B3A4099@sparrow.telecommunity.com>

At 10:34 AM 6/25/2010 +0100, Chris Withers wrote:
>Hi All,
>
>Is there any any in setuptools/distutils/anything else that I can 
>use to compare version strings using the same rules as setuptools?
>
>ie: sort the following list of versions:
>
>1.0
>2.0dev-r22542-20100623
>2.0dev-r22553-20100624
>2.0
>
>...etc

http://peak.telecommunity.com/DevCenter/PkgResources#parsing-utilities

from pkg_resources import parse_version

sort(versions, key=parse_version)




>cheers,
>
>Chris
>
>_______________________________________________
>Distutils-SIG maillist  -  Distutils-SIG at python.org
>http://mail.python.org/mailman/listinfo/distutils-sig


From fuzzyman at gmail.com  Fri Jun 25 16:45:57 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Fri, 25 Jun 2010 15:45:57 +0100
Subject: [Distutils] Test failure: test_python_53586
Message-ID: 

Hello all,

When I do a *full test run* of py3k I get a distutils test failure. It
doesn't happen if I run test_distutils on its own:

bigmac:py3k michael$ ./python.exe -m test.regrtest -j12
== CPython 3.2a0 (py3k:82215, Jun 25 2010, 13:59:00) [GCC 4.2.1 (Apple Inc.
build 5659)]
==   Darwin-10.4.0-i386-64bit
==   /compile/py3k/build/test_python_53586

... lots of results skipped

test test_distutils failed -- Traceback (most recent call last):
  File "/compile/py3k/Lib/distutils/tests/support.py", line 16, in
_capture_warnings
    return func(*args, **kw)
  File "/compile/py3k/Lib/distutils/tests/test_sysconfig.py", line 47, in
test_get_python_inc
    self.assertTrue(os.path.isdir(inc_dir), inc_dir)
AssertionError: /compile/py3k/build/test_python_53586/Include

All the best,

Michael Foord

-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ziade.tarek at gmail.com  Fri Jun 25 18:03:15 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 25 Jun 2010 18:03:15 +0200
Subject: [Distutils] Test failure: test_python_53586
In-Reply-To: 
References: 
Message-ID: 

On Fri, Jun 25, 2010 at 4:45 PM, Michael Foord  wrote:
> Hello all,
>
> When I do a *full test run* of py3k I get a distutils test failure. It
> doesn't happen if I run test_distutils on its own:
>
> bigmac:py3k michael$ ./python.exe -m test.regrtest -j12
> == CPython 3.2a0 (py3k:82215, Jun 25 2010, 13:59:00) [GCC 4.2.1 (Apple Inc.
> build 5659)]
> ==?? Darwin-10.4.0-i386-64bit
> ==?? /compile/py3k/build/test_python_53586
>
> ... lots of results skipped
>
> test test_distutils failed -- Traceback (most recent call last):
> ? File "/compile/py3k/Lib/distutils/tests/support.py", line 16, in
> _capture_warnings
> ??? return func(*args, **kw)
> ? File "/compile/py3k/Lib/distutils/tests/test_sysconfig.py", line 47, in
> test_get_python_inc
> ??? self.assertTrue(os.path.isdir(inc_dir), inc_dir)
> AssertionError: /compile/py3k/build/test_python_53586/Include
>
> All the best,

Hello Michael,

Can you add an issue in the tracker ?

Thanks !

>
> Michael Foord
>
> --
> http://www.voidspace.org.uk
>
>
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>



-- 
Tarek Ziad? | http://ziade.org

From fuzzyman at gmail.com  Fri Jun 25 18:23:58 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Fri, 25 Jun 2010 17:23:58 +0100
Subject: [Distutils] Test failure: test_python_53586
In-Reply-To: 
References: 
	
Message-ID: 

On 25 June 2010 17:03, Tarek Ziad?  wrote:

> On Fri, Jun 25, 2010 at 4:45 PM, Michael Foord  wrote:
> > Hello all,
> >
> > When I do a *full test run* of py3k I get a distutils test failure. It
> > doesn't happen if I run test_distutils on its own:
> >
> > bigmac:py3k michael$ ./python.exe -m test.regrtest -j12
> > == CPython 3.2a0 (py3k:82215, Jun 25 2010, 13:59:00) [GCC 4.2.1 (Apple
> Inc.
> > build 5659)]
> > ==   Darwin-10.4.0-i386-64bit
> > ==   /compile/py3k/build/test_python_53586
> >
> > ... lots of results skipped
> >
> > test test_distutils failed -- Traceback (most recent call last):
> >   File "/compile/py3k/Lib/distutils/tests/support.py", line 16, in
> > _capture_warnings
> >     return func(*args, **kw)
> >   File "/compile/py3k/Lib/distutils/tests/test_sysconfig.py", line 47, in
> > test_get_python_inc
> >     self.assertTrue(os.path.isdir(inc_dir), inc_dir)
> > AssertionError: /compile/py3k/build/test_python_53586/Include
> >
> > All the best,
>
> Hello Michael,
>
> Can you add an issue in the tracker ?
>
>
Done:

http://bugs.python.org/issue9081

Michael



> Thanks !
>
> >
> > Michael Foord
> >
> > --
> > http://www.voidspace.org.uk
> >
> >
> >
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
>
>
>
> --
> Tarek Ziad? | http://ziade.org
>



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From techtonik at gmail.com  Sat Jun 26 11:29:05 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 26 Jun 2010 12:29:05 +0300
Subject: [Distutils] bdist_wininst compatibility with pythons and
	windows versions
In-Reply-To: 
References: 
	<4C0C9963.9000203@gmail.com>
	
	
Message-ID: 

On Fri, Jun 11, 2010 at 1:39 PM, David Cournapeau  wrote:
>>
>> In addition bdist_wininst generates spurious warning about missing
>> "necessary compiler setting" when run on Linux with an instruction to
>> make sure win32* modules are installed (which are of course not).
>
> Use wine and the issue disappears. I built a few official numpy/scipy
> releases this way, and it works very well. There are issues on 64
> bits, but I doubt that's an issue for scons or trac,

SCons is pure Python. I can't see why it should use Wine of MS
compiler for windows installer when all necessary binary code pieces
are already available in Python distribution. The choice of correct
binary stub depends on compiler Python was built with - this is what I
would like to see in Python 2.7 even though it is probably late.

Mark, can you compile a list of features and windows/python version
compatibility provided by each stub to evaluate what is the best stub
to use with pure Python modules?

-- 
anatoly t.

From techtonik at gmail.com  Sat Jun 26 11:31:40 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 26 Jun 2010 12:31:40 +0300
Subject: [Distutils] bdist_wininst compatibility with pythons and
	windows versions
In-Reply-To: 
References: 
	<4C0C9963.9000203@gmail.com>
	
	
	
Message-ID: 

On Sat, Jun 26, 2010 at 12:28 PM, anatoly techtonik  wrote:

> The choice of correct binary stub depends on compiler Python was built with - this is what I would like to see in Python 2.7 even though it is probably late.

I meant - This is what I like to see changed in Python 2.7 for pure
Python packages.
-- 
anatoly t.

From cournape at gmail.com  Sun Jun 27 03:35:23 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 27 Jun 2010 10:35:23 +0900
Subject: [Distutils] bdist_wininst compatibility with pythons and
	windows versions
In-Reply-To: 
References: 
	<4C0C9963.9000203@gmail.com>
	
	
	
Message-ID: 

On Sat, Jun 26, 2010 at 6:29 PM, anatoly techtonik  wrote:
> On Fri, Jun 11, 2010 at 1:39 PM, David Cournapeau  wrote:
>>>
>>> In addition bdist_wininst generates spurious warning about missing
>>> "necessary compiler setting" when run on Linux with an instruction to
>>> make sure win32* modules are installed (which are of course not).
>>
>> Use wine and the issue disappears. I built a few official numpy/scipy
>> releases this way, and it works very well. There are issues on 64
>> bits, but I doubt that's an issue for scons or trac,
>
> SCons is pure Python. I can't see why it should use Wine of MS
> compiler for windows installer when all necessary binary code pieces
> are already available in Python distribution.

I know that it does not work today with distutils, I am just saying
that you can do today what you want on Linux if you are willing to use
wine.

> The choice of correct
> binary stub depends on compiler Python was built with - this is what I
> would like to see in Python 2.7 even though it is probably late.

AFAIK, the stub does not matter if you don't have compiled extensions
- but even if you choose the right stub, it would still not work
because the exe needs information encoded in mbcs, which is not
available on Linux.  This may be fixable, though, I don't know what
the mbcs encoding is, except that it is windows specific.

David

From john at industromatic.com  Tue Jun 29 00:24:51 2010
From: john at industromatic.com (John Griessen)
Date: Mon, 28 Jun 2010 17:24:51 -0500
Subject: [Distutils] How does buildout determine paths needed? (for
	django-page-cms)
Message-ID: <4C292133.20406@industromatic.com>

I made a buildout with the config below that didn't work right and
found it needed to have some extra paths added.

Here is the extra path I needed:

   '/home/john/buildout/eggs/django_page_cms-1.1.3-py2.6.egg',
   '/home/john/buildout/eggs/django_page_cms-1.1.3-py2.6.egg/pages/templates/pages',

pages was being found to not have the contents wanted.  Is having a dir pages
and pages/templates/pages a naming problem for buildout?  If a search
is being done for * in pages, it might stop short when the top level pages is found.

Hints, suggestions how to resolve this appreciated.
Meanwhile, every time I run buildout, I'll need to copy an paste that extra path...

John
-----buildout.cfg----
[buildout]
eggs-directory = /home/john/buildout/eggs
extensions = mr.developer

parts =
     django

eggs =
     mock
     django-notification
     django-page-cms
     django-haystack
     django-staticfiles
     django-messages
     django-mptt-2
     whoosh

[django]
recipe = djangorecipe
version = 1.2.1
settings = development
wsgi = true
eggs = ${buildout:eggs}
project = industromatic_com
--------buildout.cfg----------


From jim at zope.com  Tue Jun 29 13:26:23 2010
From: jim at zope.com (Jim Fulton)
Date: Tue, 29 Jun 2010 07:26:23 -0400
Subject: [Distutils] How does buildout determine paths needed? (for
	django-page-cms)
In-Reply-To: <4C292133.20406@industromatic.com>
References: <4C292133.20406@industromatic.com>
Message-ID: 

On Mon, Jun 28, 2010 at 6:24 PM, John Griessen  wrote:
> I made a buildout with the config below that didn't work right and
> found it needed to have some extra paths added.
>
> Here is the extra path I needed:
>
> ?'/home/john/buildout/eggs/django_page_cms-1.1.3-py2.6.egg',
> ?'/home/john/buildout/eggs/django_page_cms-1.1.3-py2.6.egg/pages/templates/pages',
>
> pages was being found to not have the contents wanted. ?Is having a dir
> pages
> and pages/templates/pages a naming problem for buildout? ?If a search
> is being done for * in pages, it might stop short when the top level pages
> is found.
>
> Hints, suggestions how to resolve this appreciated.
> Meanwhile, every time I run buildout, I'll need to copy an paste that extra
> path...

This is almost certainly related to the workings of the djangorecipe,
not buildout.  I suggest asking this questions on the appropriate
django mailing list or asking the author of the django recipe.

Good luck.

Jim

--
Jim Fulton

From agroszer at gmail.com  Tue Jun 29 13:58:53 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Tue, 29 Jun 2010 13:58:53 +0200
Subject: [Distutils] trying to do a buildbot for zc.buildout on windows
Message-ID: <1437101279.20100629135853@gmail.com>

Hello,

I'm trying to make a buildbot for zc.buildout on various windows
platforms.
The problem is that bin/buildout acts weird when it's run by the
buildbot process:
http://winbot.zope.org/builders/zc_buildout_dev%20py_254_win32/builds/3/steps/buildout/logs/stdio

OTOH, it's fine when running it manually (same credentials):
C:\buildslave\zc_buildout_dev_py_254_win32\build>bin\buildout.exe

C:\buildslave\zc_buildout_dev_py_254_win32\build>Upgraded:
  zc.buildout version 1.5.0dev;
restarting.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'.
Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\zc.recipe.egg_'
Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\z3c.recipe.scripts_'
Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\.'
Installing test.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\test'.
Installing oltest.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\oltest'.
Installing py.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'.
Generated script 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\zope-testrunner'.
Generated interpreter 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\py'.

Does anyone know why this could happen?

-- 
Best regards,
 Adam GROSZER                          mailto:agroszer at gmail.com
--
Quote of the day:
We can't all be heroes. Somebody has to sit on the curb and clap as they go by. 
- Will Rogers 


From chris at simplistix.co.uk  Tue Jun 29 18:01:06 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 29 Jun 2010 17:01:06 +0100
Subject: [Distutils] [buildout] develop vs extends/default.cfg
In-Reply-To: <4C054448.5080608@simplistix.co.uk>
References: <4C050997.1050909@simplistix.co.uk>	
	<4C054448.5080608@simplistix.co.uk>
Message-ID: <4C2A18C2.1070801@simplistix.co.uk>

Hi Jim,

Did you get a chance to validate the issue I reported here?

In any case, where should I put it so it doesn't get lost?

cheers,

Chris

Chris Withers wrote:
> Jim Fulton wrote:
>> On Tue, Jun 1, 2010 at 9:22 AM, Chris Withers  
>> wrote:
>>> Hi All,
>>>
>>> What is the expected behaviour when the following are all true:
>>>
>>> - default.cfg has a develop key
>>> - buildout.cfg has a develop key, and extends a base.bfg
>>> - base.cfg has a develop key
>>>
>>> My hope is that all 3 should be set unioned for the develop options.
>>>
>>> However, my experience so far is that, at the least, the one in 
>>> default.cfg
>>> is ignored...
>>
>> When a file extends another, it's options *override* options in the
> 
> ...except extends, which does appear to overlay, right?
> 
>> extended file unless you use += in the extending file, as in:
>>
>>   develop += foo
> 
> Hmm, okay, I think there's a bug lurking, please see attached .tgz
> When I run the buildout in package1, only package1's folde ends up being 
> develop'ed.
> 
> The key appears to be the += for the develop key in base.bfg. If I 
> change that to just =, the behaviour seems as expected.
> However, The += was very deliberate, so as to allow develop paths to be 
> specified user-wide in default.cfg, based on your advice above.
> 
> Interestingly, any paths in default.cfg's develop *do* end up being used 
> in the attached example.
> 
> Where/how should I report this?
> 
> cheers,
> 
> Chris
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk


From jim at zope.com  Tue Jun 29 20:34:20 2010
From: jim at zope.com (Jim Fulton)
Date: Tue, 29 Jun 2010 14:34:20 -0400
Subject: [Distutils] [buildout] develop vs extends/default.cfg
In-Reply-To: <4C2A18C2.1070801@simplistix.co.uk>
References: <4C050997.1050909@simplistix.co.uk>
	 
	<4C054448.5080608@simplistix.co.uk> <4C2A18C2.1070801@simplistix.co.uk>
Message-ID: 

On Tue, Jun 29, 2010 at 12:01 PM, Chris Withers  wrote:
> Hi Jim,
>
> Did you get a chance to validate the issue I reported here?

Not yet.

> In any case, where should I put it so it doesn't get lost?

  https://bugs.launchpad.net/zc.buildout/+bugs

Jim

-- 
Jim Fulton

From techtonik at gmail.com  Wed Jun 30 08:59:07 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 30 Jun 2010 09:59:07 +0300
Subject: [Distutils] easy_install wrong download site preference
Message-ID: 

Hello,

protobuf project have problems with installing via easy_install. One
part of problem is that the project provides versioned archives
unrelated to Python that `easy_install` threats as Python packages.
Corresponding package with the same version number was uploaded to
PyPI archive, but the easy_install still downloads archive from Google
Code. Why? I though easy_install should prefer PyPI package. Seems
like a bug. Is it possible to raise the priority of PyPI mirror for
protobuf project somehow?

See http://code.google.com/p/protobuf/issues/detail?id=66#c23
http://pypi.python.org/pypi/protobuf
-- 
anatoly t.

From ametaireau at gmail.com  Wed Jun 30 09:38:56 2010
From: ametaireau at gmail.com (Alexis Metaireau)
Date: Wed, 30 Jun 2010 09:38:56 +0200
Subject: [Distutils] easy_install wrong download site preference
In-Reply-To: 
References: 
Message-ID: <1277883536.1586.11.camel@ecureuil>

Hello Anatoly, 

I dont know why, as I never upload a distribution to PyPI, but it seems
that your downloads distributions are not registred as so (no
rel="download" appears on the pypi page, here:
http://pypi.python.org/simple/protobuf/)

I think this is why setuptools/distribute does not browse your index the
way you want.

Hope this helpful, 

Cheers, 
Alexis

On Wed, 2010-06-30 at 09:59 +0300, anatoly techtonik wrote:
> Hello,i
> 
> protobuf project have problems with installing via easy_install. One
> part of problem is that the project provides versioned archives
> unrelated to Python that `easy_install` threats as Python packages.
> Corresponding package with the same version number was uploaded to
> PyPI archive, but the easy_install still downloads archive from Google
> Code. Why? I though easy_install should prefer PyPI package. Seems
> like a bug. Is it possible to raise the priority of PyPI mirror for
> protobuf project somehow?
> 
> See http://code.google.com/p/protobuf/issues/detail?id=66#c23
> http://pypi.python.org/pypi/protobuf



From mhammond at skippinet.com.au  Sun Jun 27 06:41:43 2010
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 27 Jun 2010 14:41:43 +1000
Subject: [Distutils] bdist_wininst compatibility with pythons and
 windows versions
In-Reply-To: 
References: 	<4C0C9963.9000203@gmail.com>		
	
Message-ID: <4C26D687.7010709@skippinet.com.au>

On 26/06/2010 7:29 PM, anatoly techtonik wrote:
> Mark, can you compile a list of features and windows/python version
> compatibility provided by each stub to evaluate what is the best stub
> to use with pure Python modules?

As far as I know, the only issue you will find with ealier stubs is the 
version of the C runtime linked against the stub (ie, by using the 
correct one for the target version you had some assurance the correct 
CRT was already installed) and the fact that later versions have more 
features (but not compatibility changes as such) available to the 
installation scripts.

Mark

From pje at telecommunity.com  Wed Jun 30 18:54:07 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 30 Jun 2010 12:54:07 -0400
Subject: [Distutils] easy_install wrong download site preference
In-Reply-To: 
References: 
Message-ID: <20100630165409.0D70F3A404D@sparrow.telecommunity.com>

At 09:59 AM 6/30/2010 +0300, anatoly techtonik wrote:
>Hello,
>
>protobuf project have problems with installing via easy_install. One
>part of problem is that the project provides versioned archives
>unrelated to Python that `easy_install` threats as Python packages.
>Corresponding package with the same version number was uploaded to
>PyPI archive, but the easy_install still downloads archive from Google
>Code. Why? I though easy_install should prefer PyPI package.

It prefers newer packages, or, if the versions are the same, it 
prefers the shortest download URL.  In this case, the Google Code url 
is shorter.


>Is it possible to raise the priority of PyPI mirror for protobuf 
>project somehow?

No.  If (e.g.) 
http://pypi.python.org/packages/source/p/protobuf/protobuf-2.3.0.tar.gz 
and http://protobuf.googlecode.com/files/protobuf-2.3.0.tar.gz aren't 
equivalent files, they should not be named the same thing -- 
especially since this practice can confuse humans as well as easy_install.

On a practical level, if it's too late for the Python project to use 
a different name,  I would suggest changing the PyPI homepage links 
(for current and past releases) to point to a Python-specific project 
page, that does not contain links to download the generic, non-Python 
package.  This will keep easy_install from considering them as 
candidates for downloading.

(Note: you will have to go into PyPI's administration interface and 
manually change the home page link for *all past versions* as well, 
due to the way the /simple index works.)