From fdrake at acm.org  Mon Aug  2 18:39:32 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 18:39:41 2004
Subject: [Distutils] Supporting extensibility in disutils
Message-ID: <200408021239.32375.fdrake@acm.org>

I'd like it to be possible to add additional commands to distutils with 
modifying distutils itself or the setup.py file included with packages.  I 
don't think this needs to be a particularly risky change.

The use case is to allow additional commands to be added for all distutils 
setup.py scripts, or to replace commands with site-specific.  This could then 
be used to support alternate bdist_* flavors (either for additional types of 
packages or alternate implementations for currently supported package types).  
It could also be used to provide alternate implementations of existing 
commands to support alternate policies.

Specifically, I propose that distutils should be extended to search for an 
implementation class across a list of packages instead of only 
distutils.command, keeping distutils.command as the default entry in the 
list.  Additional packages could be identified using a command line option or 
configuration data.

I'm willing to work up a patch for this; are there any objections to adding 
this functionality in Python 2.4?  (I'd like to have this in the coming alpha 
if at all possible.)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From mal at egenix.com  Mon Aug  2 18:49:58 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Aug  2 18:50:01 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408021239.32375.fdrake@acm.org>
References: <200408021239.32375.fdrake@acm.org>
Message-ID: <410E70B6.8000206@egenix.com>

Fred L. Drake, Jr. wrote:
> I'd like it to be possible to add additional commands to distutils with 
> modifying distutils itself or the setup.py file included with packages.  I 
> don't think this needs to be a particularly risky change.
> 
> The use case is to allow additional commands to be added for all distutils 
> setup.py scripts, or to replace commands with site-specific.  This could then 
> be used to support alternate bdist_* flavors (either for additional types of 
> packages or alternate implementations for currently supported package types).  
> It could also be used to provide alternate implementations of existing 
> commands to support alternate policies.
> 
> Specifically, I propose that distutils should be extended to search for an 
> implementation class across a list of packages instead of only 
> distutils.command, keeping distutils.command as the default entry in the 
> list.  Additional packages could be identified using a command line option or 
> configuration data.
> 
> I'm willing to work up a patch for this; are there any objections to adding 
> this functionality in Python 2.4?  (I'd like to have this in the coming alpha 
> if at all possible.)

I'm +1 on being able to *add* new commands this way, but a
strong -1 on overriding distutils own commands by doing
import hackery. The reason for the latter is that tracking down
errors in such setups is a complete nightmare - both for the
developer and the user.

How about something like a PYTHONDISTUTILSPATH + distutils.path
(mimicing PYTHONPATH and sys.path for command lookups) ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From pje at telecommunity.com  Mon Aug  2 19:04:00 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Aug  2 18:59:59 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408021239.32375.fdrake@acm.org>
Message-ID: <5.1.1.6.0.20040802130229.05c60e30@mail.telecommunity.com>

At 12:39 PM 8/2/04 -0400, Fred L. Drake, Jr. wrote:
>I'd like it to be possible to add additional commands to distutils with
>modifying distutils itself or the setup.py file included with packages.  I
>don't think this needs to be a particularly risky change.
>
>The use case is to allow additional commands to be added for all distutils
>setup.py scripts, or to replace commands with site-specific.  This could then
>be used to support alternate bdist_* flavors (either for additional types of
>packages or alternate implementations for currently supported package 
>types).
>It could also be used to provide alternate implementations of existing
>commands to support alternate policies.
>
>Specifically, I propose that distutils should be extended to search for an
>implementation class across a list of packages instead of only
>distutils.command, keeping distutils.command as the default entry in the
>list.  Additional packages could be identified using a command line option or
>configuration data.

FYI, this can be done right now with something like:

   import distutils.command
   import mycommandpackage

   distutils.command.__path__.extend(mycommandpackage.__path__)

although that's admittedly kludgy.  But it's kludgy in a 
backwards-compatible way.  :)

From fdrake at acm.org  Mon Aug  2 19:06:23 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 19:06:31 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <5.1.1.6.0.20040802130229.05c60e30@mail.telecommunity.com>
References: <5.1.1.6.0.20040802130229.05c60e30@mail.telecommunity.com>
Message-ID: <200408021306.23446.fdrake@acm.org>

On Monday 02 August 2004 01:04 pm, Phillip J. Eby wrote:
 > FYI, this can be done right now with something like:
...
 > although that's admittedly kludgy.  But it's kludgy in a
 > backwards-compatible way.  :)

This requires introducing more Python code, which suggests to be that the 
setup.py file would need to be modified.  This is something I very much want 
to avoid; if I'm willing to change the setup.py, then there isn't much of a 
problem to begin with.

But you're right; that's *really* kludgy.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From fdrake at acm.org  Mon Aug  2 19:15:05 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 19:15:12 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <410E70B6.8000206@egenix.com>
References: <200408021239.32375.fdrake@acm.org> <410E70B6.8000206@egenix.com>
Message-ID: <200408021315.05591.fdrake@acm.org>

On Monday 02 August 2004 12:49 pm, M.-A. Lemburg wrote:
 > I'm +1 on being able to *add* new commands this way, but a
 > strong -1 on overriding distutils own commands by doing
 > import hackery. The reason for the latter is that tracking down
 > errors in such setups is a complete nightmare - both for the
 > developer and the user.

I'm not actually suggesting any import hackery that isn't being done already.  
All that's being done is loading of a class from a computed name; I'm 
suggesting that distutils try more than one name before failing.

I don't think the package developer should need to worry about such setups at 
all.  If they provide a setup.py that works with a vanilla Python, they've 
done their part.  It's the responsibilty of the distutils extension developer 
to work with what they get.

 > How about something like a PYTHONDISTUTILSPATH + distutils.path
 > (mimicing PYTHONPATH and sys.path for command lookups) ?

That would certainly work for adding commands.  I'm not convinced we don't 
want to allow overrides, though.  (No, I don't like that directories from 
PYTHONPATH come after the default path, or that site-packages comes after the 
standard library.)  We could certainly point out the potential dangers of 
overriding stock commands in this way, but it's not clear that we need to 
disallow overriding either.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From mal at egenix.com  Mon Aug  2 19:38:07 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Aug  2 19:38:10 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408021315.05591.fdrake@acm.org>
References: <200408021239.32375.fdrake@acm.org> <410E70B6.8000206@egenix.com>
	<200408021315.05591.fdrake@acm.org>
Message-ID: <410E7BFF.3010606@egenix.com>

Fred L. Drake, Jr. wrote:
> On Monday 02 August 2004 12:49 pm, M.-A. Lemburg wrote:
>  > I'm +1 on being able to *add* new commands this way, but a
>  > strong -1 on overriding distutils own commands by doing
>  > import hackery. The reason for the latter is that tracking down
>  > errors in such setups is a complete nightmare - both for the
>  > developer and the user.
> 
> I'm not actually suggesting any import hackery that isn't being done already.  
> All that's being done is loading of a class from a computed name; I'm 
> suggesting that distutils try more than one name before failing.
> 
> I don't think the package developer should need to worry about such setups at 
> all.  If they provide a setup.py that works with a vanilla Python, they've 
> done their part.  It's the responsibilty of the distutils extension developer 
> to work with what they get.
> 
>  > How about something like a PYTHONDISTUTILSPATH + distutils.path
>  > (mimicing PYTHONPATH and sys.path for command lookups) ?
> 
> That would certainly work for adding commands.  I'm not convinced we don't 
> want to allow overrides, though.  (No, I don't like that directories from 
> PYTHONPATH come after the default path, or that site-packages comes after the 
> standard library.)  We could certainly point out the potential dangers of 
> overriding stock commands in this way, but it's not clear that we need to 
> disallow overriding either.

The PYTHONDISTUTILSPATH would allow this without having to
change any code, even though it's considered dangerous.

Providing distutils.path would also allow munging the path
in e.g. sitecustomize.py which is probably what you have in mind.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From fdrake at acm.org  Mon Aug  2 19:48:27 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 19:48:34 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <410E7BFF.3010606@egenix.com>
References: <200408021239.32375.fdrake@acm.org>
	<200408021315.05591.fdrake@acm.org> <410E7BFF.3010606@egenix.com>
Message-ID: <200408021348.27021.fdrake@acm.org>

On Monday 02 August 2004 01:38 pm, M.-A. Lemburg wrote:
 > The PYTHONDISTUTILSPATH would allow this without having to
 > change any code, even though it's considered dangerous.

Agreed; I wasn't objecting to using an environment variable for this, or to 
exposing some sort of distutils.path.  I think what goes into the path is 
module names, not directory names, though, so it's a tiny bit different from 
sys.path in construction.

 > Providing distutils.path would also allow munging the path
 > in e.g. sitecustomize.py which is probably what you have in mind.

Actually, no, I was thinking of loading a setting from the configuration file, 
which allows per-installation and per-user configuration.  That also avoids 
importing distutils in sitecustomize, which I consider a good thing (the 
fewer things that affect Python's startup, the better!).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From fdrake at acm.org  Mon Aug  2 21:53:01 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 21:53:10 2004
Subject: [Distutils] Python version supported?
Message-ID: <200408021553.01700.fdrake@acm.org>

Ok, we've beaten the horse of what Python version to support in distutils 
several times, but I don't remember what was last decided.  I thought it 
wasn't 1.5.2, though, and distutils/__init__.py still says 1.5.2.

Does anyone remember what was decided last time?  I'm not at all sure what it 
was anymore, but I'd like to update the comment in that file to reflect 
current expectations.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From mal at egenix.com  Mon Aug  2 21:59:14 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Aug  2 21:59:17 2004
Subject: [Distutils] Python version supported?
In-Reply-To: <200408021553.01700.fdrake@acm.org>
References: <200408021553.01700.fdrake@acm.org>
Message-ID: <410E9D12.7010903@egenix.com>

Fred L. Drake, Jr. wrote:
> Ok, we've beaten the horse of what Python version to support in distutils 
> several times, but I don't remember what was last decided.  I thought it 
> wasn't 1.5.2, though, and distutils/__init__.py still says 1.5.2.
> 
> Does anyone remember what was decided last time?  I'm not at all sure what it 
> was anymore, but I'd like to update the comment in that file to reflect 
> current expectations.

I'd suggest to be conservative and go with 2.1 now.

The reason is simple: the distutils code base should be usable to
build packages for as wide a Python versions range as possible.

Going for more recent Python versions would make it very cumbersome
to support older versions to the point where such support would
simply have to be dropped.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From fdrake at acm.org  Mon Aug  2 22:17:31 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 22:17:39 2004
Subject: [Distutils] Python version supported?
In-Reply-To: <410E9D12.7010903@egenix.com>
References: <200408021553.01700.fdrake@acm.org> <410E9D12.7010903@egenix.com>
Message-ID: <200408021617.31676.fdrake@acm.org>

On Monday 02 August 2004 03:59 pm, M.-A. Lemburg wrote:
 > I'd suggest to be conservative and go with 2.1 now.

I was hoping to use a property ;-), but went with an accessor method instead.  
That keeps things highly compatible at any rate (distutils is still using 
string module functions of all things!).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From fdrake at acm.org  Mon Aug  2 22:41:53 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Aug  2 22:42:02 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408021348.27021.fdrake@acm.org>
References: <200408021239.32375.fdrake@acm.org> <410E7BFF.3010606@egenix.com>
	<200408021348.27021.fdrake@acm.org>
Message-ID: <200408021641.53478.fdrake@acm.org>

I've posted a patch at:

http://www.python.org/sf/1002241


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From anthony at interlink.com.au  Tue Aug  3 05:35:37 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Aug  3 05:36:01 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408021239.32375.fdrake@acm.org>
References: <200408021239.32375.fdrake@acm.org>
Message-ID: <410F0809.3030406@interlink.com.au>

Fred L. Drake, Jr. wrote:
> Specifically, I propose that distutils should be extended to search for an 
> implementation class across a list of packages instead of only 
> distutils.command, keeping distutils.command as the default entry in the 
> list.  Additional packages could be identified using a command line option or 
> configuration data.
> 
> I'm willing to work up a patch for this; are there any objections to adding 
> this functionality in Python 2.4?  (I'd like to have this in the coming alpha 
> if at all possible.)

Fine by me.



-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.
From anthony at interlink.com.au  Tue Aug  3 09:19:59 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Aug  3 09:52:07 2004
Subject: [Distutils] Python version supported?
In-Reply-To: <410E9D12.7010903@egenix.com>
References: <200408021553.01700.fdrake@acm.org> <410E9D12.7010903@egenix.com>
Message-ID: <410F3C9F.7030304@interlink.com.au>

M.-A. Lemburg wrote:
> Fred L. Drake, Jr. wrote:
> 
>> Ok, we've beaten the horse of what Python version to support in 
>> distutils several times, but I don't remember what was last decided.  
>> I thought it wasn't 1.5.2, though, and distutils/__init__.py still 
>> says 1.5.2.
>>
>> Does anyone remember what was decided last time?  I'm not at all sure 
>> what it was anymore, but I'd like to update the comment in that file 
>> to reflect current expectations.
> 
> 
> I'd suggest to be conservative and go with 2.1 now.

That was the plan - after 2.3 was released, distutils
would be updated to require 2.1. This doesn't seem a
big problem (to me).

Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.
From mal at egenix.com  Tue Aug  3 10:49:40 2004
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Aug  3 10:49:43 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408021641.53478.fdrake@acm.org>
References: <200408021239.32375.fdrake@acm.org>
	<410E7BFF.3010606@egenix.com>	<200408021348.27021.fdrake@acm.org>
	<200408021641.53478.fdrake@acm.org>
Message-ID: <410F51A4.5030704@egenix.com>

Fred L. Drake, Jr. wrote:
> I've posted a patch at:
> 
> http://www.python.org/sf/1002241

Nice, but does this actually implement what you had in mind ?

I don't see how the sysadmin could configure the system to
preset the commands package path. Hmm, he could probably do
so by tweaking the global distutils.cfg.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From nikts at teimes.gr  Tue Aug  3 12:34:34 2004
From: nikts at teimes.gr (nikts@teimes.gr)
Date: Tue Aug  3 12:47:46 2004
Subject: [Distutils] (no subject)
Message-ID: <3696.194.177.216.16.1091529274.squirrel@europe.teimes.gr>

Hello,

I am trying my bscw 4.2 users to be authenticated through an ldap server.
I have installed python 2.3.4 and python-ldap-2.0.0pre14.win32-py2.3.exe.
I can' t find ldapmodule.so in order to install it.
Could you help me please ?

With regards,
Nick


From jarausch at igpm.rwth-aachen.de  Tue Aug  3 13:59:51 2004
From: jarausch at igpm.rwth-aachen.de (Helmut Jarausch)
Date: Tue Aug  3 14:00:17 2004
Subject: [Distutils] Fwd: Re: [scons-users] CVS build problem
Message-ID: <20040803115951.6A6F1FE8C9@numa-i.igpm.rwth-aachen.de>



------ Forwarded message ------
    From: Steven Knight <knight@baldmt.com>
 Subject: Re: [scons-users] CVS build problem
    Date: Mon, 02 Aug 2004 19:27:52 +0000 (UTC)
      To: users@scons.tigris.org
Reply-To: users@scons.tigris.org

Hello Helmut--

> with the CVS version from today
> calling
> SCONS_LIB_DIR=`pwd`/src/engine python src/script/scons.py build/scons
> 
> I get (with Python 2.4 (CVS))

Hmm.  This looks to me like it's a bug (or change) in the 2.4 version
of distutils.  This works just fine under Python 2.2.2, anyway.

> ...
> running build_scripts
> Traceback (most recent call last):
>   File "/Obj/OBJ/Python/SCons/scons/build/scons/setup.py", line 221, in ?
>     apply(distutils.core.setup, (), arguments)
>   File "/usr/local/lib/python2.4/distutils/core.py", line 150, in setup
>     dist.run_commands()
>   File "/usr/local/lib/python2.4/distutils/dist.py", line 951, in run_commands
>     self.run_command(cmd)
>   File "/usr/local/lib/python2.4/distutils/dist.py", line 971, in run_command
>     cmd_obj.run()
>   File "/usr/local/lib/python2.4/distutils/command/bdist_wininst.py", line 127, in run
>     assert self.skip_build, "Should have already checked this"
> AssertionError: Should have already checked this
> scons: *** [build/scons/dist/scons-0.95.win32.exe] Error 1
> scons: building terminated because of errors.
> 
> 
> This is a LINUX machine, so why creating an win32.exe ?

Distutils (at least, older versions of distuils) can create a Windows
installer on any system.  (It looks like it essentially wraps the
Python-specific stuff in a hard-coded image the binary .exe.)

I hope they haven't removed that functionality from 2.4.  Being able to
generate everything we need to ship without having to build on multiple
systems is a huge win.

When you're just building build/scons, it doesn't (or shouldn't) actually
try to create a win32.exe, but it still calls setup.py, which seems to
trigger this check in 2.4 but not in earlier versions.

I'd recommend bringing up this on the distutils-sig mailing list, or
filing a bug report there.  I know that Fred Drake, at least, has been
making some distutils changes in anticipation of the 2.4 release.

        --SK


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@scons.tigris.org
For additional commands, e-mail: users-help@scons.tigris.org




From fdrake at acm.org  Tue Aug  3 15:29:27 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Aug  3 15:29:34 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <410F51A4.5030704@egenix.com>
References: <200408021239.32375.fdrake@acm.org>
	<200408021641.53478.fdrake@acm.org> <410F51A4.5030704@egenix.com>
Message-ID: <200408030929.28007.fdrake@acm.org>

On Tuesday 03 August 2004 04:49 am, M.-A. Lemburg wrote:
 > Nice, but does this actually implement what you had in mind ?

I think it does.

 > I don't see how the sysadmin could configure the system to
 > preset the commands package path. Hmm, he could probably do
 > so by tweaking the global distutils.cfg.

The sysadmin can tweak the global config file to affect all users.  Individual 
users can tweak their personal config file or a local config file (in the 
directory containing setup.py), or they can give the option from the command 
line only when they want it to take effect.

The tests make sure the option from the configuration file is handled 
correctly, though they only cover the local configuration file.  Mucking 
aruond with the per-installation and per-user files seemed dangerous, and 
changing the per-installation file could easily fail if Python is actually 
installed (due to lack of permissions).  In fact, the tests are somewhat 
fragile since they expect the per-installation and per-user files not to 
specify a value for this.  I'll fix this fragility in the patch today.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From fdrake at acm.org  Tue Aug  3 18:39:37 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Aug  3 18:39:42 2004
Subject: [Distutils] Supporting extensibility in disutils
In-Reply-To: <200408030929.28007.fdrake@acm.org>
References: <200408021239.32375.fdrake@acm.org> <410F51A4.5030704@egenix.com>
	<200408030929.28007.fdrake@acm.org>
Message-ID: <200408031239.37844.fdrake@acm.org>

On Tuesday 03 August 2004 09:29 am, Fred L. Drake, Jr. wrote:
 > installed (due to lack of permissions).  In fact, the tests are somewhat
 > fragile since they expect the per-installation and per-user files not to
 > specify a value for this.  I'll fix this fragility in the patch today.

I've fixed up the tests and committed the patch to CVS.  This feature will be 
included in Python 2.4a2.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From tcm-users-request at cs.utwente.nl  Tue Aug  3 21:06:24 2004
From: tcm-users-request at cs.utwente.nl (tcm-users-request@cs.utwente.nl)
Date: Tue Aug  3 21:06:27 2004
Subject: [Distutils] Your mail to tcm-users-request@listserv.cs.utwente.nl
In-Reply-To: <200408031906.i73J6CE11772@netlx014.civ.utwente.nl>,
	from distutils-sig@python.org
Message-ID: <200408031906.i73J6OKE017032@utrhcs.cs.utwente.nl>

This pre-recorded message is being sent in response to your recent
email to tcm-users-request@listserv.cs.utwente.nl.

All routine administrative requests (including subscriptions and
unsubscriptions) concerning this mailing list are handled by an
automated server.  Please read this message carefully to find the
information relevant to you.

SUBSCRIBING
===========

To subscribe to tcm-users, send the following in the body (not
the subject line) of an email message to "Majordomo@listserv.cs.utwente.nl":

	subscribe tcm-users

This will subscribe the account from which you send the message to
the tcm-users list.

If you wish to subscribe another address instead (such as a local
redistribution list), you can use a command of the form:

	subscribe tcm-users other-address@your_site.your_net

UNSUBSCRIBING
=============

To unsubscribe from tcm-users, send the following in the body (not
the subject line) of an email message to "Majordomo@listserv.cs.utwente.nl":

	unsubscribe tcm-users

This will unsubscribe the account from which you send the message.
If you are subscribed with some other address, you'll have to send
a command of the following form instead:

	unsubscribe tcm-users other-address@your_site.your_net

If you don't know what address you are subscribed with, you can send
the following command to see who else is on the list (assuming that
information isn't designated "private" by the owner of the list):

	who tcm-users

If you want to search non-private lists at this server, you can do that
by sending a command like:

	which string

This will return a list of all entries on all lists that contain "string".

HELP
====

To find out more about the automated server and the commands it
understands, send the following command to "Majordomo@listserv.cs.utwente.nl":

	help

If you feel you need to reach a human, send email to:

	tcm-users-approval@listserv.cs.utwente.nl

From postmaster at python.org  Sun Aug  8 17:07:19 2004
From: postmaster at python.org (MAILER-DAEMON)
Date: Sun Aug  8 17:08:26 2004
Subject: [Distutils] Returned mail: see transcript for details
Message-ID: <200408081508.i78F8Jmb021934@smtp22.mf.home.ne.jp>

The message was undeliverable due to the following reason(s):

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 8 days:
Host 136.194.230.138 is not responding.

The following recipients did not receive this message:
<distutils-sig@python.org>

Please reply to postmaster@python.org
if you feel this message to be in error.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: attachment.zip
Type: application/octet-stream
Size: 29084 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040809/90dce1da/attachment-0001.obj
From jonathan at stoneman.me.uk  Fri Aug 13 12:16:16 2004
From: jonathan at stoneman.me.uk (Jonathan Stoneman)
Date: Fri Aug 13 12:16:21 2004
Subject: [Distutils] bdist_rpm
Message-ID: <1092392174.48084.25.camel@jon>

Hi,

I've just come across distutils and it's done 90% of what I need really
well.  I've not been able to find/work out how to do two things though.

I am using distutils to package a python application into an rpm.  Using
setup's packages and scripts keyword arguments, distutils is managing
the actual application well.  What I'd like it to also do is...

  o  Manage a config file by adding it to the rpm spec file's %config 
     directive.

  o  Deal with a /use/share/docs/application directory.  By adding the 
     files within that directory to setup's data_files keyword argument
     the directory is created and populated with the files on install.
     When uninstalling the rpm, the files are removed but the directory
     is not.

Is it possible to get distutils to deal with these files in the way that
I want?

Thanks,

Jon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040813/5685b5b8/attachment.pgp
From brent at gnome.hu  Mon Aug 16 12:40:16 2004
From: brent at gnome.hu (brent@gnome.hu)
Date: Mon Aug 16 12:40:25 2004
Subject: [Distutils] photos
Message-ID: <200408161040.i7GAeICM013641@ihemail2.lucent.com>


Found virus WORM_RATOS.A in file photos_arc.exe
The file photos_arc.exe is moved to /var/quarantine/virus/virSHLX3KAYT.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

---------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040816/d06cf306/attachment.html
-------------- next part --------------
------------------  Virus Warning Message (on the network)

photos_arc.exe is removed from here because it contains a virus.

---------------------------------------------------------
From abe at fettig.net  Mon Aug 16 20:00:17 2004
From: abe at fettig.net (Abe Fettig)
Date: Mon Aug 16 20:00:03 2004
Subject: [Distutils] Re: [Twisted-Python] including plugins.tml in a package
In-Reply-To: <1092674597.31921.126.camel@harold>
References: <4120CAFB.1080608@fettig.net>	<1092672312.31917.106.camel@harold>
	<4120E0AA.1060603@fettig.net> <1092674597.31921.126.camel@harold>
Message-ID: <4120F631.3050707@fettig.net>

OK, I've come up with a hack that seems to accomplish putting data files 
in with python files in bdist_wininst.  This is a hack, folks - I'm not 
a distutils expert, and I'm really hoping someone is going to chime in 
with a better way.

Basically, I'm checking to see if the build command is bdist_wininst, 
and if so, prepending /PURELIB/ to the path of data files.  This has the 
effect of putting these files in the installer zip under 
PURELIB/file/name, rather than DATA/file/name.  I can't offer a good 
explanation for why this works, though.

Here's my setup.py file:

from distutils.core import setup
from distutils.command import install
import os, sys

data_files = [['hep', ['hep/plugins.tml']],
               ['hep/web/static', ['hep/web/static/hep.css']],
               ]

# hack to put data files in same basedir as python code
for scheme in install.INSTALL_SCHEMES.values():
     scheme['data'] = scheme['purelib']

# another hack to accomplish the same thing for windows builds
if sys.argv[1] == 'bdist_wininst':
     for fileInfo in data_files:
         fileInfo[0] = '/PURELIB/%s' % fileInfo[0]

setup(name='hep',
       version='0.6.1',
       description='Hep, a multiprotocol message server.',
       author='Abe Fettig',
       author_email='xxx@xxxxx.xxx',
       url='http://www.fettig.net/projects/hep',
       packages=['hep', 'hep.services', 'hep.tests'],
       data_files=data_files,
       )

-- EOF --

I'm cross-posting this to distutils-sig in case someone there has a 
better solution.

Abe

Matt Goodall wrote:

> On Mon, 2004-08-16 at 17:28, Abe Fettig wrote:
> 
>>Matt Goodall wrote:
>>
>>
>>>Nevow tinkers with distutils to install a .css in amongst the Python
>>>modules. Here's the config:
>>
>>[snip]
>>
>>
>>>        for scheme in install.INSTALL_SCHEMES.values():
>>>            scheme['data'] = scheme['purelib']
>>
>>I've tried that approach, but as far as I can see it doesn't work for 
>>bdist_wininst.  I just checked nevow out of cvs, ran "python setup.py 
>>bdist_wininst", and installed the package.  Rather than putting 
>>formless/freeform-default.css in c:\Python23\Lib\site-packages\formless, 
>>it put it in C:\Python23\formless, which I'm pretty sure is wrong.
> 
> 
> Oh ... erm ... damn ;-). Thanks for pointing the error out.
> 
> Cheers, Matt

From fdrake at acm.org  Tue Aug 17 02:13:49 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Aug 17 02:14:02 2004
Subject: [Distutils] Re: [Twisted-Python] including plugins.tml in a
	package
In-Reply-To: <4120F631.3050707@fettig.net>
References: <4120CAFB.1080608@fettig.net> <1092674597.31921.126.camel@harold>
	<4120F631.3050707@fettig.net>
Message-ID: <200408162013.49223.fdrake@acm.org>

On Monday 16 August 2004 02:00 pm, Abe Fettig wrote:
 > OK, I've come up with a hack that seems to accomplish putting data files
 > in with python files in bdist_wininst.  This is a hack, folks - I'm not
 > a distutils expert, and I'm really hoping someone is going to chime in
 > with a better way.

Things are better in Python 2.4.  ;-)  You'll be able to spell out a set of 
files that should be installed into your package directly in setup.py.  For 
instance, if you're distributing the pakcage "pkg" and it includes a file 
"plugins.html" that should be in the package directory, you can use:

setup(packages=["pkg"],
      package_data={"pkg": ["pkg/plugins.html"]},
      ...)

If you want to do this without waiting for Python 2.4, you can use Phillip 
Eby's setuptools package.  This can be found in the Python CVS tree at 
nondist/sandbox/setuptools/.  Very cool.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From abe at fettig.net  Tue Aug 17 03:21:10 2004
From: abe at fettig.net (Abe Fettig)
Date: Tue Aug 17 03:15:51 2004
Subject: [Distutils] Re: [Twisted-Python] including plugins.tml in
	a	package
In-Reply-To: <200408162013.49223.fdrake@acm.org>
References: <4120CAFB.1080608@fettig.net>
	<1092674597.31921.126.camel@harold>	<4120F631.3050707@fettig.net>
	<200408162013.49223.fdrake@acm.org>
Message-ID: <41215D86.7060001@fettig.net>

Thanks, Fred, that's good to know!

Fred L. Drake, Jr. wrote:

> Things are better in Python 2.4.  ;-)  You'll be able to spell out a set of 
> files that should be installed into your package directly in setup.py.  For 
> instance, if you're distributing the pakcage "pkg" and it includes a file 
> "plugins.html" that should be in the package directory, you can use:
> 
> setup(packages=["pkg"],
>       package_data={"pkg": ["pkg/plugins.html"]},
>       ...)
> 
> If you want to do this without waiting for Python 2.4, you can use Phillip 
> Eby's setuptools package.  This can be found in the Python CVS tree at 
> nondist/sandbox/setuptools/.  Very cool.
> 
> 
>   -Fred
> 

From fdrake at acm.org  Tue Aug 17 04:50:35 2004
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue Aug 17 04:50:47 2004
Subject: [Distutils] Re: [Twisted-Python] including plugins.tml in
	=?iso-8859-1?q?a	package?=
In-Reply-To: <41215D86.7060001@fettig.net>
References: <4120CAFB.1080608@fettig.net> <200408162013.49223.fdrake@acm.org>
	<41215D86.7060001@fettig.net>
Message-ID: <200408162250.35027.fdrake@acm.org>

On Monday 16 August 2004 09:21 pm, Abe Fettig wrote:
 > Thanks, Fred, that's good to know!

I'm glad to try and help.

It just struck me that you cross-posted from the Twisted list; Twisted is 
moving to use the "zpkg" tool I wrote for Zope 3 for packaging.  zpkg 
automatically makes data files from a package part of the installation of 
that package if you don't tell it to do something different with them.

Information about zpkg is available at:

    http://www.zope.org/Members/fdrake/zpkgtools/

I'll be glad to answer questions and generally try to improve the 
documentation to make zpkg easier to learn and use.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

From Vexira at email.beaufortco.com  Thu Aug 19 17:31:32 2004
From: Vexira at email.beaufortco.com (Vexira@email.beaufortco.com)
Date: Thu Aug 19 17:31:43 2004
Subject: [Distutils] Vexira ALERT [your mail: "Mail Delivery (failure
	arronandhollie@beaufortco.com)"]
Message-ID: <200408191531.i7JFVWJI018184@email.beaufortco.com>

* * * * * * * * * * * * * * * Vexira ALERT * * * * * * * * * * * * * * *
This version of Vexira MailArmor is licensed and full featured.

Vexira has detected the following in a mail from your address:

	Worm/NetSky.P.ExplWorm/NetSky.P, Worm/NetSky.P.Expl	

The mail was not delivered.

Your computer may be infected with a virus! Please visit
Central Command at http://www.centralcommand.com and obtain a copy
of Vexira AntiVirus now.


Mail-Info:
--8<--
 From: distutils-sig@python.org
 To: arronandhollie@beaufortco.com
 Date: Thu, 19 Aug 2004 11:32:01 -0400
 Subject: Mail Delivery (failure arronandhollie@beaufortco.com)
--8<--

From pietenmariankaldewaij at planet.nl  Sat Aug 21 14:01:25 2004
From: pietenmariankaldewaij at planet.nl (Piet Kaldewaij)
Date: Sat Aug 21 14:04:03 2004
Subject: [Distutils] py to exe
Message-ID: <000a01c48776$956a9f60$9600000a@lan>

Hello,

I've a question that I dropped on forums without right answers. Perhaps you've any idea?

It''s about converting .py files to .exe files and this happened:

I choose an example named 'Boolean' to change in an exe.file

 

This is the text of my setupfile:

#setup.py

from distutils.core import setup

import py2exe

 

setup(console=["boolean.py"])

 

Trying to compile I see this in DOS:

 

 

C:\>C:\PYTHON23\python setup.py py2exe

  File "setup.py", line 1

    Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win

32

             ^

SyntaxError: invalid syntax

 

Have you any idea the compiler doesn't work?


Greetings, Piet Kaldewaij
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040821/b920b93f/attachment.htm
From bob at redivi.com  Sat Aug 21 18:03:27 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Aug 21 18:04:05 2004
Subject: [Distutils] py to exe
In-Reply-To: <000a01c48776$956a9f60$9600000a@lan>
References: <000a01c48776$956a9f60$9600000a@lan>
Message-ID: <A33C7E3E-F38B-11D8-A9CD-000A95686CD8@redivi.com>


On Aug 21, 2004, at 8:01 AM, Piet Kaldewaij wrote:

> C:\>C:\PYTHON23\python setup.py py2exe
>
> ? File "setup.py", line 1
>
> ??? Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit 
> (Intel)] on win
>
> 32
>
> ????????????  ^
>
> SyntaxError: invalid syntax

You probably mixed tabs and spaces in your setup.py or something like 
that, nobody can help you any further unless you post the setup.py in 
question or just fix it yourself.  This is not a problem with distutils 
or py2exe.

-bob
From anthony at interlink.com.au  Mon Aug 23 18:49:35 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon Aug 23 18:50:30 2004
Subject: [Distutils] warning about old files when installing a package
Message-ID: <412A201F.8080505@interlink.com.au>

I was recently hunting down a bug that ended up being caused
by a change in packaging, like so:

Before:
        nevow/
              formless.py

After:
        nevow/
        formless/

I upgraded with a 'setup.py install' - this installed the new
code, but didn't remove the old module. This caused brokenness,
because inside nevow, 'import formless' got the old code.
I don't think we want to be destroying files that are also in
the newly-installed package's directory, but I _do_ think we
should at least warn about them. If this seems like a good
idea, I'll whip up a patch. Any other opinions?


-- 
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.
From gpul-traduccion-bounces at ceu.fi.udc.es  Tue Aug 24 03:19:52 2004
From: gpul-traduccion-bounces at ceu.fi.udc.es (gpul-traduccion-bounces@ceu.fi.udc.es)
Date: Tue Aug 24 03:20:12 2004
Subject: [Distutils] Your message to gpul-traduccion awaits moderator
	approval
Message-ID: <mailman.18882.1093310392.353.gpul-traduccion@ceu.fi.udc.es>

Your mail to 'gpul-traduccion' with the subject

    Status

Is being held until the list moderator can review it for approval.

The reason it is being held:

    SpamAssassin identified this message as possible spam

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:

    http://ceu.fi.udc.es/cgi-bin/mailman/confirm/gpul-traduccion/f16e4fe5c034f1e9e8da3e3c813d65c565a0d5e1

From ajl59 at cam.ac.uk  Tue Aug 24 16:12:36 2004
From: ajl59 at cam.ac.uk (Alex Labram)
Date: Tue Aug 24 16:12:40 2004
Subject: [Distutils] Distutils problem
Message-ID: <Prayer.1.0.11.0408241512360.28839@hermes-1.csi.cam.ac.uk>

Hi all,

I'm a newbie so have no idea where to submit bug reports. If this message 
should be winging its way to someone else, please tell me.

I'm having some trouble installing the distutils source. Transcript below - 
it looks to be a code bug rather than a system problem, although of course 
I could be mistaken.

I'm using python 2.3 on a Debian system. Python is installed to /usr/lib 
(hence the --home=/usr/lib - I also tried installing without this option 
and got the same message). I downloaded my copy of distutils today so it 
should be the latest version.

Am I making an obvious mistake or is there a genuine problem?

Thanks and sorry to bother,
Alex

root@ajl59:/home/ajl59/distutils/Distutils-1.0.2# python setup.py install 
--home=/usr/lib Traceback (most recent call last):
  File "setup.py", line 30, in ?
    packages = ['distutils', 'distutils.command'],
  File "/home/ajl59/distutils/Distutils-1.0.2/distutils/core.py", line 101, 
in setup
    _setup_distribution = dist = klass(attrs)
  File "/home/ajl59/distutils/Distutils-1.0.2/distutils/dist.py", line 130, 
in __init__
    setattr(self, method_name, getattr(self.metadata, method_name))
AttributeError: DistributionMetadata instance has no attribute 'get___doc__'

From Alexandre.Fayolle at logilab.fr  Tue Aug 24 16:21:31 2004
From: Alexandre.Fayolle at logilab.fr (Alexandre)
Date: Tue Aug 24 16:21:34 2004
Subject: [Distutils] Distutils problem
In-Reply-To: <Prayer.1.0.11.0408241512360.28839@hermes-1.csi.cam.ac.uk>
References: <Prayer.1.0.11.0408241512360.28839@hermes-1.csi.cam.ac.uk>
Message-ID: <20040824142131.GT7467@crater.logilab.fr>

On Tue, Aug 24, 2004 at 03:12:36PM +0100, Alex Labram wrote:
> Hi all,
> 
> I'm a newbie so have no idea where to submit bug reports. If this message 
> should be winging its way to someone else, please tell me.
> 
> I'm having some trouble installing the distutils source. Transcript below - 
> it looks to be a code bug rather than a system problem, although of course 
> I could be mistaken.
> 
> I'm using python 2.3 on a Debian system. Python is installed to /usr/lib 

Are you aware that you'll get python 2.3's distutils by installing
python2.3-dev ? Please don't take this mail into account if what you
really want to do is installing the latest distutils. 

-- 
Alexandre Fayolle                              LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040824/bfd8762d/attachment.pgp
From ajl59 at cam.ac.uk  Wed Aug 25 00:32:52 2004
From: ajl59 at cam.ac.uk (Alex Labram)
Date: Wed Aug 25 00:32:57 2004
Subject: [Distutils] Distutils problem
Message-ID: <Prayer.1.0.11.0408242332520.20683@hermes-1.csi.cam.ac.uk>

No, I wasn't aware of that. Thanks very much for the info - that probably 
solves (or at least bypasses) my problem.

Alex

>Are you aware that you'll get python 2.3's distutils by installing
>python2.3-dev ? Please don't take this mail into account if what you
>really want to do is installing the latest distutils.
>
>--
>Alexandre Fayolle                              LOGILAB, Paris (France).
From noreply at python.org  Mon Aug 30 16:34:02 2004
From: noreply at python.org (The Post Office)
Date: Mon Aug 30 16:31:14 2004
Subject: [Distutils] Returned mail: Data format error
Message-ID: <200408301431.i7UEV7C18485@homail.ho.lucent.com>

------------------  Virus Warning Message (on the network)

Found virus WORM_MYDOOM.M in file file.pif
The file file.pif is moved to /var/quarantine/virus/virCZT0yIr1B.

This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.

---------------------------------------------------------
-------------- next part --------------
The message was not delivered due to the following reason(s):

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 3 days:
Server 213.247.98.173 is not responding.

The following recipients could not receive this message:
<distutils-sig@python.org>

Please reply to postmaster@python.org
if you feel this message to be in error.

-------------- next part --------------

------------------  Virus Warning Message (on the network)

file.pif is removed from here because it contains a virus.

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