From mwh@python.net  Fri Feb  1 05:37:03 2002
From: mwh@python.net (Michael Hudson)
Date: Fri Feb  1 05:37:03 2002
Subject: [Distutils] _spawn_posix fails, command line works??
In-Reply-To: "John J. Lee"'s message of "Thu, 31 Jan 2002 21:59:39 +0000 (GMT)"
References: <Pine.SOL.4.30.0201312157220.5072-100000@mimosa.csv.warwick.ac.uk>
Message-ID: <2madut1obl.fsf@starship.python.net>

"John J. Lee" <jjl@pobox.com> writes:

> On 28 Jan 2002, Michael Hudson wrote:
> 
> > "John J. Lee" <jjl@pobox.com> writes:
> [...]
> > > if os.name == "nt":
> > >     fmt = '\\"%s\\"'
> > > elif os.name == "posix":
> > >     fmt = '\"%s\"'
> >
> > What happens if you change this to
> >
> >     fmt = "%s"
> 
> I suppose you mean '"%s"'?  Yes, that's what I should have had in the
> "posix" part of the if statement (though I don't much care at the moment,
> since I've still to get the thing to work without segfaulting on windows).
> The confusing part was the difference in behaviour between windows and
> unix -- or have I missed your point?

I don't *think* there *should* be any difference between posix & windows.

There may well be in practice.

Oh, I'm getting confused by the whole issue.  I also can't test on
windows, which isn't a great help...

Cheers,
M.

-- 
  I also fondly recall Paris because that's where I learned to
  debug Zetalisp while drunk.                          -- Olin Shivers


From skip@pobox.com  Fri Feb  1 11:52:01 2002
From: skip@pobox.com (Skip Montanaro)
Date: Fri Feb  1 11:52:01 2002
Subject: [Distutils] "clean" doesn't
Message-ID: <15450.51099.442762.312368@12-248-41-177.client.attbi.com>

(please cc me on any replies - i'm not on the distutils sig)

Am I missing something or is "python setup.py clean" only a feeble attempt
at cleaning what was created by distutils?  If I execute

    python setup.py build
    python setup.py clean
    python setup.py build

the second build does nothing, claiming that everything is up-to-date.  In
my opinion, the clean command should delete the entire build subdirectory,
not just the build/temp.<arch> directory.

Thx,

-- 
Skip Montanaro (skip@pobox.com - http://www.mojam.com/)


From mwh@python.net  Fri Feb  1 11:55:12 2002
From: mwh@python.net (Michael Hudson)
Date: Fri Feb  1 11:55:12 2002
Subject: [Distutils] "clean" doesn't
In-Reply-To: Skip Montanaro's message of "Fri, 1 Feb 2002 10:51:39 -0600"
References: <15450.51099.442762.312368@12-248-41-177.client.attbi.com>
Message-ID: <2mn0ytb0rp.fsf@starship.python.net>

Skip Montanaro <skip@pobox.com> writes:

> (please cc me on any replies - i'm not on the distutils sig)
> 
> Am I missing something or is "python setup.py clean" only a feeble attempt
> at cleaning what was created by distutils?  If I execute
> 
>     python setup.py build
>     python setup.py clean
>     python setup.py build
> 
> the second build does nothing, claiming that everything is up-to-date.  In
> my opinion, the clean command should delete the entire build subdirectory,
> not just the build/temp.<arch> directory.

Have you tried 

python setup.py clean -a

? (like I suggested when you submitted this as a bug)

Perhaps this should be the default?

Cheers,
M.

-- 
39. Re graphics:  A picture is worth 10K words - but only those
    to describe the picture.  Hardly any sets of 10K words can be
    adequately described with pictures.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From mal@lemburg.com  Fri Feb  1 12:22:01 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri Feb  1 12:22:01 2002
Subject: [Distutils] "clean" doesn't
References: <15450.51099.442762.312368@12-248-41-177.client.attbi.com>
Message-ID: <3C5ACF7A.76D3390F@lemburg.com>

Skip Montanaro wrote:
> 
> (please cc me on any replies - i'm not on the distutils sig)
> 
> Am I missing something or is "python setup.py clean" only a feeble attempt
> at cleaning what was created by distutils?  If I execute
> 
>     python setup.py build
>     python setup.py clean
>     python setup.py build
> 
> the second build does nothing, claiming that everything is up-to-date.  In
> my opinion, the clean command should delete the entire build subdirectory,
> not just the build/temp.<arch> directory.

Agreed. Basically, "clean" should be the same as "clean --all" 
is now.

I'd also like a "distclean" command which not only removes
the build/ dir, but also the dist/ dir and any funny files
which may exist in the base dir such as *~, *.bak, *.pyc,
*.pyo, etc.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From skip@pobox.com  Fri Feb  1 13:11:02 2002
From: skip@pobox.com (Skip Montanaro)
Date: Fri Feb  1 13:11:02 2002
Subject: [Distutils] "clean" doesn't
In-Reply-To: <2mn0ytb0rp.fsf@starship.python.net>
References: <15450.51099.442762.312368@12-248-41-177.client.attbi.com>
 <2mn0ytb0rp.fsf@starship.python.net>
Message-ID: <15450.55798.93457.372526@12-248-41-177.client.attbi.com>

    Michael> Have you tried 

    Michael> python setup.py clean -a

    Michael> ? (like I suggested when you submitted this as a bug)

Nope.  I never saw a response to my bug report.  I assumed nobody had looked
at it.

    Michael> Perhaps this should be the default?

In my mind, yes.  Distutils is very feeble at dependencies.  I would rather
have it delete too much than not enough by default.

-- 
Skip Montanaro (skip@pobox.com - http://www.mojam.com/)


From jjl@pobox.com  Sat Feb  2 16:25:02 2002
From: jjl@pobox.com (John J. Lee)
Date: Sat Feb  2 16:25:02 2002
Subject: [Distutils] _spawn_posix fails, command line works??
In-Reply-To: <2madut1obl.fsf@starship.python.net>
Message-ID: <Pine.SOL.4.30.0202022122560.579-100000@mimosa.csv.warwick.ac.uk>

On 1 Feb 2002, Michael Hudson wrote:
[...]
> I don't *think* there *should* be any difference between posix & windows.

Yes, we agree.

> There may well be in practice.
[...]

Yes, there is.


John



From just@letterror.com  Tue Feb  5 16:31:02 2002
From: just@letterror.com (Just van Rossum)
Date: Tue Feb  5 16:31:02 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
Message-ID: <20020205223047-r01010800-ae7d4b26-0920-010c@10.0.0.23>

A while back I posted about Darwin (OSX) needs to run ranlib when creating
static libraries. I've created a patch and wanted to run it by you guys. Does
the patch below look reasonable? Thanks,

Just


Index: unixccompiler.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/unixccompiler.py,v
retrieving revision 1.38
diff -c -3 -r1.38 unixccompiler.py
*** unixccompiler.py    2001/12/11 05:04:24     1.38
--- unixccompiler.py    2002/02/05 21:26:44
***************
*** 17,23 ****
  
  __revision__ = "$Id: unixccompiler.py,v 1.38 2001/12/11 05:04:24 fdrake Exp $"
  
! import string, re, os
  from types import *
  from copy import copy
  from distutils import sysconfig
--- 17,23 ----
  
  __revision__ = "$Id: unixccompiler.py,v 1.38 2001/12/11 05:04:24 fdrake Exp $"
  
! import string, re, os, sys
  from types import *
  from copy import copy
  from distutils import sysconfig
***************
*** 61,66 ****
--- 61,69 ----
                     'archiver'     : ["ar", "-cr"],
                     'ranlib'       : None,
                    }
+ 
+     if sys.platform.startswith("darwin"):
+         executables['ranlib'] = ["ranlib"]
  
      # Needed for the filename generation methods provided by the base
      # class, CCompiler.  NB. whoever instantiates/uses a particular



From goodger@users.sourceforge.net  Tue Feb  5 21:34:01 2002
From: goodger@users.sourceforge.net (David Goodger)
Date: Tue Feb  5 21:34:01 2002
Subject: [Distutils] Optik in the stdlib?
Message-ID: <B886006D.1E395%goodger@users.sourceforge.net>

Has anyone looked into getting Optik__ accepted into Python's standard
library? From past experience I know that modifying Lib/getopt.py is
off-limits; perhaps an "Adding a High-Level Option Module" PEP is in
order? Yes, I am volunteering to write & champion a PEP.

__ http://optik.sourceforge.net/

I'd like to use Optik for command-line tools in the documentation
projects I'm working on (see my sig). If I hope to eventually get them
into the stdlib, as I do, I can't use unrelated modules not already in
the stdlib.

Optik seems to be a generalized and reworked superset of Distutils'
fancy_getopt.py (also originally written by Greg Ward). Are there any
features of fancy_getopt missing from Optik? Unfortunately,
fancy_getopt has no external documentation (although the code *is*
well commented) so it's not reasonable to expect projects to use it.

Are there any plans to replace fancy_getopt in Distutils with Optik? I
realize their interfaces are not 100% compatible.

Question for Greg: How would you compare the two modules?

-- 
David Goodger    goodger@users.sourceforge.net    Open-source projects:
 - Python Docstring Processing System: http://docstring.sourceforge.net
 - reStructuredText: http://structuredtext.sourceforge.net
 - The Go Tools Project: http://gotools.sourceforge.net



From mwh@python.net  Wed Feb  6 05:48:01 2002
From: mwh@python.net (Michael Hudson)
Date: Wed Feb  6 05:48:01 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
In-Reply-To: Just van Rossum's message of "Tue,  5 Feb 2002 22:30:44 +0100"
References: <20020205223047-r01010800-ae7d4b26-0920-010c@10.0.0.23>
Message-ID: <2madumx4xu.fsf@starship.python.net>

Just van Rossum <just@letterror.com> writes:

> A while back I posted about Darwin (OSX) needs to run ranlib when
> creating static libraries. I've created a patch and wanted to run it
> by you guys. Does the patch below look reasonable? Thanks,

Looks harmless enough to me.

Cheers,
M.

-- 
  My hat is lined with tinfoil for protection in the unlikely event
  that the droid gets his PowerPoint presentation working.
                               -- Alan W. Frame, alt.sysadmin.recovery


From thomas.heller@ion-tof.com  Wed Feb  6 06:58:01 2002
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Feb  6 06:58:01 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
References: <20020205223047-r01010800-ae7d4b26-0920-010c@10.0.0.23>
Message-ID: <0a2701c1af05$619cd550$e000a8c0@thomasnotebook>

From: "Just van Rossum" <just@letterror.com>
> + 
> +     if sys.platform.startswith("darwin"):
> +         executables['ranlib'] = ["ranlib"]

Also looks harmless to me, although I would prefer
something *not* using string methods, so that compatibility
to 1.5.2 is retained (does anyone care besides myself?).

Thomas



From andersjm@dancontrol.dk  Wed Feb  6 07:30:02 2002
From: andersjm@dancontrol.dk (Anders J. Munch)
Date: Wed Feb  6 07:30:02 2002
Subject: [Distutils] CCompiler signature
Message-ID: <009201c1af09$e549ccb0$2501a8c0@quebec>

I'm considering writing a no-op CCompiler implementation that instead
of actually compiling anything just outputs which files would have
been compiled and with which options.  The idea is that I'd take this
information and add the files to Setup.local manually, in order to
produce a statically linked executable.  (See
<news:3c5fe73f$0$204$edfadb0f@dspool01.news.tele.dk> on why I want to
do that.)

But reading ccompiler.py I can't figure out what which signature such
a class should implement.  CCompiler claims to be an abstract base
class but is in reality jam packed with implementation.  So which
methods are utility methods that can be ignored and which are part of
the interface which must be implemented for distutils to work?  Does a
compiler implementation class have to derive from CCompiler?

I presume that adding a module with a CCompiler derived class and
giving it an entry in compiler_class is sufficient to implement a new
compiler for distutils, am I right?  I wish there was an overview
document to explain the distutils architecture.

Using python 2.2 on Win2k.

- Anders





From mal@lemburg.com  Wed Feb  6 08:00:02 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Feb  6 08:00:02 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
References: <20020205223047-r01010800-ae7d4b26-0920-010c@10.0.0.23> <0a2701c1af05$619cd550$e000a8c0@thomasnotebook>
Message-ID: <3C6128AC.5AC17F53@lemburg.com>

Thomas Heller wrote:
> 
> From: "Just van Rossum" <just@letterror.com>
> > +
> > +     if sys.platform.startswith("darwin"):
> > +         executables['ranlib'] = ["ranlib"]
> 
> Also looks harmless to me, although I would prefer
> something *not* using string methods, so that compatibility
> to 1.5.2 is retained (does anyone care besides myself?).

I do and since many people are still using 1.5.2 we should keep
distutils 1.5.2-safe for at least a few more rounds.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From mal@lemburg.com  Wed Feb  6 08:08:02 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Feb  6 08:08:02 2002
Subject: [Distutils] CCompiler signature
References: <009201c1af09$e549ccb0$2501a8c0@quebec>
Message-ID: <3C612A9A.8771E573@lemburg.com>

"Anders J. Munch" wrote:
> 
> I'm considering writing a no-op CCompiler implementation that instead
> of actually compiling anything just outputs which files would have
> been compiled and with which options.  The idea is that I'd take this
> information and add the files to Setup.local manually, in order to
> produce a statically linked executable.  (See
> <news:3c5fe73f$0$204$edfadb0f@dspool01.news.tele.dk> on why I want to
> do that.)
> 
> But reading ccompiler.py I can't figure out what which signature such
> a class should implement.  CCompiler claims to be an abstract base
> class but is in reality jam packed with implementation.  So which
> methods are utility methods that can be ignored and which are part of
> the interface which must be implemented for distutils to work?  Does a
> compiler implementation class have to derive from CCompiler?

It probably should since CCompiler is not an abstract class, but
a base class with lots of working method implementations.
 
> I presume that adding a module with a CCompiler derived class and
> giving it an entry in compiler_class is sufficient to implement a new
> compiler for distutils, am I right?  I wish there was an overview
> document to explain the distutils architecture.

I'd try to take one of the existing compiler modules and
simply replace the compile and link methods with implementations
which write the information you require to some external file.
To register the compiler, you'll only have to edit the ccompile.py
file -- gee, I wish there was a better way to tweak the compiler
settings in distutils via the setup() entry API.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From thomas.heller@ion-tof.com  Wed Feb  6 08:31:12 2002
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Feb  6 08:31:12 2002
Subject: [Distutils] Another string-method call in distutils
Message-ID: <0b9001c1af12$74e9b530$e000a8c0@thomasnotebook>

Another recent change which doesn_t run in 1.5.2, and a proposed patch:

Thomas

Index: msvccompiler.py
===================================================================
RCS file: /cvsroot/python/distutils/distutils/msvccompiler.py,v
retrieving revision 1.44
diff -c -r1.44 msvccompiler.py
*** msvccompiler.py 2002/01/29 10:23:42 1.44
--- msvccompiler.py 2002/02/06 13:22:11
***************
*** 117,126 ****
                      if string.upper(p) == path:
                          V = string.split(v,';')
                          for v in V:
!                             try:
!                                 v = v.encode("mbcs")
!                             except UnicodeError:
!                                 pass
                              if v == '' or v in L: continue
                              L.append(v)
                          break
--- 117,127 ----
                      if string.upper(p) == path:
                          V = string.split(v,';')
                          for v in V:
!                             if hasattr(v, "encode"):
!                                 try:
!                                     v = v.encode("mbcs")
!                                 except UnicodeError:
!                                     pass
                              if v == '' or v in L: continue
                              L.append(v)
                          break




From slash@dotnetslash.net  Wed Feb  6 08:50:03 2002
From: slash@dotnetslash.net (Mark W. Alexander)
Date: Wed Feb  6 08:50:03 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
In-Reply-To: <3C6128AC.5AC17F53@lemburg.com>
Message-ID: <Pine.LNX.4.21.0202060846061.16629-100000@llave.eproinet.com>

On Wed, 6 Feb 2002, M.-A. Lemburg wrote:

> Thomas Heller wrote:
> > 
> > From: "Just van Rossum" <just@letterror.com>
> > > +
> > > +     if sys.platform.startswith("darwin"):
> > > +         executables['ranlib'] = ["ranlib"]
> > 
> > Also looks harmless to me, although I would prefer
> > something *not* using string methods, so that compatibility
> > to 1.5.2 is retained (does anyone care besides myself?).
> 
> I do and since many people are still using 1.5.2 we should keep
> distutils 1.5.2-safe for at least a few more rounds.

Ditto. I've got some HP's that are being "deprecated", so I don't want
to fight getting python 2 packaged and rolled out. I'm just now
getting 2 to my Solaris boxes because of all the dependencies I've
got. Based on my experience, 1.5.2 is going to be around a while on
non-linux platforms.

mwa



From mal@lemburg.com  Wed Feb  6 08:52:02 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed Feb  6 08:52:02 2002
Subject: [Distutils] Another string-method call in distutils
References: <0b9001c1af12$74e9b530$e000a8c0@thomasnotebook>
Message-ID: <3C6134D5.4A9494D8@lemburg.com>

Thomas Heller wrote:
> 
> Another recent change which doesn_t run in 1.5.2, and a proposed patch:

+1 from here.
 
> Thomas
> 
> Index: msvccompiler.py
> ===================================================================
> RCS file: /cvsroot/python/distutils/distutils/msvccompiler.py,v
> retrieving revision 1.44
> diff -c -r1.44 msvccompiler.py
> *** msvccompiler.py 2002/01/29 10:23:42 1.44
> --- msvccompiler.py 2002/02/06 13:22:11
> ***************
> *** 117,126 ****
>                       if string.upper(p) == path:
>                           V = string.split(v,';')
>                           for v in V:
> !                             try:
> !                                 v = v.encode("mbcs")
> !                             except UnicodeError:
> !                                 pass
>                               if v == '' or v in L: continue
>                               L.append(v)
>                           break
> --- 117,127 ----
>                       if string.upper(p) == path:
>                           V = string.split(v,';')
>                           for v in V:
> !                             if hasattr(v, "encode"):
> !                                 try:
> !                                     v = v.encode("mbcs")
> !                                 except UnicodeError:
> !                                     pass
>                               if v == '' or v in L: continue
>                               L.append(v)
>                           break
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From andersjm@dancontrol.dk  Wed Feb  6 10:43:02 2002
From: andersjm@dancontrol.dk (Anders J. Munch)
Date: Wed Feb  6 10:43:02 2002
Subject: [Distutils] CCompiler signature
References: <009201c1af09$e549ccb0$2501a8c0@quebec> <3C612A9A.8771E573@lemburg.com>
Message-ID: <00eb01c1af24$c785c240$2501a8c0@quebec>

> "Anders J. Munch" wrote:
> > Does a
> > compiler implementation class have to derive from CCompiler?
> 
> It probably should since CCompiler is not an abstract class, but
> a base class with lots of working method implementations.

Right, CCompiler is not an abstract class however the docstring and
several comments say otherwise.  Supposedly the implementations are
just "utility methods" which are there for the convenience of
subclasses but not required.

> > I presume that adding a module with a CCompiler derived class and
> > giving it an entry in compiler_class is sufficient to implement a new
> > compiler for distutils, am I right?  I wish there was an overview
> > document to explain the distutils architecture.
> 
> I'd try to take one of the existing compiler modules and
> simply replace the compile and link methods with implementations
> which write the information you require to some external file.

Just compile and link?  Not set_executable or add_library or
link_executable or library_option or ... ?  The problem with modifying
one of the existing concrete classes is that they don't override the
same set of methods that I'll want to override.  I just want to know
which methods constitute the public interface used by CCompiler
clients so that I can override those and only those.

- Anders




From mats@laplaza.org  Wed Feb  6 18:25:01 2002
From: mats@laplaza.org (Mats Wichmann)
Date: Wed Feb  6 18:25:01 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
In-Reply-To: <Pine.LNX.4.21.0202060846061.16629-100000@llave.eproinet.co
 m>
References: <3C6128AC.5AC17F53@lemburg.com>
Message-ID: <5.1.0.14.1.20020206132532.03bf0660@204.151.72.2>

 >Based on my experience, 1.5.2 is going to be around a while on
 >non-linux platforms.

It's going to be around a while on /Linux/ platforms, too.
RedHat 8.0 is the first chance to stamp it out from that
vendor; that's at least six months away; then give a reasonable
amount of time during which people haven't rolled forward
(many RedHat oldtimers avoid all .0 releases :-) - at least
another year, probably more.




From sanner@scripps.edu  Thu Feb  7 10:56:01 2002
From: sanner@scripps.edu (Michel Sanner)
Date: Thu Feb  7 10:56:01 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
In-Reply-To: <5.1.0.14.1.20020206132532.03bf0660@204.151.72.2>
Message-ID: <Pine.SGI.4.21.0202070751490.1547670-100000@hermes>

We are stilll using  1.5.2 just because it is about twice as fast  as 2.1
on our application and about 30% faster than 2.0. Apparently 2.2 is
somewhere between 2.1 and 2.0 in terms of performance.
So pleaser do not pahse out 1.5.2 before a new version of the interpretor
with comparable execution performance is available


-----------------------------------------------------------------------

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sanner@scripps.edu                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------


On Wed, 6 Feb 2002, Mats Wichmann wrote:

>  >Based on my experience, 1.5.2 is going to be around a while on
>  >non-linux platforms.
> 
> It's going to be around a while on /Linux/ platforms, too.
> RedHat 8.0 is the first chance to stamp it out from that
> vendor; that's at least six months away; then give a reasonable
> amount of time during which people haven't rolled forward
> (many RedHat oldtimers avoid all .0 releases :-) - at least
> another year, probably more.
> 
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 



From mal@lemburg.com  Thu Feb  7 11:51:13 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Feb  7 11:51:13 2002
Subject: [Distutils] static libs, unixccompiler.py, darwin
References: <Pine.SGI.4.21.0202070751490.1547670-100000@hermes>
Message-ID: <3C62B024.897650F0@lemburg.com>

Michel Sanner wrote:
> 
> We are stilll using  1.5.2 just because it is about twice as fast  as 2.1
> on our application and about 30% faster than 2.0. Apparently 2.2 is
> somewhere between 2.1 and 2.0 in terms of performance.
> So pleaser do not pahse out 1.5.2 before a new version of the interpretor
> with comparable execution performance is available

OTOH, machines got at least 3-5 times faster since the days of 
Python 1.5.2 :-)

Still, you're right. Python 1.5.2 compatibility should be preserved
for at least another year.

Thomas, I'd suggest you check in the fixes for string method
usage -- perhaps distutils could grow some helpers in util.py
to aid with this, e.g. filename(str) and platformname() ?!

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From frog@creatis.insa-lyon.fr  Thu Feb  7 13:36:01 2002
From: frog@creatis.insa-lyon.fr (Eric Boix)
Date: Thu Feb  7 13:36:01 2002
Subject: [Distutils] [XML PyXML-0.7-1] fix to demo/dom/generate_xml1.py
Message-ID: <20020207193518.G26548@tux.creatis.insa-lyon.fr>

	Hi,

	Apparentrly the demo/dom/generate_xml1.py is broken:
Traceback (most recent call last):
  File "PyXML/demo/dom/generate_xml1.py", line 17, in ?
    doc = implementation.createHTMLDocument('', 'mydoc', dt)
TypeError: createHTMLDocument() takes exactly 2 arguments (4 given)

	I could have it running with the following changes :

----------------------------------------
   doc = implementation.createHTMLDocument('', 'mydoc', dt)
---
>     doc = implementation.createDocument(None, 'mydoc', dt)
23c18
<     new_elem = doc.createElementNS('', 'spam')
---
>     new_elem = doc.createElementNS(None, 'spam')
26c21
<     new_elem.setAttributeNS('', 'eggs', 'sunnysideup')
---
>     new_elem.setAttributeNS(None, 'eggs', 'sunnysideup')
38,39c33,34
<     import xml.doc.ext
<     xml.doc.ext.Print(doc)
---
>     from xml.dom import ext
>     ext.Print(doc)
----------------------------------------

Am I correct or am I missing something ?


I also was unable to run an Aspn Python Cookbook XML example 
(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52242)
because I hit the bug registered with request ID 510080, see
 http://sourceforge.net/tracker/index.php?func=detail&aid=510080&group_id=6473&atid=106473

Any one with a work around or fix on this ?

	Yours,
	Eric Boix

Creatis : Medical imaging lab
http://www.creatis.insa-lyon.fr/~frog



From gward@python.net  Sat Feb  9 22:12:02 2002
From: gward@python.net (Greg Ward)
Date: Sat Feb  9 22:12:02 2002
Subject: [Distutils] Re: [optik] Optik in the stdlib?
In-Reply-To: <B886006D.1E395%goodger@users.sourceforge.net>
References: <B886006D.1E395%goodger@users.sourceforge.net>
Message-ID: <20020210031101.GA11352@gerg.ca>

On 05 February 2002, David Goodger said:
> Has anyone looked into getting Optik__ accepted into Python's standard
> library?

I haven't inquired on python-dev, but it's something I'd like to do for
Python 2.3.  There are a few small tweaks I'd like to make to Optik
before I consider it "done", but it's pretty damn close.

> From past experience I know that modifying Lib/getopt.py is
> off-limits; perhaps an "Adding a High-Level Option Module" PEP is in
> order? Yes, I am volunteering to write & champion a PEP.

I don't know if a PEP is necessary just to add a module (or a couple of
modules).

> Optik seems to be a generalized and reworked superset of Distutils'
> fancy_getopt.py (also originally written by Greg Ward).

That's a fair assessment.

> Are there any features of fancy_getopt missing from Optik?

Optik uses the wrap_text() function currently provided by fancy_getopt.
This function should be moved elsewhere in the standard library -- maybe
somewhere in the distutils package, maybe somewhere else.  (Heck, maybe
into Optik itself if it goes in the standard lib.)  But I'm pretty sure
Optik is a complete superset of (and completely superior to)
fancy_getopt.

> Are there any plans to replace fancy_getopt in Distutils with Optik? I
> realize their interfaces are not 100% compatible.

Yes, I have had ideas along these lines.  The distutils.fancy_getopt
module would shrink to a wrapper around Optik so that existing Distutils
commands could continue to work -- this is particularly important for
people who subclass commands and add their own options.  That's about as
far as I've gotten.

> Question for Greg: How would you compare the two modules?

fancy_getopt was a quick hack motivated by the obvious fact that the
standard getopt is totally inadequate for applications like the
Distutils that need an extensible option-parsing framework.  It was
toned down ("the simplest thing possible that actually works") because I
didn't want to get distracted by cooking up an all-singing, all-dancing
option-parsing solution just for the Distutils.

Optik is the all-singing, all-dancing option-parsing solution that I
have always wanted.

        Greg
-- 
Greg Ward - geek                                        gward@python.net
http://starship.python.net/~gward/
"When I hear the word `culture', I reach for my gun." --Goebbels
"When I hear the word `Microsoft', *I* reach for *my* gun." --me


From just@letterror.com  Mon Feb 11 10:48:03 2002
From: just@letterror.com (Just van Rossum)
Date: Mon Feb 11 10:48:03 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation broken?
Message-ID: <20020211164753-r01010800-31f0fb02-0920-010c@10.0.0.23>

I'm running into an odd problem with CVS Python:

  running build_ext
  Traceback (most recent call last):
  [ ... ]
    File "/usr/local/lib/python2.2/distutils/sysconfig.py", line 434, in
get_config_vars
      func()
    File "/usr/local/lib/python2.2/distutils/sysconfig.py", line 322, in
_init_posix
      raise DistutilsPlatformError(my_msg)
  distutils.errors.DistutilsPlatformError: invalid Python installation: unable
to open /usr/local/lib/python2.3/config/Makefile (No such file or directory)


This is my Python version, freshly checked out from CVS:
Python 2.3a0 (#22, Feb 11 2002, 16:05:10) 


So distutils is looking for /usr/local/lib/python2.3, whereas the lib is still
in /usr/local/lib/python2.2. Is my install broken or is distutils confused?

Thanks,

Just


From mal@lemburg.com  Mon Feb 11 11:10:01 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Feb 11 11:10:01 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation
 broken?
References: <20020211164753-r01010800-31f0fb02-0920-010c@10.0.0.23>
Message-ID: <3C67EC9E.EA2FA2DB@lemburg.com>

I guess you have to reinstall Python. The version number changed
from 2.2 to 2.3a0 a few days ago. And you have to call distutils
with the Python 2.3a0 version, of course.

Could also be that distutils doesn't like the "2.3a0" version 
number; I remember some problems with this in the 2.2 cycle.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From just@letterror.com  Mon Feb 11 11:20:02 2002
From: just@letterror.com (Just van Rossum)
Date: Mon Feb 11 11:20:02 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation  broken?
In-Reply-To: <3C67EC9E.EA2FA2DB@lemburg.com>
Message-ID: <20020211171856-r01010800-ee9c6e04-0920-010c@10.0.0.23>

M.-A. Lemburg wrote:

> I guess you have to reinstall Python.

That's what I did, (after I deleted the build dir and did "make clean", and ran
./configure again), but the Python lib still installs in
/usr/lib/local/python2.2/.

> The version number changed
> from 2.2 to 2.3a0 a few days ago. And you have to call distutils
> with the Python 2.3a0 version, of course.
> 
> Could also be that distutils doesn't like the "2.3a0" version 
> number; I remember some problems with this in the 2.2 cycle.

Just


From jack@oratrix.com  Mon Feb 11 11:24:01 2002
From: jack@oratrix.com (Jack Jansen)
Date: Mon Feb 11 11:24:01 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation broken?
In-Reply-To: <20020211164753-r01010800-31f0fb02-0920-010c@10.0.0.23>
Message-ID: <CA28C8CA-1F0B-11D6-8176-0030655234CE@oratrix.com>

I think this is the result of a recent checkin that replaced "2.2+" with 
"2.3a0" in the version string.

But: that fix was especially done for distutils, if I remember the 
checkin message corretly...

On Monday, February 11, 2002, at 04:47 , Just van Rossum wrote:

> I'm running into an odd problem with CVS Python:
>
>   running build_ext
>   Traceback (most recent call last):
>   [ ... ]
>     File "/usr/local/lib/python2.2/distutils/sysconfig.py", line 434, in
> get_config_vars
>       func()
>     File "/usr/local/lib/python2.2/distutils/sysconfig.py", line 322, in
> _init_posix
>       raise DistutilsPlatformError(my_msg)
>   distutils.errors.DistutilsPlatformError: invalid Python installation: 
> unable
> to open /usr/local/lib/python2.3/config/Makefile (No such file or 
> directory)
>
>
> This is my Python version, freshly checked out from CVS:
> Python 2.3a0 (#22, Feb 11 2002, 16:05:10)
>
>
> So distutils is looking for /usr/local/lib/python2.3, whereas the lib 
> is still
> in /usr/local/lib/python2.2. Is my install broken or is distutils 
> confused?
>
> Thanks,
>
> Just
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From akuchlin@mems-exchange.org  Mon Feb 11 11:30:01 2002
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon Feb 11 11:30:01 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation broken?
In-Reply-To: <20020211164753-r01010800-31f0fb02-0920-010c@10.0.0.23>
References: <20020211164753-r01010800-31f0fb02-0920-010c@10.0.0.23>
Message-ID: <20020211162944.GC29750@ute.mems-exchange.org>

On Mon, Feb 11, 2002 at 04:47:38PM +0100, Just van Rossum wrote:
>So distutils is looking for /usr/local/lib/python2.3, whereas the lib is still
>in /usr/local/lib/python2.2. Is my install broken or is distutils confused?

The configure.in has an outdated version number.  Does the patch below
help?  (I'll go ahead and check it in no matter what.)

--amk

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.289
diff -u -r1.289 configure.in
--- configure.in	1 Jan 2002 18:41:32 -0000	1.289
+++ configure.in	11 Feb 2002 16:25:10 -0000
@@ -6,7 +6,7 @@
 
 # Set VERSION so we only need to edit in one place (i.e., here)
 AC_SUBST(VERSION)
-VERSION=2.2
+VERSION=2.3
 
 # Arguments passed to configure.
 AC_SUBST(CONFIG_ARGS)



From just@letterror.com  Mon Feb 11 11:55:01 2002
From: just@letterror.com (Just van Rossum)
Date: Mon Feb 11 11:55:01 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation broken?
In-Reply-To: <20020211162944.GC29750@ute.mems-exchange.org>
Message-ID: <20020211175402-r01010800-b16bb494-0920-010c@10.0.0.23>

Andrew Kuchling wrote:

> The configure.in has an outdated version number.  Does the patch below
> help?  (I'll go ahead and check it in no matter what.)

Sure does! Thanks.

Just


From mal@lemburg.com  Mon Feb 11 12:12:03 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon Feb 11 12:12:03 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation
 broken?
References: <20020211171856-r01010800-ee9c6e04-0920-010c@10.0.0.23>
Message-ID: <3C67FB33.1F7BEF79@lemburg.com>

Just van Rossum wrote:
> 
> M.-A. Lemburg wrote:
> 
> > I guess you have to reinstall Python.
> 
> That's what I did, (after I deleted the build dir and did "make clean", and ran
> ./configure again), but the Python lib still installs in
> /usr/lib/local/python2.2/.

Hmm, that's strange. Looking in configure, I see:
"""
# Set VERSION so we only need to edit in one place (i.e., here)

VERSION=2.2
"""

Someone obviously forgot to change the version number in 
configure. I'll fix that.
 
> > The version number changed
> > from 2.2 to 2.3a0 a few days ago. And you have to call distutils
> > with the Python 2.3a0 version, of course.
> >
> > Could also be that distutils doesn't like the "2.3a0" version
> > number; I remember some problems with this in the 2.2 cycle.
> 
> Just

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From mwh@python.net  Mon Feb 11 12:29:02 2002
From: mwh@python.net (Michael Hudson)
Date: Mon Feb 11 12:29:02 2002
Subject: [Distutils] Re: [Python-Dev] Want to co-design and implement a logging module?
In-Reply-To: Greg Ward's message of "Mon, 11 Feb 2002 11:13:54 -0500"
References: <200202040235.g142ZPG16987@pcp742651pcs.reston01.va.comcast.net> <20020204094149.C31089@ActiveState.com> <20020211150338.GA20372@gerg.ca> <2mheoom3va.fsf@starship.python.net> <20020211161354.GB20794@gerg.ca>
Message-ID: <2mlme0j5ck.fsf@starship.python.net>

Greg Ward <gward@python.net> writes:

> On 11 February 2002, Michael Hudson said:
> > But I believe that 1.5.2 compatibility is still relavent for
> > distutils
> 
> I'm still catching up on distutils-sig traffic from the past year, so I
> don't want to overcommit myself here... but I've been thinking that we
> (I) should do one last Distutils release that is 1.5.2 compatible, and
> then we can decide if future Distutils releases will stick to
> 2.0-compatibility, or are allowed to require the version of Python that
> they go with.

I;m not sure that idea will get widespread support.

> However, please *don't* everyone jump in and start a thread about this
> now.  I'll take it up on distutils-sig when I've caught up.

But I'll wait until you get caught up.

> > I had a go at implementing a very KISS approach to distutils logging
> > this morning and found what I was doing conflicted horribly with
> > distutils' current practice, so I stopped.
> 
> Probably because the Distutils current practice is an ill-thought-out
> mishmash.  That'll have to be fixed first, I suspect.  Sorry.  ;-(

It was more to do with options processing (the fact that basically
speaking all options translate to attributes on some object) than
logging.  I suspect I could have used Optik more easily...

I'm also not sure how politic it would be to take an axe to the
interfaces of the various *util modules.

Cheers,
M.

-- 
  You sound surprised.  We're talking about a government department
  here - they have procedures, not intelligence.
                                            -- Ben Hutchings, cam.misc


From tim.one@comcast.net  Mon Feb 11 17:38:02 2002
From: tim.one@comcast.net (Tim Peters)
Date: Mon Feb 11 17:38:02 2002
Subject: [Distutils] distutils + CVS Python prob. -- or is my installation
 broken?
In-Reply-To: <CA28C8CA-1F0B-11D6-8176-0030655234CE@oratrix.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEFNNLAA.tim.one@comcast.net>

[Jack Jansen]
> I think this is the result of a recent checkin that replaced "2.2+" with
> "2.3a0" in the version string.

Yes:  yell at me if I screwed someone here!

> But: that fix was especially done for distutils, if I remember the
> checkin message corretly...

Well, it was especially done for me <wink>, because it was impossible to use
distutils to build concurrent 2.2 and 2.3 versions so long as CVS Python
still had a version string starting with "2.2".

BTW, distutils should define and use a common utility function to find the
Python version, instead of slicing a hard-coded three characters off of
sys.version in multiple places.



From skip@pobox.com  Tue Feb 12 15:54:01 2002
From: skip@pobox.com (Skip Montanaro)
Date: Tue Feb 12 15:54:01 2002
Subject: [Distutils] building static extension modules?
Message-ID: <15465.33060.997629.540700@beluga.mojam.com>

Is there a way to build extension modules for static linkage and have them
get incorporated into libpython2.2.a using distutils?  I tried

    python setup.py --help
    python setup.py --help-commands
    python setup.py build --help
    python setup.py build_ext --help

and also gazed briefly at the docs, but couldn't find anything.

Thx,

-- 
Skip Montanaro (skip@pobox.com - http://www.mojam.com/)


From hinsen@cnrs-orleans.fr  Tue Feb 12 16:20:02 2002
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Tue Feb 12 16:20:02 2002
Subject: [Distutils] building static extension modules?
In-Reply-To: <15465.33060.997629.540700@beluga.mojam.com>
References: <15465.33060.997629.540700@beluga.mojam.com>
Message-ID: <m3heomjt25.fsf@localhost.localdomain>

Skip Montanaro <skip@pobox.com> writes:

> Is there a way to build extension modules for static linkage and have them
> get incorporated into libpython2.2.a using distutils?  I tried

To the best of my knowledge there is no such possibility. And with the
disappearance of the old Makefile.pre.in mechanism in Python 2.2,
I see no simple and portable way of building an interpreter with
statically linked modules at all. Definitely a loss.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From hinsen@cnrs-orleans.fr  Wed Feb 13 15:10:01 2002
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Wed Feb 13 15:10:01 2002
Subject: [Distutils] Option question
Message-ID: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>

I am trying to put the option --no-rpm-opt-flags to bdist_rpm
permanently into setup.cfg. According to my understanding of the manual,
I should add the line

  no-rpm-opt-flags = 1

But that doesn't work:

  running bdist_rpm
  error: error in setup.cfg: command 'bdist_rpm' has no such option 'no_rpm_opt_flags'

What am I doing wrong?

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From thomas.heller@ion-tof.com  Wed Feb 13 15:21:00 2002
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Wed Feb 13 15:21:00 2002
Subject: [Distutils] Option question
References: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>
Message-ID: <12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook>

From: "Konrad Hinsen" <hinsen@cnrs-orleans.fr>
> 
> I am trying to put the option --no-rpm-opt-flags to bdist_rpm
> permanently into setup.cfg. According to my understanding of the manual,
> I should add the line
> 
>   no-rpm-opt-flags = 1
> 
> But that doesn't work:
> 
>   running bdist_rpm
>   error: error in setup.cfg: command 'bdist_rpm' has no such option 'no_rpm_opt_flags'
> 
> What am I doing wrong?
It seems no_rpm_opt_flags is not a 'first-class' option (whatever this may be ;-).
According to the source no_rpm_opt_flags is a negative option - inverting the value
of use_rpm_opt_flags. You should probably try to add the line
  use_rpm_opt_flags = 0
in the setup.cfg file (but this is simply guesswork).

> 
> Konrad.

HTH,

Thomas



From hinsen@cnrs-orleans.fr  Thu Feb 14 04:38:02 2002
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Thu Feb 14 04:38:02 2002
Subject: [Distutils] Option question
In-Reply-To: <12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook>
References: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>
 <12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook>
Message-ID: <m3lmdwpfqq.fsf@chinon.cnrs-orleans.fr>

"Thomas Heller" <thomas.heller@ion-tof.com> writes:

> According to the source no_rpm_opt_flags is a negative option - inverting the value
> of use_rpm_opt_flags. You should probably try to add the line
>   use_rpm_opt_flags = 0
> in the setup.cfg file (but this is simply guesswork).

Good start, this is accepted - but has no effect, unfortunately.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From mal@lemburg.com  Thu Feb 14 04:56:02 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Feb 14 04:56:02 2002
Subject: [Distutils] Option question
References: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>
 <12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook> <m3lmdwpfqq.fsf@chinon.cnrs-orleans.fr>
Message-ID: <3C6B897F.50B8FFDF@lemburg.com>


Konrad Hinsen wrote:
> 
> "Thomas Heller" <thomas.heller@ion-tof.com> writes:
> 
> > According to the source no_rpm_opt_flags is a negative option - inverting the value
> > of use_rpm_opt_flags. You should probably try to add the line
> >   use_rpm_opt_flags = 0
> > in the setup.cfg file (but this is simply guesswork).
> 
> Good start, this is accepted - but has no effect, unfortunately.

I suggest you take the debugger and skip to the end of 
finalize_options() in bdist_rpm.py. I don't see any magic in
that routine which would reset .use_rpm_opt_flags, so the
magic has to be built into some other part of distutils ;-)

What Thomas suggest *should* work. If it doesn't, then
something is wrong and we have a bug.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From hinsen@cnrs-orleans.fr  Thu Feb 14 06:07:01 2002
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Thu Feb 14 06:07:01 2002
Subject: [Distutils] Option question
In-Reply-To: <3C6B897F.50B8FFDF@lemburg.com> (mal@lemburg.com)
References: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>
 <12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook> <m3lmdwpfqq.fsf@chinon.cnrs-orleans.fr> <3C6B897F.50B8FFDF@lemburg.com>
Message-ID: <200202141106.g1EB6Bi19199@chinon.cnrs-orleans.fr>

> I suggest you take the debugger and skip to the end of 
> finalize_options() in bdist_rpm.py. I don't see any magic in
> that routine which would reset .use_rpm_opt_flags, so the
> magic has to be built into some other part of distutils ;-)
> 
> What Thomas suggest *should* work. If it doesn't, then
> something is wrong and we have a bug.

I think so... Here's what happens. When I specify the option
--no-rpm-opt-flags on the command line, the value of
self.use_rpm_opt_flags in the bdist_rpm code is the integer 0.
When I set use_rpm_opt_flags=0 in setup.cfg, the value becomes
the string '0'. For the subsequent test "if self.use_rpm_opt_flags",
that makes a big difference.

I'll file a bug report about this.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


From thomas.heller@ion-tof.com  Thu Feb 14 14:40:02 2002
From: thomas.heller@ion-tof.com (Thomas Heller)
Date: Thu Feb 14 14:40:02 2002
Subject: [Distutils] Option question
References: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>	<12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook> <m3lmdwpfqq.fsf@chinon.cnrs-orleans.fr> <3C6B897F.50B8FFDF@lemburg.com> <200202141106.g1EB6Bi19199@chinon.cnrs-orleans.fr>
Message-ID: <017b01c1b58f$4d42d1a0$e000a8c0@thomasnotebook>

There's another bug related to options specified in the
configuration file. The following entry

  [install]
  verbose=0

will also lead to self.verbose having a value of '0' (string)
at the end of the finalize_options() method, and
The problem is in dist.py, near line 821:

            bool_opts = map(translate_longopt, command_obj.boolean_options)
            ...
            try:
                is_string = type(value) is StringType
                if neg_opt.has_key(option) and is_string:
                    setattr(command_obj, neg_opt[option], not strtobool(value))
                elif option in bool_opts and is_string:
                    setattr(command_obj, option, strtobool(value))
                elif hasattr(command_obj, option):
                    setattr(command_obj, option, value)
                else:
                    raise DistutilsOptionError, \
                          ("error in %s: command '%s' has no such option '%s'"
                           % (source, command_name, option))
            except ValueError, msg:
                raise DistutilsOptionError, msg

Since command_obj.boolean_options does not include 'verbose' (verbose
is an attribute of class Distribution), 'verbose' is not recognized as
a boolean option, and the value will not be converted by strtobool().

Hm, reading the dist.py source, I find about the [global] section...
It seems the [globals] section is not documented anywhere.
I should probably use

    [global]
    verbose=0

instead, but, nevertheless, the above also looks like a bug to me.
I propose the following fix (Note that the #ugh! comment is copied
from another, similar code on line 343 ;-)
Or should instead using global options in non-global sections of
the config file be forbidden?

Thomas

Index: dist.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/dist.py,v
retrieving revision 1.53
diff -c -r1.53 dist.py
*** dist.py 6 Dec 2001 20:51:35 -0000 1.53
--- dist.py 14 Feb 2002 19:35:25 -0000
***************
*** 822,828 ****
                  is_string = type(value) is StringType
                  if neg_opt.has_key(option) and is_string:
                      setattr(command_obj, neg_opt[option], not strtobool(value))
!                 elif option in bool_opts and is_string:
                      setattr(command_obj, option, strtobool(value))
                  elif hasattr(command_obj, option):
                      setattr(command_obj, option, value)
--- 822,828 ----
                  is_string = type(value) is StringType
                  if neg_opt.has_key(option) and is_string:
                      setattr(command_obj, neg_opt[option], not strtobool(value))
!                 elif (option in bool_opts + ['verbose', 'dry_run']) and is_string: # ugh!
                      setattr(command_obj, option, strtobool(value))
                  elif hasattr(command_obj, option):
                      setattr(command_obj, option, value)




From mal@lemburg.com  Thu Feb 14 15:46:25 2002
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu Feb 14 15:46:25 2002
Subject: [Distutils] Option question
References: <200202132009.g1DK9kL16087@chinon.cnrs-orleans.fr>	<12c301c1b4cb$e5a74530$e000a8c0@thomasnotebook> <m3lmdwpfqq.fsf@chinon.cnrs-orleans.fr> <3C6B897F.50B8FFDF@lemburg.com> <200202141106.g1EB6Bi19199@chinon.cnrs-orleans.fr> <017b01c1b58f$4d42d1a0$e000a8c0@thomasnotebook>
Message-ID: <3C6C21CF.EB092724@lemburg.com>

Thomas Heller wrote:
> ...another setup.cfg bug...
> I propose the following fix (Note that the #ugh! comment is copied
> from another, similar code on line 343 ;-)

Looks, uhm, ok... :-)

> Or should instead using global options in non-global sections of
> the config file be forbidden?

What are (or would be) the semantics of having a local and a global
option of the same name ?
 
-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/


From Jack.Jansen@oratrix.nl  Sun Feb 17 17:27:16 2002
From: Jack.Jansen@oratrix.nl (Jack Jansen)
Date: Sun Feb 17 17:27:16 2002
Subject: [Distutils] Linking against the interpreter - how?
Message-ID: <5A95B2D4-23F5-11D6-B306-003065517236@oratrix.nl>

I'm in the process of converting Python to use two-level 
namespaces on Mac OS X (a way to make sure globals in different 
extension modules don't bite each other) but I'm running into a 
problem.

If you use two level namespaces the LD command line for the 
extension module needs to specify the executable into which the 
extension will be loaded. But unfortunately the Makefile 
variable for this, BLDFLAGS, does double duty: it is used during 
the build process for building the standard extension modules 
(with the setup.py in the Python source directory) and it is 
later (when Python is installed, and you're building a new 
extension module) picked up by distutils.

In the first case BLDFLAGS would need to contain the pathname of 
the Python executable in the build directory. In the second case 
it would need to contain the pathname of the installed Python.

Does anyone have any suggestions on how I could fix this?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -



From mwh@python.net  Mon Feb 18 04:48:05 2002
From: mwh@python.net (Michael Hudson)
Date: Mon Feb 18 04:48:05 2002
Subject: [Distutils] Linking against the interpreter - how?
In-Reply-To: Jack Jansen's message of "Sun, 17 Feb 2002 23:26:14 +0100"
References: <5A95B2D4-23F5-11D6-B306-003065517236@oratrix.nl>
Message-ID: <2m664v9l4r.fsf@starship.python.net>

Jack Jansen <Jack.Jansen@oratrix.nl> writes:

> I'm in the process of converting Python to use two-level 
> namespaces on Mac OS X (a way to make sure globals in different 
> extension modules don't bite each other) but I'm running into a 
> problem.
> 
> If you use two level namespaces the LD command line for the 
> extension module needs to specify the executable into which the 
> extension will be loaded. But unfortunately the Makefile 
> variable for this, BLDFLAGS, does double duty: it is used during 
> the build process for building the standard extension modules 
> (with the setup.py in the Python source directory) and it is 
> later (when Python is installed, and you're building a new 
> extension module) picked up by distutils.
> 
> In the first case BLDFLAGS would need to contain the pathname of 
> the Python executable in the build directory. In the second case 
> it would need to contain the pathname of the installed Python.
> 
> Does anyone have any suggestions on how I could fix this?

Um, can you use a strategy like that of command/build_scripts.py?
I.e. check sysconfig.python_build and then use either sys.executable
or sysconfig.get_config_var("BINDIR") + "python", depending?

Cheers,
M.

-- 
  The use of COBOL cripples the mind; its teaching should, therefore,
  be regarded as a criminal offence.
           -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5


From dma@andrew.cmu.edu  Mon Feb 25 12:26:43 2002
From: dma@andrew.cmu.edu (David Andersen)
Date: Mon Feb 25 12:26:43 2002
Subject: [Distutils] gtk-config
Message-ID: <1027663634.1014639945@DAWSON.PC.CC.CMU.EDU>

I've got a Makefile that uses gtk-config to get the appropriate OpenGL 
includes and libraries:

LDFLAGS = -shared -fPIC $(shell gtk-config --libs gtk gthread) -lGL -lgtkgl
GTK_INCLUDES = $(shell gtk-config --cflags gtk gthread)
CFLAGS =   -I. $(CXX_INCLUDES) $(PYTHON_INCLUDES) $(GTK_INCLUDES)

How do I do the equivalent in a Distutils script?






From jjl@pobox.com  Mon Feb 25 14:24:02 2002
From: jjl@pobox.com (John J. Lee)
Date: Mon Feb 25 14:24:02 2002
Subject: [Distutils] gtk-config
In-Reply-To: <1027663634.1014639945@DAWSON.PC.CC.CMU.EDU>
Message-ID: <Pine.SOL.4.30.0202251919170.22979-100000@primrose.csv.warwick.ac.uk>

On Mon, 25 Feb 2002, David Andersen wrote:

> I've got a Makefile that uses gtk-config to get the appropriate OpenGL
> includes and libraries:
>
> LDFLAGS = -shared -fPIC $(shell gtk-config --libs gtk gthread) -lGL -lgtkgl
> GTK_INCLUDES = $(shell gtk-config --cflags gtk gthread)
> CFLAGS =   -I. $(CXX_INCLUDES) $(PYTHON_INCLUDES) $(GTK_INCLUDES)
>
> How do I do the equivalent in a Distutils script?

Just run gtk-config from setup.py?  Will work on windows and unix
(assuming gtk-config is properly installed, which isn't necessarily true
of course).  Then pass everything to distutils in usual way.


John