Re: [Distutils] packaging terminology confusion

2010-01-09 Thread Suno Ano
John> I would also add the common use of the term "distribution" to John> that glossary as well. Yes, true that, at http://python.org/download/ we have *distributions* to download. I figure the definition for *Installer* should then include that term too. To summarize, we now have the terms -

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread John Gabriele
On Sat, Jan 9, 2010 at 2:48 PM, Lennart Regebro wrote: > On Sat, Jan 9, 2010 at 20:17, Suno Ano wrote: > >>  - *package* means a Python package, (directory intended to be on >>   sys.path, with an __init__.py. We *never* mean a distributable >>   or installable archive, except when “impedance mat

[Distutils] buildout config question

2010-01-09 Thread Olaf Conradi
Hello, Am fiddling with a buildout.cfg for my project, but I don't understand something in script generation. It seems my console script is generated twice. And in that second round it adds pylint to the script of my program and not just the pylint script?? This is the config I have My setup.py

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Lennart Regebro
On Sat, Jan 9, 2010 at 20:17, Suno Ano wrote: >  - *package* means a Python package, (directory intended to be on >   sys.path, with an __init__.py. We *never* mean a distributable >   or installable archive, except when “impedance matching” with >   folks who think in terms of operating system pa

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Suno Ano
[skipping a lot of lines ...] Brad> called 'packages'.) The word 'project' is not a suitable Brad> replacement for the word 'package', right, imho it is been never considered to be Brad> because 'project' is a higher level abstract container of Brad> releases, not a downloadable file containing

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Brad Allen
Oops, I hit send too soon. Please ignore my prior message which contain scratch text at the end. The corrected message follows: On Sat, Jan 9, 2010 at 10:38 AM, P.J. Eby wrote: > At 09:13 AM 1/9/2010 -0600, Brad Allen wrote: >> >> On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby wrote: >> >> >> >> >> Y

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Brad Allen
On Sat, Jan 9, 2010 at 10:38 AM, P.J. Eby wrote: > At 09:13 AM 1/9/2010 -0600, Brad Allen wrote: >> >> On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby wrote: >> >> >> >> >> Yes, very much. I like 'parcel' better than 'project', partly because >> >> it's not already overload with other contextual meanin

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Suno Ano
[skipping a lot of lines ...] Brad> Does anyone who vote +1 for 'project' want to change that vote to Brad> 'parcel'? I do http://tarekziade.wordpress.com/2010/01/07/fixing-packaging-terminology-confusion - However, as P.J. Eby pointed out correctly, *parcel* would be a substitute for *di

Re: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED

2010-01-09 Thread Martin v. Löwis
> * Should it be patched in 26-maint and 31-maint as well? I think so, yes. Adding new support for --enable-shared would be out of scope; fixing the existing support is fine. Regards, Martin ___ Distutils-SIG maillist - Distutils-SIG@python.org http:/

Re: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED

2010-01-09 Thread Nicholas Bastin
On Sat, Jan 9, 2010 at 05:04, Floris Bruynooghe wrote: > Searching throug the tracker I found this: > http://bugs.python.org/issue4366, which looks the same issue. I've added a patch from 2.7 and comment to this issue (apologies for failing to find it on my first seach). I'm grabbing a checkout

Re: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED

2010-01-09 Thread Nicholas Bastin
On Sat, Jan 9, 2010 at 05:04, Floris Bruynooghe wrote: > Your solution is better tough, If you don't I'll try to create and > test a patch for it by the end of the weekend. I'll put a patch on that issue today. I've tested on freebsd5 and it works - I'd like to at least test on freebsd6, and if

Re: [Distutils] zc.buildout generated console scripts with sys.exit

2010-01-09 Thread Jim Fulton
On Fri, Jan 8, 2010 at 7:28 PM, Olaf Conradi wrote: > Hello, > > I wanted use zc.buildout for a program that I wrote, but noticed that the > generated console script does not call sys.exit, unlike setuptools. > > My main function uses a structure as explained by Guido in > http://www.artima.com/we

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread P.J. Eby
At 09:13 AM 1/9/2010 -0600, Brad Allen wrote: On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby wrote: >> >> Yes, very much. I like 'parcel' better than 'project', partly because >> it's not already overload with other contextual meanings. > > This is just another example of the degree of confusion aro

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Brad Allen
On Thu, Jan 7, 2010 at 10:47 PM, Fred Drake wrote: > The point of carefully defined terminology is primarily to make sure > that relatively formal communication, such as technical documentation, > can be carried out both effectively and efficiently.  There's no need > to dictate terminology for c

Re: [Distutils] [Catalog-sig] packaging terminology confusion

2010-01-09 Thread Brad Allen
On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby wrote: >> >> Yes, very much. I like 'parcel' better than 'project', partly because >> it's not already overload with other contextual meanings. > > This is just another example of the degree of confusion around terminology > here, because "parcel" isn't a

Re: [Distutils] Building extension on FreeBSD with Py_ENABLE_SHARED

2010-01-09 Thread Floris Bruynooghe
Hi Nicholas On Thu, Jan 07, 2010 at 10:19:12PM -0500, Nicholas Bastin wrote: > (This comes from trying to build python with --enable-shared, but I > think the problem is not in the Python build process, but rather in > distutils itself) > > When building python standard extensions as part of the