From reinout at vanrees.org  Tue Sep  1 09:42:28 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 1 Sep 2009 07:42:28 +0000 (UTC)
Subject: [Distutils] buildout's tests fail for me
Message-ID: <slrnh9pk34.2nla.reinout@isengrim.local>

I've made a reasonable number of recipes and there's one thing in buildout
that I want to fix.  In order to fix it, I need to be able to run the tests,
of course.  But the tests fail for me.  Tens of them.  (I've posted about this
before). 

The kind of errors you get:

Expected:
    setuptools.egg
    -  zc.buildout.egg
Got:
    -  setuptools.egg-link
    -  zc.buildout.egg

As far as I can see, there's one root cause for all of them: setuptools is
detected as a development egg on line 346 of buildout.py.  There was at least
one other developer that was plagued by exact the same problem.  He was on
linux, I'm on osx.  So it is not specifically os-dependent.

I've tried installing setuptools (globally) in several ways.  Whether I use
macport's version or the downloaded setuptools egg: no difference.


So:

- Is this a known issue?

- Is this something I really should fix in my own setup?

- Is there a known fix that can be applied to the test setup?


I'd really like to contribute :-)

Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From jim at zope.com  Tue Sep  1 12:26:25 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 1 Sep 2009 06:26:25 -0400
Subject: [Distutils] buildout's tests fail for me
In-Reply-To: <slrnh9pk34.2nla.reinout@isengrim.local>
References: <slrnh9pk34.2nla.reinout@isengrim.local>
Message-ID: <1099b90b0909010326x42d21531r530bea8eb7d96419@mail.gmail.com>

On Tue, Sep 1, 2009 at 3:42 AM, Reinout van Rees<reinout at vanrees.org> wrote:
> - Is this something I really should fix in my own setup?
>
> - Is there a known fix that can be applied to the test setup?

Yes. Use a clean Python built from source with nothing in site-packages.

To build the buildout checkout, use dev.py, which is a special
bootstrap used when working on buildout itself.

Jim

-- 
Jim Fulton

From reinout at vanrees.org  Tue Sep  1 15:19:27 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 1 Sep 2009 13:19:27 +0000 (UTC)
Subject: [Distutils] buildout's tests fail for me
References: <slrnh9pk34.2nla.reinout@isengrim.local>
	<1099b90b0909010326x42d21531r530bea8eb7d96419@mail.gmail.com>
Message-ID: <slrnh9q7qv.189j.reinout@isengrim.local>

On 2009-09-01, Jim Fulton <jim at zope.com> wrote:
> On Tue, Sep 1, 2009 at 3:42 AM, Reinout van Rees<reinout at vanrees.org> wrote:
>> - Is this something I really should fix in my own setup?
>>
>> - Is there a known fix that can be applied to the test setup?
>
> Yes. Use a clean Python built from source with nothing in site-packages.

Ok, that helped partially.  But then I got an error like:

 distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch:
 now "10.3" but "10.5" during configure

Waargh, that was in python2.4-checking code.  So I tried running the buildout
with python2.4 instead of the 2.5 I've been using: success.

I don't know if the python24/python25 difference is known/intended, but in any
case: I can run the tests now.

> To build the buildout checkout, use dev.py, which is a special
> bootstrap used when working on buildout itself.

I haven't seen that dev.py documented.  Would a "development instructions for
buildout itself" be good to add to the documentation?


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From gary.poster at canonical.com  Tue Sep  1 15:59:47 2009
From: gary.poster at canonical.com (Gary Poster)
Date: Tue, 1 Sep 2009 09:59:47 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <4A9BC21C.9080606@simplistix.co.uk>
References: <1251333526.5297.52.camel@alisah>	<DB395FDF-0120-449C-AF6C-1DF742BE5038@canonical.com>	<4A9639BF.50902@simplistix.co.uk>
	<416D11D0-8C33-4F20-9BE6-65A4DDBF94C8@canonical.com>
	<4A9BC21C.9080606@simplistix.co.uk>
Message-ID: <B9F4715D-CDE1-4509-B1BE-ACB159080D03@canonical.com>


On Aug 31, 2009, at 8:29 AM, Chris Withers wrote:

> Gary Poster wrote:
>>> Indeed. Sounds great. However, what do you do if the system  
>>> installed libraries are the wrong very (eg: the buildout specifies  
>>> a particular version, and the one in site-packages isn't it)?
>> Using a whitelist in your .cfg,
>
> What does this mean/do/look like?

First, to repeat: Jim has not yet had a chance to review (and now he's  
waiting for me to do a merge with trunk, and I'm also using that to  
test the branch out on the upcoming Ubuntu release because I got a bug  
report), and this may change.  That said...

In the simplest case:

allowed-eggs-from-site-packages =

That means you don't allow any eggs from site packages.  So, this  
means that if one of your direct or indirect dependencies is docutils,  
and docutils is installed as an egg in your system, when the eggs for  
your buildout are assembled, the system egg will be ignored, and  
buildout will go on the hunt for one someplace else.  The typical  
result is that the egg that it finds will be earlier in the site path,  
so it has precedence in scripts and so on.

Meanwhile, dependencies that are not part of your dependencies (like,  
say, pyopenssl) are still available from your standard site-packages.

Alternatively, consider this.
allowed-eggs-from-site-packages =
     lxml

That is, you only allow the lxml egg from site packages.  All the rest  
will be ignored, as per the description above.

Here are the docs:

allowed-eggs-from-site-packages
     Sometimes you need or want to control what eggs from site- 
packages are
     used. The allowed-eggs-from-site-packages option allows you to  
specify a
     whitelist of project names that may be included from site- 
packages.  You
     can use globs to specify the value.  It defaults to a single  
value of '*',
     indicating that any package may come from site-packages.

     Here's a usage example::

         [buildout]
         ...

         allowed-eggs-from-site-packages =
             demo
             bigdemo
             zope.*

     This option interacts with the ``include-site-packages`` option  
in the
     following ways.

     If ``include-site-packages`` is true, then
     ``allowed-eggs-from-site-packages`` filters what eggs from site- 
packages
     may be chosen.  Therefore, if ``allowed-eggs-from-site-packages``  
is an
     empty list, then no eggs from site-packages are chosen, but site- 
packages
     will still be included at the end of path lists.

     If ``include-site-packages`` is false, the value of
     ``allowed-eggs-from-site-packages`` is irrelevant.

     The same pattern holds true for the ``include-site-packages-for- 
buildout``
     option, except only the bin/buildout script is affected by that
     interaction.


>
>> some or all of the eggs in site-packages are simply ignored when  
>> buildout assembles dependencies (even if they are or claim to be  
>> the right versions); and then the eggs that buildout chooses have  
>> precedence over site-packages (they come before site-packages in  
>> sys.path).
>
> Okay, but what if I don't know (or more accurately: don't want to  
> have to care ;-) ) what's in site-packages? What happens if there's  
> no whitelist and either buildout can't figure out what version of  
> the package is installed or it's the wrong version?

Simplest answer: if you are not using any new features, this usually  
fails, as before.  I'm loathe to significantly change the default  
behavior in 1.x release, and someone may be doing virtualenv/buildout  
dances that rely on the current behavior with site-packages.

The next simplest answer is to use the new "include-site-packages =  
false" option.  That's a tiny bit like using a virtualenv for your  
buildout, in that you are using the system executable but a clean site- 
packages.

The last answer is to leave "include-site-packages = true" (the  
default), and use the "allowed-eggs-from-site-packages" whitelist I  
describe above.  We currently use an empty whitelist, so we get bits  
like pyopenssl from the system, but buildout manages all of the  
application eggs.  It's a compromise that is working well for us so far.

Gary

From jim at zope.com  Tue Sep  1 16:21:23 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 1 Sep 2009 10:21:23 -0400
Subject: [Distutils] buildout's tests fail for me
In-Reply-To: <slrnh9q7qv.189j.reinout@isengrim.local>
References: <slrnh9pk34.2nla.reinout@isengrim.local>
	<1099b90b0909010326x42d21531r530bea8eb7d96419@mail.gmail.com>
	<slrnh9q7qv.189j.reinout@isengrim.local>
Message-ID: <1099b90b0909010721h45063d7av666e807a971db35e@mail.gmail.com>

On Tue, Sep 1, 2009 at 9:19 AM, Reinout van Rees<reinout at vanrees.org> wrote:
> On 2009-09-01, Jim Fulton <jim at zope.com> wrote:
>> On Tue, Sep 1, 2009 at 3:42 AM, Reinout van Rees<reinout at vanrees.org> wrote:
>>> - Is this something I really should fix in my own setup?
>>>
>>> - Is there a known fix that can be applied to the test setup?
>>
>> Yes. Use a clean Python built from source with nothing in site-packages.
>
> Ok, that helped partially. ?But then I got an error like:
>
> ?distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch:
> ?now "10.3" but "10.5" during configure

<shrug> Mac OS X weirdity.

> Waargh, that was in python2.4-checking code. ?So I tried running the buildout
> with python2.4 instead of the 2.5 I've been using: success.

I run the tests on Mac OS X with Python 2.4, 2.5 and 2.6.

> I don't know if the python24/python25 difference is known/intended, but in any
> case: I can run the tests now.
>
>> To build the buildout checkout, use dev.py, which is a special
>> bootstrap used when working on buildout itself.
>
> I haven't seen that dev.py documented. ?Would a "development instructions for
> buildout itself" be good to add to the documentation?

I wouldn't make it part of the standard documentation.  Perhaps a
DEVELOPER.txt in the root directory.

Jim

-- 
Jim Fulton

From ronaldoussoren at mac.com  Tue Sep  1 20:51:40 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 01 Sep 2009 20:51:40 +0200
Subject: [Distutils] buildout's tests fail for me
In-Reply-To: <1099b90b0909010721h45063d7av666e807a971db35e@mail.gmail.com>
References: <slrnh9pk34.2nla.reinout@isengrim.local>
	<1099b90b0909010326x42d21531r530bea8eb7d96419@mail.gmail.com>
	<slrnh9q7qv.189j.reinout@isengrim.local>
	<1099b90b0909010721h45063d7av666e807a971db35e@mail.gmail.com>
Message-ID: <026F681C-6BFA-48C5-87C8-0DBB1BA5B2D1@mac.com>


On 1 Sep, 2009, at 16:21, Jim Fulton wrote:

> On Tue, Sep 1, 2009 at 9:19 AM, Reinout van  
> Rees<reinout at vanrees.org> wrote:
>> On 2009-09-01, Jim Fulton <jim at zope.com> wrote:
>>> On Tue, Sep 1, 2009 at 3:42 AM, Reinout van  
>>> Rees<reinout at vanrees.org> wrote:
>>>> - Is this something I really should fix in my own setup?
>>>>
>>>> - Is there a known fix that can be applied to the test setup?
>>>
>>> Yes. Use a clean Python built from source with nothing in site- 
>>> packages.
>>
>> Ok, that helped partially.  But then I got an error like:
>>
>>  distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET  
>> mismatch:
>>  now "10.3" but "10.5" during configure
>
> <shrug> Mac OS X weirdity.

What kind of Python installation are you using? System python, binary  
installer from Python.org, ...
Which version of Python are you using?
Do you have MACOSX_DEPLOYMENT_TARGET set in your shell environment?

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090901/3dff3956/attachment-0001.bin>

From sdouche at gmail.com  Tue Sep  1 23:39:38 2009
From: sdouche at gmail.com (Sebastien Douche)
Date: Tue, 1 Sep 2009 23:39:38 +0200
Subject: [Distutils] buildout's tests fail for me
In-Reply-To: <slrnh9pk34.2nla.reinout@isengrim.local>
References: <slrnh9pk34.2nla.reinout@isengrim.local>
Message-ID: <5e1183fa0909011439u6f95afet32a0d81cfcb64f66@mail.gmail.com>

On Tue, Sep 1, 2009 at 09:42, Reinout van Rees<reinout at vanrees.org> wrote:
> He was on linux, I'm on osx. ?So it is not specifically os-dependent.

No problem here:
http://misc.buildbot.securactive.org/waterfall


-- 
Sebastien Douche <sdouche at gmail.com>
Twitter: http://bit.ly/afkrK (agile, python, open source)

From reinout at vanrees.org  Wed Sep  2 09:44:32 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 2 Sep 2009 07:44:32 +0000 (UTC)
Subject: [Distutils] buildout's tests fail for me
References: <slrnh9pk34.2nla.reinout@isengrim.local>
	<1099b90b0909010326x42d21531r530bea8eb7d96419@mail.gmail.com>
	<slrnh9q7qv.189j.reinout@isengrim.local>
	<1099b90b0909010721h45063d7av666e807a971db35e@mail.gmail.com>
	<026F681C-6BFA-48C5-87C8-0DBB1BA5B2D1@mac.com>
Message-ID: <h7l7p0$mte$1@ger.gmane.org>

On 2009-09-01, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 1 Sep, 2009, at 16:21, Jim Fulton wrote:
>
>> On Tue, Sep 1, 2009 at 9:19 AM, Reinout van  
>> Rees<reinout at vanrees.org> wrote:
>>>
>>>  distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET  
>>> mismatch:
>>>  now "10.3" but "10.5" during configure
>>
>> <shrug> Mac OS X weirdity.
>
> What kind of Python installation are you using? System python, binary  
> installer from Python.org, ...
> Which version of Python are you using?
> Do you have MACOSX_DEPLOYMENT_TARGET set in your shell environment?

Set in my shell? No.

And this last attempt where I got the 10.3 != 10.5 error was with a freshly
compiled 2.5.4 source release from python.org.  Plain configure/make/make
install (with a --prefix= option).  Plain as plain can be.

If you google it, there are quite a lot of reports on this.

Well, I've got the tests running with python2.4 at least.  Hm. I *could* do
another build WITH such an environment variable set...

Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From reinout at vanrees.org  Wed Sep  2 09:54:03 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 2 Sep 2009 07:54:03 +0000 (UTC)
Subject: [Distutils] buildout's tests fail for me
References: <slrnh9pk34.2nla.reinout@isengrim.local>
	<5e1183fa0909011439u6f95afet32a0d81cfcb64f66@mail.gmail.com>
Message-ID: <h7l8ar$mte$2@ger.gmane.org>

On 2009-09-01, Sebastien Douche <sdouche at gmail.com> wrote:
> On Tue, Sep 1, 2009 at 09:42, Reinout van Rees<reinout at vanrees.org> wrote:
>> He was on linux, I'm on osx. ?So it is not specifically os-dependent.
>
> No problem here:
> http://misc.buildbot.securactive.org/waterfall

That's exactly the problem: most people don't have a problem.  So it took me
quite some time to be actually able to work on buildbot itself as all I heard
was "the tests run for me".

I've added two of the most helpful hints to a new DEVERLOPERS.txt to make sure
they're documented now.


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From barthelemy at crans.org  Wed Sep  2 12:13:09 2009
From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=)
Date: Wed, 2 Sep 2009 12:13:09 +0200
Subject: [Distutils] passing options to Command from setup.py
Message-ID: <78f7ab620909020313h3dad3588k431dc890ee02ed99@mail.gmail.com>

Hello,

is there a way to pass options to a custom distutils.core.Command from
setup.py instead of setup.cfg ? I could not find any doc about that.

Thanks !

From ziade.tarek at gmail.com  Wed Sep  2 12:32:52 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 2 Sep 2009 12:32:52 +0200
Subject: [Distutils] passing options to Command from setup.py
In-Reply-To: <78f7ab620909020313h3dad3588k431dc890ee02ed99@mail.gmail.com>
References: <78f7ab620909020313h3dad3588k431dc890ee02ed99@mail.gmail.com>
Message-ID: <94bdd2610909020332h4c6c1d65yf2bad83b22173010@mail.gmail.com>

2009/9/2 S?bastien Barth?lemy <barthelemy at crans.org>:
> Hello,
>
> is there a way to pass options to a custom distutils.core.Command from
> setup.py instead of setup.cfg ? I could not find any doc about that.
>
> Thanks !

Hello

when you create a command, you can define options (look at any command
in dstutils/command)
then you can pass these options either in the command line (1), either
in the setup() arguments (2)
either in a cfg file.

1) command line:

$ python setup.py my_command --my-option=foo

2) in setup.py:

setup(command_options={'my_command': {'my_option': ('setup.py', 'foo') } })

(the "setup.py" value is just a source value that is not actually used
here. it's used
when command_options is built from .cfg files)

3) in a cfg file

[my_command]
my_option = foo

Cheers
Tarek


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

From barthelemy at crans.org  Wed Sep  2 13:12:25 2009
From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=)
Date: Wed, 2 Sep 2009 13:12:25 +0200
Subject: [Distutils] passing options to Command from setup.py
In-Reply-To: <94bdd2610909020332h4c6c1d65yf2bad83b22173010@mail.gmail.com>
References: <78f7ab620909020313h3dad3588k431dc890ee02ed99@mail.gmail.com>
	<94bdd2610909020332h4c6c1d65yf2bad83b22173010@mail.gmail.com>
Message-ID: <78f7ab620909020412r57c7b0bbuc4fafcd96989b7ac@mail.gmail.com>

> 2) in setup.py:
>
> setup(command_options={'my_command': {'my_option': ('setup.py', 'foo') } })

Great, thanks! Is this documented in some place I overlooked?

From tl at gocept.com  Wed Sep  2 07:22:03 2009
From: tl at gocept.com (Thomas Lotze)
Date: Wed, 2 Sep 2009 07:22:03 +0200
Subject: [Distutils] [buildout] zc.recipe.cmmi and Windows
Message-ID: <20090902072203.1cd7f942@krusty.ws.whq.gocept.com>

I wonder whether zc.recipe.cmmi is meant to be usable and testable in a
Windows environment. While the changelog says a Windows-related bug was
fixed last year, the tests don't succeed on the Windows box I tried today
due to file-system path handling which is being done in a non-portable and
Unix-specific way both in code and tests, and has been for a long time.
Can someone enlighten me as to what it is that I seem to have missed?
Thank you.

Viele Gr??e,
Thomas

-- 
Thomas Lotze ? tl at gocept.com
gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany
http://gocept.com ? tel +49 345 1229889 0 ? fax +49 345 1229889 1
Zope and Plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090902/093d2d2d/attachment.pgp>

From reinout at vanrees.org  Wed Sep  2 15:07:43 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 2 Sep 2009 13:07:43 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
Message-ID: <h7lqmu$k13$1@ger.gmane.org>

First things first: what I want to accomplish is to install pyflakes and
docutils in a buildout.  That is, I want to have a bin/pyflakes and bin/rst2*
scripts.

- Buildout listens to the console_scripts entry point.

- pyflakes and docutils use the (apparently old) scripts=['scripts/pyflakes']
  option instead of a console_scripts entry point.


So I have three choices:

- Ask pyflakes and docutils to use the console_scripts entry point.  Is there
  a reason not to use console_scripts?  The "scripts=[]" comes from plain
  distutils which is in the official python distribution and setuptools is
  an add-on.  Can this be a cause?

- Fix up buildout to also support scripts=[].  (I'm trying that one right
  now).

- Write a wrapper library that depends on pyflakes/docutils and provides
  proper entry points.  Feels a bit dirty.


I have two questions:

- Has the console_scripts entry point superseded scripts=[]?  Should it be
  considered a bug in pyflakes?  Or is it OK to still use it?

- How do I access that 'scripts=[....]' which is sitting right there in my
  setup() call?  From buildout?  Buildout does something like:

       req = pkg_resources.Requirement.parse('my.package')
       dist = working_set.find('my.package')
  
  dist ends up as a pkg_resources.Distribution class, which doesn't seem to
  have anything with which to do "dist.scripts" or so.  Anyone know the magic
  call?  In easy_install there's a "self.distribution.scripts", but after 4
  levels of inheritance and a monkey patch I lost track where
  self.distribution comes from...


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ziade.tarek at gmail.com  Wed Sep  2 15:13:52 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 2 Sep 2009 15:13:52 +0200
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7lqmu$k13$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
Message-ID: <94bdd2610909020613k2d66e659iee8c2306e7662f9@mail.gmail.com>

On Wed, Sep 2, 2009 at 3:07 PM, Reinout van Rees<reinout at vanrees.org> wrote:
> First things first: what I want to accomplish is to install pyflakes and
> docutils in a buildout. ?That is, I want to have a bin/pyflakes and bin/rst2*
> scripts.
>
> - Buildout listens to the console_scripts entry point.
>
> - pyflakes and docutils use the (apparently old) scripts=['scripts/pyflakes']
> ?option instead of a console_scripts entry point.
>
>
> So I have three choices:
>
> - Ask pyflakes and docutils to use the console_scripts entry point. ?Is there
> ?a reason not to use console_scripts? ?The "scripts=[]" comes from plain
> ?distutils which is in the official python distribution and setuptools is
> ?an add-on. ?Can this be a cause?
>
> - Fix up buildout to also support scripts=[]. ?(I'm trying that one right
> ?now).
>
> - Write a wrapper library that depends on pyflakes/docutils and provides
> ?proper entry points. ?Feels a bit dirty.
>

if the code called in scripts/pyflakes is using a function from the
pyflakes package,
you could also add in a zc.recipe.eggs section in your buildout an
explicit entry_point like this:

[scripts]
recipe= zc.recipe.eggs
eggs =
    pyflakes

entry-points =
    pyflakes=pyflakes.somemodule:main

where main is the function to launch is the somemodule module in pyflakes for
instance

Cheers
Tarek

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

From reinout at vanrees.org  Wed Sep  2 15:14:07 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 2 Sep 2009 13:14:07 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
Message-ID: <h7lr2v$kva$1@ger.gmane.org>

On 2009-09-02, Reinout van Rees <reinout at vanrees.org> wrote:

> - pyflakes and docutils use the (apparently old) scripts=['scripts/pyflakes']
>   option instead of a console_scripts entry point.

Just for easy reference: here's the setup.py of pyflakes:


#!/usr/bin/python
# (c) 2005-2009 Divmod, Inc.  See LICENSE file for details

from distutils.core import setup

setup(
    name="pyflakes",
    license="MIT",
    version="0.3.0",
    description="passive checker of Python programs",
    author="Phil Frost",
    maintainer="Moe Aboulkheir",
    maintainer_email="moe at divmod.com",
    url="http://www.divmod.org/trac/wiki/DivmodPyflakes",
    packages=["pyflakes", "pyflakes.scripts", "pyflakes.test"],
    scripts=["bin/pyflakes"],
    long_description="""Pyflakes is program to analyze Python programs and detect various errors. It
works by parsing the source file, not importing it, so it is safe to use on
modules with side effects. It's also much faster.""")


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From jim at zope.com  Wed Sep  2 19:36:28 2009
From: jim at zope.com (Jim Fulton)
Date: Wed, 2 Sep 2009 13:36:28 -0400
Subject: [Distutils] [buildout] zc.recipe.cmmi and Windows
In-Reply-To: <20090902072203.1cd7f942@krusty.ws.whq.gocept.com>
References: <20090902072203.1cd7f942@krusty.ws.whq.gocept.com>
Message-ID: <1099b90b0909021036s2ccdd930j73821dd998c1188c@mail.gmail.com>

On Wed, Sep 2, 2009 at 1:22 AM, Thomas Lotze<tl at gocept.com> wrote:
> I wonder whether zc.recipe.cmmi is meant to be usable and testable in a
> Windows environment. While the changelog says a Windows-related bug was
> fixed last year, the tests don't succeed on the Windows box I tried today
> due to file-system path handling which is being done in a non-portable and
> Unix-specific way both in code and tests, and has been for a long time.
> Can someone enlighten me as to what it is that I seem to have missed?
> Thank you.

I don't expect it to work on windows. It wasn't designed with windows
in mind at all.

I can imagine some  hardy soul trying to make it work on windows,
possibly untested.  Somebody made zdaemon work on windows, I think. :)

Jim

-- 
Jim Fulton

From jim at zope.com  Wed Sep  2 19:50:23 2009
From: jim at zope.com (Jim Fulton)
Date: Wed, 2 Sep 2009 13:50:23 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7lqmu$k13$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
Message-ID: <1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>

On Wed, Sep 2, 2009 at 9:07 AM, Reinout van Rees<reinout at vanrees.org> wrote:
> First things first: what I want to accomplish is to install pyflakes and
> docutils in a buildout. ?That is, I want to have a bin/pyflakes and bin/rst2*
> scripts.
>
> - Buildout listens to the console_scripts entry point.
>
> - pyflakes and docutils use the (apparently old) scripts=['scripts/pyflakes']
> ?option instead of a console_scripts entry point.
>
>
> So I have three choices:
>
> - Ask pyflakes and docutils to use the console_scripts entry point. ?Is there
> ?a reason not to use console_scripts? ?The "scripts=[]" comes from plain
> ?distutils which is in the official python distribution and setuptools is
> ?an add-on. ?Can this be a cause?

Perhaps.

Note that, as Tarek reminded us, buildout lets you define entry points
yourself. In fact, I happen to have done this for pyflakes myself a
couple of weeks ago:

  [pyflakes]
  recipe = zc.recipe.egg
  eggs = pyflakes
  entry-points = pyflakes=pyflakes.scripts.pyflakes:main

> - Fix up buildout to also support scripts=[]. ?(I'm trying that one right
> ?now).

For a long time, I maintained that this wasn't practical. I do think
90% (maybe a 100%) solution of possible.  It will require generating
scripts that set up the path and then include the source of the
original scripts.  This is rather ugly but probably doable.  Of
course, there's also the pain that the script meta data isn't
available cleanly, as you point out below.

>
> - Write a wrapper library that depends on pyflakes/docutils and provides
> ?proper entry points. ?Feels a bit dirty.
>
>
> I have two questions:
>
> - Has the console_scripts entry point superseded scripts=[]? ?Should it be
> ?considered a bug in pyflakes? ?Or is it OK to still use it?

I personally think entry points are cleaner, but I think it would be
rather bold to call use of scripts a bug. :)


> - How do I access that 'scripts=[....]' which is sitting right there in my
> ?setup() call? ?From buildout? ?Buildout does something like:
>
> ? ? ? req = pkg_resources.Requirement.parse('my.package')
> ? ? ? dist = working_set.find('my.package')
>
> ?dist ends up as a pkg_resources.Distribution class, which doesn't seem to
> ?have anything with which to do "dist.scripts" or so. ?Anyone know the magic
> ?call? ?In easy_install there's a "self.distribution.scripts", but after 4
> ?levels of inheritance and a monkey patch I lost track where
> ?self.distribution comes from...

Yeah, it's too bad that the meta data is lost.  It amazes me how
willing distutils and setuptools are to toss meta data passed to
setup.

You could probably invoke the install command telling it to install
the scripts in some place and then grab them, but that sounds nasty
too.

Jim

-- 
Jim Fulton

From hanno at hannosch.eu  Wed Sep  2 19:53:41 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Wed, 2 Sep 2009 19:53:41 +0200
Subject: [Distutils] [buildout] zc.recipe.cmmi and Windows
In-Reply-To: <1099b90b0909021036s2ccdd930j73821dd998c1188c@mail.gmail.com>
References: <20090902072203.1cd7f942@krusty.ws.whq.gocept.com>
	<1099b90b0909021036s2ccdd930j73821dd998c1188c@mail.gmail.com>
Message-ID: <5cae42b20909021053i4c6b03f3n747375afa20cd32c@mail.gmail.com>

On Wed, Sep 2, 2009 at 7:36 PM, Jim Fulton<jim at zope.com> wrote:
> I can imagine some ?hardy soul trying to make it work on windows,
> possibly untested. ?Somebody made zdaemon work on windows, I think. :)

I doubt zdaemon works on Windows. I once made all the Zope2 zopectl
scripts work on Windows. But that was by avoiding zdaemon and
transparently using actual Windows services for start/stop/restart
commands instead.

On the matter of cmmi, I think with enough tools of the MingW project
installed you could make things work. But I wouldn't particularly
trust the stability of things compiled this way. At least not from my
past sysadmin perspective on long term maintenance ;)

Hanno

From chris at simplistix.co.uk  Thu Sep  3 01:45:10 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 03 Sep 2009 00:45:10 +0100
Subject: [Distutils] [buildout] zc.recipe.egg
 interpretters	don't	support -m
In-Reply-To: <5D4EBCDA-2AB4-4BD1-B2D9-B6F859036D5E@canonical.com>
References: <4A86958A.4040507@simplistix.co.uk>	<E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>	<4A86A195.9090805@simplistix.co.uk>	<1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>	<4A939FF8.1050907@simplistix.co.uk>	<1099b90b0908250300s70876458yc49e234fd4905784@mail.gmail.com>	<4A957AFB.6000801@simplistix.co.uk>	<1099b90b0908281559o79a60910hf7aa1cb53428d226@mail.gmail.com>	<4A9BB984.6020405@simplistix.co.uk>
	<5D4EBCDA-2AB4-4BD1-B2D9-B6F859036D5E@canonical.com>
Message-ID: <4A9F0386.7080008@simplistix.co.uk>

Gary Poster wrote:
> 
> The same is true for -c, which we've had for awhile and has the same 
> rough edge.  (I changed that in a hacky way for my branch for -c, and 
> now for -m.  I'll be trying to change that to use optparse very soon, 
> though someone may beat me to it.)

Do you have your patches for this to hand?

I want to profile some stuff but I hit the above problem with, for example:

bin/py -m cProfile -o test.profile bin/test

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

From chris at simplistix.co.uk  Thu Sep  3 01:49:54 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 03 Sep 2009 00:49:54 +0100
Subject: [Distutils] [buildout] profiling stuff with cProfile
In-Reply-To: <4A9F0386.7080008@simplistix.co.uk>
References: <4A86958A.4040507@simplistix.co.uk>	<E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>	<4A86A195.9090805@simplistix.co.uk>	<1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>	<4A939FF8.1050907@simplistix.co.uk>	<1099b90b0908250300s70876458yc49e234fd4905784@mail.gmail.com>	<4A957AFB.6000801@simplistix.co.uk>	<1099b90b0908281559o79a60910hf7aa1cb53428d226@mail.gmail.com>	<4A9BB984.6020405@simplistix.co.uk>	<5D4EBCDA-2AB4-4BD1-B2D9-B6F859036D5E@canonical.com>
	<4A9F0386.7080008@simplistix.co.uk>
Message-ID: <4A9F04A2.2090007@simplistix.co.uk>

Chris Withers wrote:
> Gary Poster wrote:
>>
>> The same is true for -c, which we've had for awhile and has the same 
>> rough edge.  (I changed that in a hacky way for my branch for -c, and 
>> now for -m.  I'll be trying to change that to use optparse very soon, 
>> though someone may beat me to it.)
> 
> Do you have your patches for this to hand?
> 
> I want to profile some stuff but I hit the above problem with, for example:
> 
> bin/py -m cProfile -o test.profile bin/test

Okay, well, with the following entrypoint:

setup(
...
     entry_points = {
         'console_scripts': [
             'profile = cProfile:main',
         ],
         },
     )

You can now do:

bin/profile -o tests.profile bin/test

Hope this helps!

Chris

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

From thomas at thomas-lotze.de  Thu Sep  3 09:08:56 2009
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Thu, 03 Sep 2009 09:08:56 +0200
Subject: [Distutils] [buildout] zc.recipe.cmmi and Windows
References: <20090902072203.1cd7f942@krusty.ws.whq.gocept.com>	<1099b90b0909021036s2ccdd930j73821dd998c1188c@mail.gmail.com>
Message-ID: <pan.2009.09.03.05.16.58.982887@ID-174572.user.uni-berlin.de>

Jim Fulton wrote:

> I don't expect it to work on windows. It wasn't designed with windows in
> mind at all.

Fine with me. I'll add a note in an appropriate place to make this clear
to other developers who might wonder the same thing.

> I can imagine some  hardy soul trying to make it work on windows, possibly
> untested.  Somebody made zdaemon work on windows, I think. :)

Certainly not me :o)

-- 
Thomas




From reinout at vanrees.org  Thu Sep  3 17:46:57 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 3 Sep 2009 15:46:57 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
Message-ID: <h7oodh$c3f$1@ger.gmane.org>

On 2009-09-02, Jim Fulton <jim at zope.com> wrote:
>
> Note that, as Tarek reminded us, buildout lets you define entry points
> yourself. In fact, I happen to have done this for pyflakes myself a
> couple of weeks ago:
>
>   [pyflakes]
>   recipe = zc.recipe.egg
>   eggs = pyflakes
>   entry-points = pyflakes=pyflakes.scripts.pyflakes:main

That's much shorter than the one I've been using, which makes it seem less
painful.  Due to the way the docutils scripts are set up (without a clear
'main()' method), this is much more painful.

>> - Fix up buildout to also support scripts=[]. ?(I'm trying that one right
>> ?now).
>
> For a long time, I maintained that this wasn't practical. I do think
> 90% (maybe a 100%) solution of possible.  It will require generating
> scripts that set up the path and then include the source of the
> original scripts.  This is rather ugly but probably doable.  Of
> course, there's also the pain that the script meta data isn't
> available cleanly, as you point out below.

I went from "probably an easy fix" to "ouch, distutils/setuptools makes this
impossible without resorting to ugly hacks" within one day...

>> - How do I access that 'scripts=[....]' which is sitting right there in my
>> ?setup() call? ?From buildout? ?Buildout does something like:
>>
>> ? ? ? req = pkg_resources.Requirement.parse('my.package')
>> ? ? ? dist = working_set.find('my.package')
>>
>> ?dist ends up as a pkg_resources.Distribution class, which doesn't seem to
>> ?have anything with which to do "dist.scripts" or so. ?Anyone know the magic
>> ?call? ?In easy_install there's a "self.distribution.scripts", but after 4
>> ?levels of inheritance and a monkey patch I lost track where
>> ?self.distribution comes from...
>
> Yeah, it's too bad that the meta data is lost.  It amazes me how
> willing distutils and setuptools are to toss meta data passed to
> setup.
>
> You could probably invoke the install command telling it to install
> the scripts in some place and then grab them, but that sounds nasty
> too.

And it is especially nasty as you'd have to do it for every egg in order to
discover whether they *have* a 'scripts=[...]'.  Unless you'd specify it.

What about making the problem explicit and doing something like:

[distutilscripts]
recipe = zc.recipe.egg:distutils
eggs =
    pyflakes
    docutils
scripts =
    scripts/pyflakes
    tools/rst2html
    tools/rst2s5


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From jim at zope.com  Thu Sep  3 18:15:40 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 3 Sep 2009 12:15:40 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7oodh$c3f$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<h7oodh$c3f$1@ger.gmane.org>
Message-ID: <1099b90b0909030915j3fb99e88p2301186c48ec43b8@mail.gmail.com>

On Thu, Sep 3, 2009 at 11:46 AM, Reinout van Rees<reinout at vanrees.org> wrote:
> On 2009-09-02, Jim Fulton <jim at zope.com> wrote:
>>
>> Note that, as Tarek reminded us, buildout lets you define entry points
>> yourself. In fact, I happen to have done this for pyflakes myself a
>> couple of weeks ago:
>>
>> ? [pyflakes]
>> ? recipe = zc.recipe.egg
>> ? eggs = pyflakes
>> ? entry-points = pyflakes=pyflakes.scripts.pyflakes:main
>
> That's much shorter than the one I've been using, which makes it seem less
> painful. ?Due to the way the docutils scripts are set up (without a clear
> 'main()' method), this is much more painful.

Yeah, I ended up creating a wrapper package for docutuls.  In fact, I
should have mentioned it sooner:

  http://pypi.python.org/pypi/zc.rst2

You might find it useful. :)

...

> What about making the problem explicit and doing something like:
>
> [distutilscripts]
> recipe = zc.recipe.egg:distutils
> eggs =
> ? ?pyflakes
> ? ?docutils
> scripts =
> ? ?scripts/pyflakes
> ? ?tools/rst2html
> ? ?tools/rst2s5

Something like that might work. Note that there is already a scripts
option.  Maybe:

distutils-scripts = x y=z

Jim

-- 
Jim Fulton

From ziade.tarek at gmail.com  Thu Sep  3 18:34:31 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 3 Sep 2009 18:34:31 +0200
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
Message-ID: <94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>

On Wed, Sep 2, 2009 at 7:50 PM, Jim Fulton<jim at zope.com> wrote:
>
> Yeah, it's too bad that the meta data is lost. ?It amazes me how
> willing distutils and setuptools are to toss meta data passed to
> setup.

Are your referring to the Package Metadata ? (eg the PEP 314 that
lands in the PKG-INFO)

'scripts' is just an argument that is used by the commands to generate
the scripts,

I don't think they should land in the Package Metadata, but I think we should
have an API for any installed distribution to list them.

Right now PEP 376 proposes a RECORD file that lists all files
installed for a distribution,
but maybe we could have a flag that indicates that a file is an
executable script

How does that sounds ?


Tarek

From jim at zope.com  Thu Sep  3 19:58:21 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 3 Sep 2009 13:58:21 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
Message-ID: <1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>

On Thu, Sep 3, 2009 at 12:34 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Wed, Sep 2, 2009 at 7:50 PM, Jim Fulton<jim at zope.com> wrote:
>>
>> Yeah, it's too bad that the meta data is lost. ?It amazes me how
>> willing distutils and setuptools are to toss meta data passed to
>> setup.
>
> Are your referring to the Package Metadata ? (eg the PEP 314 that
> lands in the PKG-INFO)

Not necessarily.  I mainly want it to land somewhere in the egg info.

>
> 'scripts' is just an argument that is used by the commands to generate
> the scripts,
>
> I don't think they should land in the Package Metadata, but I think we should
> have an API for any installed distribution to list them.

I consider everything that ends up in egg info directories to be
package meta data.  The information needs to be saved somewhere for an
API to dig it out of an egg.


>
> Right now PEP 376 proposes a RECORD file that lists all files
> installed for a distribution,
> but maybe we could have a flag that indicates that a file is an
> executable script
>
> How does that sounds ?

I think the script information should be included somehow so that it
can be gotten from eggs.

Jim

-- 
Jim Fulton

From pje at telecommunity.com  Fri Sep  4 02:04:15 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 03 Sep 2009 20:04:15 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.co
 m>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
Message-ID: <20090904000502.D35203A409E@sparrow.telecommunity.com>

At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
>I think the script information should be included somehow so that it
>can be gotten from eggs.

The original script files get stored in the "EGG-INFO/scripts" directory.


From reinout at vanrees.org  Fri Sep  4 14:05:40 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 4 Sep 2009 12:05:40 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.co m>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
Message-ID: <h7qvqk$heq$1@ger.gmane.org>

On 2009-09-04, P.J. Eby <pje at telecommunity.com> wrote:
> At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
>>I think the script information should be included somehow so that it
>>can be gotten from eggs.
>
> The original script files get stored in the "EGG-INFO/scripts" directory.

Ok, I got something working based on that info. Thanks! It is in the
zc.buildout/branches/reinout-scripts branch.  Just run bin/buildout and the
presence of bin/pyflakes, bin/rst2s5.py and friends demonstrates that it
works.


I'm not sure how robust it is, though.  My main worry is that it probably only
works OK with unzipped eggs.  "dist.location" is the egg's location:

    scripts_dir = os.path.join(dist.location, 'EGG-INFO', 'scripts')
    if os.path.exists(scripts_dir):
        for name in os.listdir(scripts_dir):
            distutils_scripts.append(
                (name, os.path.join(scripts_dir, name)))

So this does a basic os.path.join()... I tried pkg_resources'
resource_filename() call, but that doesn't work because the egg isn't
installed yet.  But I might be overlooking something here!  An alternative
would be to unzip an egg ourselves.


There are enough "if" statements to make it safe, I guess.  It will have to be
tested on windows, for sure (which I cannot).  And: it *does* solve the 90%
usecase of just installing pyflakes and docutils' scripts!


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From reinout at vanrees.org  Fri Sep  4 17:35:31 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 4 Sep 2009 15:35:31 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.co m>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org>
Message-ID: <h7rc43$sk5$1@ger.gmane.org>

On 2009-09-04, Reinout van Rees <reinout at vanrees.org> wrote:
> On 2009-09-04, P.J. Eby <pje at telecommunity.com> wrote:
>> At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
>>>I think the script information should be included somehow so that it
>>>can be gotten from eggs.
>>
>> The original script files get stored in the "EGG-INFO/scripts" directory.
>
> Ok, I got something working based on that info. Thanks! It is in the
> zc.buildout/branches/reinout-scripts branch.  Just run bin/buildout and the
> presence of bin/pyflakes, bin/rst2s5.py and friends demonstrates that it
> works.
>
>
> I'm not sure how robust it is, though.  My main worry is that it probably only
> works OK with unzipped eggs.  "dist.location" is the egg's location:
>
>     scripts_dir = os.path.join(dist.location, 'EGG-INFO', 'scripts')
>     if os.path.exists(scripts_dir):
>         for name in os.listdir(scripts_dir):
>             distutils_scripts.append(
>                 (name, os.path.join(scripts_dir, name)))
>
> So this does a basic os.path.join()... I tried pkg_resources'
> resource_filename() call, but that doesn't work because the egg isn't
> installed yet.  But I might be overlooking something here!  An alternative
> would be to unzip an egg ourselves.

I verified that it doesn't work with zipped eggs.  Are there alternatives for
getting my hand on that listdir of EGG-INFO/scripts/* without unzipping the
egg?  Otherwise I'm in favour of just leaving zipped eggs be.

Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ziade.tarek at gmail.com  Fri Sep  4 17:56:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 4 Sep 2009 17:56:25 +0200
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7rc43$sk5$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org> <h7rc43$sk5$1@ger.gmane.org>
Message-ID: <94bdd2610909040856w7d9c50cak8700ca2d83121114@mail.gmail.com>

On Fri, Sep 4, 2009 at 5:35 PM, Reinout van Rees<reinout at vanrees.org> wrote:
> On 2009-09-04, Reinout van Rees <reinout at vanrees.org> wrote:
>> On 2009-09-04, P.J. Eby <pje at telecommunity.com> wrote:
>>> At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
>>>>I think the script information should be included somehow so that it
>>>>can be gotten from eggs.
>>>
>>> The original script files get stored in the "EGG-INFO/scripts" directory.
>>
>> Ok, I got something working based on that info. Thanks! It is in the
>> zc.buildout/branches/reinout-scripts branch. ?Just run bin/buildout and the
>> presence of bin/pyflakes, bin/rst2s5.py and friends demonstrates that it
>> works.
>>
>>
>> I'm not sure how robust it is, though. ?My main worry is that it probably only
>> works OK with unzipped eggs. ?"dist.location" is the egg's location:
>>
>> ? ? scripts_dir = os.path.join(dist.location, 'EGG-INFO', 'scripts')
>> ? ? if os.path.exists(scripts_dir):
>> ? ? ? ? for name in os.listdir(scripts_dir):
>> ? ? ? ? ? ? distutils_scripts.append(
>> ? ? ? ? ? ? ? ? (name, os.path.join(scripts_dir, name)))
>>
>> So this does a basic os.path.join()... I tried pkg_resources'
>> resource_filename() call, but that doesn't work because the egg isn't
>> installed yet. ?But I might be overlooking something here! ?An alternative
>> would be to unzip an egg ourselves.
>
> I verified that it doesn't work with zipped eggs. ?Are there alternatives for
> getting my hand on that listdir of EGG-INFO/scripts/* without unzipping the
> egg? ?Otherwise I'm in favour of just leaving zipped eggs be.

You can browse an egg using zipimport.zimporter or try to use the
"driver" in pkg_resources
or, look at our PEP 376 prototype http://bitbucket.org/tarek/pep376.

Although, dropping zipped eggs support is a good option too imho ;)

Cheers
Tarek

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

From jim at zope.com  Fri Sep  4 18:55:32 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 4 Sep 2009 12:55:32 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7rc43$sk5$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org> <h7rc43$sk5$1@ger.gmane.org>
Message-ID: <1099b90b0909040955m1d4a94e9l3e49b8aaf5ecc6eb@mail.gmail.com>

On Fri, Sep 4, 2009 at 11:35 AM, Reinout van Rees<reinout at vanrees.org> wrote:
> On 2009-09-04, Reinout van Rees <reinout at vanrees.org> wrote:
>> On 2009-09-04, P.J. Eby <pje at telecommunity.com> wrote:
>>> At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
>>>>I think the script information should be included somehow so that it
>>>>can be gotten from eggs.
>>>
>>> The original script files get stored in the "EGG-INFO/scripts" directory.
>>
>> Ok, I got something working based on that info. Thanks! It is in the
>> zc.buildout/branches/reinout-scripts branch. ?Just run bin/buildout and the
>> presence of bin/pyflakes, bin/rst2s5.py and friends demonstrates that it
>> works.
>>
>>
>> I'm not sure how robust it is, though. ?My main worry is that it probably only
>> works OK with unzipped eggs. ?"dist.location" is the egg's location:
>>
>> ? ? scripts_dir = os.path.join(dist.location, 'EGG-INFO', 'scripts')
>> ? ? if os.path.exists(scripts_dir):
>> ? ? ? ? for name in os.listdir(scripts_dir):
>> ? ? ? ? ? ? distutils_scripts.append(
>> ? ? ? ? ? ? ? ? (name, os.path.join(scripts_dir, name)))
>>
>> So this does a basic os.path.join()... I tried pkg_resources'
>> resource_filename() call, but that doesn't work because the egg isn't
>> installed yet. ?But I might be overlooking something here! ?An alternative
>> would be to unzip an egg ourselves.
>
> I verified that it doesn't work with zipped eggs. ?Are there alternatives for
> getting my hand on that listdir of EGG-INFO/scripts/* without unzipping the
> egg? ?Otherwise I'm in favour of just leaving zipped eggs be.

Sure, use the zipfile module.

Jim

-- 
Jim Fulton

From reinout at vanrees.org  Fri Sep  4 23:30:37 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 4 Sep 2009 21:30:37 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org> <h7rc43$sk5$1@ger.gmane.org>
	<1099b90b0909040955m1d4a94e9l3e49b8aaf5ecc6eb@mail.gmail.com>
Message-ID: <h7s0tt$vir$1@ger.gmane.org>

On 2009-09-04, Jim Fulton <jim at zope.com> wrote:

>> I verified that it doesn't work with zipped eggs. ?Are there alternatives for
>> getting my hand on that listdir of EGG-INFO/scripts/* without unzipping the
>> egg? ?Otherwise I'm in favour of just leaving zipped eggs be.
>
> Sure, use the zipfile module.

Hm. I tried it and it was remarkably painless to just get a list of the zipped
egg's contents.  So I got it working with zipped eggs, too :-)

There's one thing I couldn't find out: does the zipfile module report
filenames as slashes or does it use the OS's preference?  /me has no windows
around to test it on.  So there might be an OS inconsistency there.  Running
the tests on windows will uncover that, of course.


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From pje at telecommunity.com  Fri Sep  4 23:59:43 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 04 Sep 2009 17:59:43 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7qvqk$heq$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.co m>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org>
Message-ID: <20090904215946.B43503A4093@sparrow.telecommunity.com>

At 12:05 PM 9/4/2009 +0000, Reinout van Rees wrote:
>On 2009-09-04, P.J. Eby <pje at telecommunity.com> wrote:
> > At 01:58 PM 9/3/2009 -0400, Jim Fulton wrote:
> >>I think the script information should be included somehow so that it
> >>can be gotten from eggs.
> >
> > The original script files get stored in the "EGG-INFO/scripts" directory.
>
>Ok, I got something working based on that info. Thanks! It is in the
>zc.buildout/branches/reinout-scripts branch.  Just run bin/buildout and the
>presence of bin/pyflakes, bin/rst2s5.py and friends demonstrates that it
>works.
>
>
>I'm not sure how robust it is, though.  My main worry is that it probably only
>works OK with unzipped eggs.  "dist.location" is the egg's location:
>
>     scripts_dir = os.path.join(dist.location, 'EGG-INFO', 'scripts')
>     if os.path.exists(scripts_dir):
>         for name in os.listdir(scripts_dir):
>             distutils_scripts.append(
>                 (name, os.path.join(scripts_dir, name)))

Ugh.  Seriously not kosher.  Use this instead:

     if dist.metadata_isdir('scripts'):
         for name in dist.metadata_listdir('scripts'):
             script_text = dist.get_metadata('scripts/'+name)
             # write the text to a file and do whatever else you want


From pje at telecommunity.com  Sat Sep  5 00:00:28 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 04 Sep 2009 18:00:28 -0400
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7s0tt$vir$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org> <h7rc43$sk5$1@ger.gmane.org>
	<1099b90b0909040955m1d4a94e9l3e49b8aaf5ecc6eb@mail.gmail.com>
	<h7s0tt$vir$1@ger.gmane.org>
Message-ID: <20090904220030.6568C3A4093@sparrow.telecommunity.com>

At 09:30 PM 9/4/2009 +0000, Reinout van Rees wrote:
>There's one thing I couldn't find out: does the zipfile module report
>filenames as slashes or does it use the OS's preference?  /me has no windows
>around to test it on.  So there might be an OS inconsistency there.  Running
>the tests on windows will uncover that, of course.

If you use the pkg_resources get_metadata and 
metadata_isdir/metadata_listdir operations, you can use /-separated 
paths regardless of platform.


From zooko at zooko.com  Sat Sep  5 15:04:04 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sat, 5 Sep 2009 07:04:04 -0600
Subject: [Distutils] scripts versus console_scripts
In-Reply-To: <h7lqmu$k13$1@ger.gmane.org>
References: <h7lqmu$k13$1@ger.gmane.org>
Message-ID: <3EF9CD0F-4853-4C90-8EEB-CCC7DD125EC2@zooko.com>

On Wednesday,2009-09-02, at 7:07 , Reinout van Rees wrote:

> First things first: what I want to accomplish is to install  
> pyflakes and docutils in a buildout.  That is, I want to have a bin/ 
> pyflakes and bin/rst2* scripts.

See also

http://pypi.python.org/pypi/setuptools_pyflakes

Which adds a setuptools command to run pyflakes.

Regards,

Zooko

From a.cavallo at cavallinux.eu  Sun Sep  6 06:53:11 2009
From: a.cavallo at cavallinux.eu (A. Cavallo)
Date: Sun, 6 Sep 2009 05:53:11 +0100
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>
Message-ID: <200909060553.12210.a.cavallo@cavallinux.eu>

You might give a try to a project of mine:

http://pyvm.sourceforge.net

It provides what people expect from a clean build of python.

Regards,
Antonio

> On Wed, Aug 26, 2009 at 8:38 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
> ...
>
> > 3) exist any plan for buildout to obtain the same isolation level than
> > virtualenv ? when ?
>
> As Gary mentioned, yes. I hope this will be in 1.5, within a few weeks
> (maybe days :).
>
> > 4) do you see any other alternative to obtain the same effect (we need
> > to test apps between python 2.5 and python 2.6, we see than the buildout
> > dont ignore the global site-package, some dev machines are really messed
> > in their python interpreters used and the eggs/modules/installed in
> > their systems, and we love to deploy the apps inside venvs with
> > mod_wsgi, no more hell with pythonpath)
>
> Sure. The simplest, IMO, is to use a clean Python built from source
> that you keep clean and share among your various projects.  We deploy
> to CentOS-based systems and deploy "cleanpython" RPMs (for both 2.4
> and 2.6) along side the Red Hat supplied installs.  We develop on Mac
> and Ubuntu and typically have clean Python builds that we share among
> our various projects.
>
> Of course, you can create a virtualenv and keep it clean and use it
> for multiple buildouts. This is the rough equivalent of of creating a
> clean Python. Buildout never installs into site-packages, so if you
> create a clean virtualenv, buildout won't dirty it.
>
> Jim

From chris at simplistix.co.uk  Mon Sep  7 14:15:08 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 07 Sep 2009 13:15:08 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>	<4A8A606D.6090306@taupro.com>	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>	<4A8A8FE9.6070905@trueblade.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
Message-ID: <4AA4F94C.9080702@simplistix.co.uk>

Tarek Ziad? wrote:
>> - I've never had to use anything that would require the kind of templating
>> being discussed here, so please make setup.cfg "just work" if setup.cfg.in
>> isn't there.
> 
> That's the case

Yay :-)

>> - I think any kind of templating language is *way to heavyweight*. If you
>> need anything more than simple string substitution, then the code should be
>> in setup.py
> 
> Well, the point is to be able to define sections in a static file that
> will be used without
> having to execute any code in the distribution.
> 
> For example being able to express:
> 
> "if the target python is version 2.6 the dependencies are ..."
> 
> The goal is to be able to run that part on a vanilla Python. without
> having to rely on the distribution's setup.py

Seems like a bad goal to me.

I'd prefer setup.cfg to be totally static. If there are complicated 
if/then/else's needed, they should be in setup.py.

As soon as this file becomes dynamic, we're back in the situation where 
you can't tell what a package requires without installing it, which is 
something I'd really like to not have to do.

cheers,

Chris

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

From chris at simplistix.co.uk  Mon Sep  7 17:12:40 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 07 Sep 2009 16:12:40 +0100
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <B9F4715D-CDE1-4509-B1BE-ACB159080D03@canonical.com>
References: <1251333526.5297.52.camel@alisah>	<DB395FDF-0120-449C-AF6C-1DF742BE5038@canonical.com>	<4A9639BF.50902@simplistix.co.uk>	<416D11D0-8C33-4F20-9BE6-65A4DDBF94C8@canonical.com>	<4A9BC21C.9080606@simplistix.co.uk>
	<B9F4715D-CDE1-4509-B1BE-ACB159080D03@canonical.com>
Message-ID: <4AA522E8.6050506@simplistix.co.uk>

Gary Poster wrote:
> 
> In the simplest case:
> 
> allowed-eggs-from-site-packages =
> 
> That means you don't allow any eggs from site packages.  So, this means 
> that if one of your direct or indirect dependencies is docutils, and 
> docutils is installed as an egg in your system, when the eggs for your 
> buildout are assembled, the system egg will be ignored, and buildout 
> will go on the hunt for one someplace else.  The typical result is that 
> the egg that it finds will be earlier in the site path, so it has 
> precedence in scripts and so on.

Ah, OK :-)

> Alternatively, consider this.
> allowed-eggs-from-site-packages =
>     lxml
> 
> That is, you only allow the lxml egg from site packages.  All the rest 
> will be ignored, as per the description above.

Hmm, okay, but what ensures the version of lxml found in site packages 
doesn't match the one required by the buildout?

> allowed-eggs-from-site-packages
>     This option interacts with the ``include-site-packages`` option in the
>     following ways.
> 
>     If ``include-site-packages`` is true, then
>     ``allowed-eggs-from-site-packages`` filters what eggs from 
> site-packages
>     may be chosen. 

Cool :-)

>     If ``include-site-packages`` is false, the value of
>     ``allowed-eggs-from-site-packages`` is irrelevant.

I'd suggest an exception should even be raised in this case...

> The next simplest answer is to use the new "include-site-packages = 
> false" option.  That's a tiny bit like using a virtualenv for your 
> buildout, in that you are using the system executable but a clean 
> site-packages.

Yep, this we like :-)

cheers,

Chris

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

From ziade.tarek at gmail.com  Mon Sep  7 17:41:40 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 7 Sep 2009 17:41:40 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA4F94C.9080702@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
Message-ID: <94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>

On Mon, Sep 7, 2009 at 2:15 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>> For example being able to express:
>>
>> "if the target python is version 2.6 the dependencies are ..."
>>
>> The goal is to be able to run that part on a vanilla Python. without
>> having to rely on the distribution's setup.py
>
> Seems like a bad goal to me.

Why ?

>
> I'd prefer setup.cfg to be totally static. If there are complicated
> if/then/else's needed, they should be in setup.py.

The template engine will be restricted to "if", and the expression
will be able to ^may only 3 values:

- the python version
- sys.platform
- os.name

>
> As soon as this file becomes dynamic, we're back in the situation where you
> can't tell what a package requires without installing it, which is something
> I'd really like to not have to do.
>

setup.cfg stays static. We're talking about the ability to add a
setup.cfg.in file,
that generates the setup.cfg file ***without having to run any third
party code***.

So again, this will not require any installation to run since transforming
a "setup.cfg.in" into a "setup.cfg" will just require a vanilla Python

to synthetize =

if exists(setup.cfg.in):
  setup.cfg = distutils.some_func(setup.cfg.in)
else:
  nothing

That's the whole point ! ;)

It means that people will be able to read the .cfg file, and if needed
to rebuild for their platform
without any installation required.

Eventually, PyPI can provide both (.cfg and .cfg.in) as metadata that a tool can
grab to see what's required for installation, *without installing the package*

Regards
Tarek

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

From chris at simplistix.co.uk  Mon Sep  7 23:56:48 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 07 Sep 2009 22:56:48 +0100
Subject: [Distutils] what does zc.recipe.egg do with disutils scripts?
Message-ID: <4AA581A0.20105@simplistix.co.uk>

Hi,

I'm trying to get docutils installed and running with this part:

[docs]
recipe = zc.recipe.egg:scripts
eggs = docutils

However, the following scripts specified in docutils' setup.py are not 
installed:

     'scripts' : ['tools/rst2html.py',
                  'tools/rst2s5.py',
                  'tools/rst2latex.py',
                  'tools/rst2newlatex.py',
                  'tools/rst2xml.py',
                  'tools/rst2pseudoxml.py',
                  'tools/rstpep2html.py',
                  ],}

How do I get them installed? I've tried adding dependent-scripts = true 
and/or interpreter = py, but nothing seems to work...

What am I doing wrong?

cheers,

Chris

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

From david.lyon at preisshare.net  Tue Sep  8 00:54:11 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 07 Sep 2009 18:54:11 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>
Message-ID: <a10660cf665953f64022aeacac9210a4@preisshare.net>

On Mon, 7 Sep 2009 17:41:40 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
>> I'd prefer setup.cfg to be totally static. If there are complicated
>> if/then/else's needed, they should be in setup.py.

+1

> The template engine will be restricted to "if", and the expression
> will be able to ^may only 3 values:
> 
> - the python version
> - sys.platform
> - os.name

That's very, very hard....

It makes it harder for the developer because they must learn yet 
another templating system. Add half a days work to every developer.

>> As soon as this file becomes dynamic, we're back in the situation where
>> you
>> can't tell what a package requires without installing it, which is
>> something
>> I'd really like to not have to do.

+1

> setup.cfg stays static. We're talking about the ability to add a
> setup.cfg.in file,
> that generates the setup.cfg file ***without having to run any third
> party code***.
> 
> So again, this will not require any installation to run since
transforming
> a "setup.cfg.in" into a "setup.cfg" will just require a vanilla Python

It's still just overly complicated..

> to synthetize =
> 
> if exists(setup.cfg.in):
>   setup.cfg = distutils.some_func(setup.cfg.in)
> else:
>   nothing
> 
> That's the whole point ! ;)

Point is to introduce distutils? haha - why not just use setuptools?

> It means that people will be able to read the .cfg file, and if needed
> to rebuild for their platform
> without any installation required.
> 
> Eventually, PyPI can provide both (.cfg and .cfg.in) as metadata that a
> tool can
> grab to see what's required for installation, *without installing the
> package*

I can see your intentions here are good. But what you are suggesting is
just overly complicated for what is required. There's no need for a
templating engine, in this part of distutils.

Yes, introducing a template engine might be good for multi-platform
output.

But the setup.py and setup.cfg and [setup] sections must be readily
understood by the complete novice. That's the point that you don't
seem to understand yet. Stop making it non-obvious.

No installation system I have ever heard of makes it mandatory
to understand a template system to be able to write your "hello
world - I'm installed".... script..

Especially when the alternative is just "if os.name == "win32:"

..

I see nothing wrong with such a simple piece of python code...

Regards

David


From jim at zope.com  Tue Sep  8 01:20:17 2009
From: jim at zope.com (Jim Fulton)
Date: Mon, 7 Sep 2009 19:20:17 -0400
Subject: [Distutils] what does zc.recipe.egg do with disutils scripts?
In-Reply-To: <4AA581A0.20105@simplistix.co.uk>
References: <4AA581A0.20105@simplistix.co.uk>
Message-ID: <1099b90b0909071620t24cd1324r168e015f9530e670@mail.gmail.com>

On Mon, Sep 7, 2009 at 5:56 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Hi,
>
> I'm trying to get docutils installed and running with this part:
>
> [docs]
> recipe = zc.recipe.egg:scripts
> eggs = docutils
>
> However, the following scripts specified in docutils' setup.py are not
> installed:
>
> ? ?'scripts' : ['tools/rst2html.py',
> ? ? ? ? ? ? ? ? 'tools/rst2s5.py',
> ? ? ? ? ? ? ? ? 'tools/rst2latex.py',
> ? ? ? ? ? ? ? ? 'tools/rst2newlatex.py',
> ? ? ? ? ? ? ? ? 'tools/rst2xml.py',
> ? ? ? ? ? ? ? ? 'tools/rst2pseudoxml.py',
> ? ? ? ? ? ? ? ? 'tools/rstpep2html.py',
> ? ? ? ? ? ? ? ? ],}

This recipe only supports console_script entry points.  There is work
underway to add support for distutils scripts.

> How do I get them installed? I've tried adding dependent-scripts = true
> and/or interpreter = py, but nothing seems to work...

You might find this useful:

http://pypi.python.org/pypi/zc.rst2

>
> What am I doing wrong?

Nothing.

Jim

-- 
Jim Fulton

From david at ar.media.kyoto-u.ac.jp  Tue Sep  8 04:13:50 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 08 Sep 2009 11:13:50 +0900
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA4F94C.9080702@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>	<4A8A606D.6090306@taupro.com>	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>	<4A8A8FE9.6070905@trueblade.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
Message-ID: <4AA5BDDE.100@ar.media.kyoto-u.ac.jp>

Chris Withers wrote:
> Seems like a bad goal to me.
>
> I'd prefer setup.cfg to be totally static. If there are complicated
> if/then/else's needed, they should be in setup.py.
>
> As soon as this file becomes dynamic, we're back in the situation
> where you can't tell what a package requires without installing it,
> which is something I'd really like to not have to do.

I don't see how you would reach that conclusion - rpm spec files have
basic if/then/else, and they certainly don't have the problem you
mention. Cabal files in haskell have this construction as well. Both
work very well.

cheers,

David

From david at ar.media.kyoto-u.ac.jp  Tue Sep  8 04:18:09 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 08 Sep 2009 11:18:09 +0900
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <a10660cf665953f64022aeacac9210a4@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>	<4A8A606D.6090306@taupro.com>	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>	<4A8A8FE9.6070905@trueblade.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	<4AA4F94C.9080702@simplistix.co.uk>	<94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>
	<a10660cf665953f64022aeacac9210a4@preisshare.net>
Message-ID: <4AA5BEE1.9040200@ar.media.kyoto-u.ac.jp>

David Lyon wrote:
>
> I can see your intentions here are good. But what you are suggesting is
> just overly complicated for what is required. There's no need for a
> templating engine, in this part of distutils.
>   

Compared to other parts of distutils, that's very simple, and actually
useful and well established practice.

> Yes, introducing a template engine might be good for multi-platform
> output.
>
> But the setup.py and setup.cfg and [setup] sections must be readily
> understood by the complete novice. That's the point that you don't
> seem to understand yet. Stop making it non-obvious.
>   

having if/then don't make distutils more complicated. The point of those
'dynamic' features in the static metadata is that a vast majority of
projects can be *fully* described without a setup.py file - without it,
very few packages would fall in that category.

Once you can describe a non trivial subset of all python packages with a
static metadata file, it means you can use it without using distutils
itself, which is a very big plus.

> No installation system I have ever heard of makes it mandatory
> to understand a template system to be able to write your "hello
> world - I'm installed".... script..
>   

Actually, almost every one I have ever seen does. Which installation
system does not use a templating engine of some sort ? That's a very
common practice.

cheers,

David

From david.lyon at preisshare.net  Tue Sep  8 05:42:36 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 07 Sep 2009 23:42:36 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA5BEE1.9040200@ar.media.kyoto-u.ac.jp>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>	<4A8A606D.6090306@taupro.com>	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>	<4A8A8FE9.6070905@trueblade.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	<4AA4F94C.9080702@simplistix.co.uk>	<94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>
	<a10660cf665953f64022aeacac9210a4@preisshare.net>
	<4AA5BEE1.9040200@ar.media.kyoto-u.ac.jp>
Message-ID: <934ec3aac677df9e46e8b6a253a641f2@preisshare.net>

On Tue, 08 Sep 2009 11:18:09 +0900, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
>> I can see your intentions here are good. But what you are suggesting is
>> just overly complicated for what is required. There's no need for a
>> templating engine, in this part of distutils.
>>   
> 
> Compared to other parts of distutils, that's very simple, and actually
> useful and well established practice.

Perphaps. But why make the simplest part as complex as the most complex.

> having if/then don't make distutils more complicated. 

There's no debate about that. The need for an if/else is clear.

What is up for discussion is having it in python code or
template code.

> The point of those
> 'dynamic' features in the static metadata is that a vast majority of
> projects can be *fully* described without a setup.py file - without it,
> very few packages would fall in that category.

Too complex a statement for me to comment on...

> Once you can describe a non trivial subset of all python packages with a
> static metadata file, it means you can use it without using distutils
> itself, which is a very big plus.

Yes. That's why I have been pushing and pushing for this...

> Actually, almost every one I have ever seen does. Which installation
> system does not use a templating engine of some sort ? That's a very
> common practice.

I originally said, templating isn't required for for a "install-my-hellow
world". Innosetup, NSIS under windows are examples of install systems that
don't require any templating to make a simple installation file.

Regards

David


From ronaldoussoren at mac.com  Tue Sep  8 10:09:31 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 08 Sep 2009 10:09:31 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA4F94C.9080702@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
Message-ID: <23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>


On 7 Sep, 2009, at 14:15, Chris Withers wrote:

> I'd prefer setup.cfg to be totally static. If there are complicated  
> if/then/else's needed, they should be in setup.py.

I have a number of packages where the only logic on setup.py is set  
flags based on the python version or OS. Examples:
* depend on pysqlite in old versions of python where sqlite wasn't in  
the stdlib
* select different compiler flags based for Linux vs. Windows for a C  
extension

It would be nice if those could be expressed in a setup.cfg(.in) file,  
because that way to can introspect these packages without having to  
execute a setup.py file.

>
> As soon as this file becomes dynamic, we're back in the situation  
> where you can't tell what a package requires without installing it,  
> which is something I'd really like to not have to do.

I agree that the file shouldn't be too dynamic, we don't need a full  
programming language in setup.cfg because we already have setup.py  
files.

The proof of concept already severely limits what constructs the  
template can use, and those should both be enough for most python  
packages and simple enough to allow easy introspection.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090908/801ce5a4/attachment.bin>

From chris at simplistix.co.uk  Tue Sep  8 10:18:50 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 09:18:50 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
Message-ID: <4AA6136A.7080904@simplistix.co.uk>

Ronald Oussoren wrote:
> 
> I have a number of packages where the only logic on setup.py is set 
> flags based on the python version or OS. Examples:
> * depend on pysqlite in old versions of python where sqlite wasn't in 
> the stdlib

<mini rant>
If Python had a packaging system *and* used it for the standard library, 
then things like this wouldn't be a problem...
The setup.cfg could just say "requires sqlite greater than version 
x.y.z", and if it was in the standard library, it would be used unless a 
newer version was needed. It would also mean it would be possible to 
release bug fix versions of the standard library packages without having 
to roll a whole python release.
Better yet, since "python" should be a package as far as the packaging 
system is concerned, library versions can just say what versions of 
python they work with.
</rant>

> It would be nice if those could be expressed in a setup.cfg(.in) file, 
> because that way to can introspect these packages without having to 
> execute a setup.py file.

No, you just have to execute setup.cfg instead :-(

For me, setup.cfg should contain static stuff like name, description, 
url and dependencies. Anything else that varies like this can and should 
be in setup.py. We already have a fantastic scripting language, why coem 
up with another one?

> I agree that the file shouldn't be too dynamic, we don't need a full 
> programming language in setup.cfg because we already have setup.py files.

It's an extremely slippery slope, as soon as there's any possibility for 
weirdness some inexperienced developer will jump at the chance to abuse 
it to its fullest extent :-(

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Sep  8 10:26:19 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 10:26:19 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA6136A.7080904@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
Message-ID: <94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>

2009/9/8 Chris Withers <chris at simplistix.co.uk>:
>> I agree that the file shouldn't be too dynamic, we don't need a full
>> programming language in setup.cfg because we already have setup.py files.
>
> It's an extremely slippery slope, as soon as there's any possibility for
> weirdness some inexperienced developer will jump at the chance to abuse it
> to its fullest extent :-(

I am restricting the template language to two expressions: "if" and "else"

The values you can work with in the "if" and "else" section will be
restricted to :

- the python version (string)
- the os.name (string)
- the os.platform (string)
- an extra function called "long_description", to be able to point a
file for the long description field

and nothing else.

How anyone could abuse of that kind of expressions ?

Regards
Tarek

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

From chris at simplistix.co.uk  Tue Sep  8 10:29:58 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 09:29:58 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>	
	<4A8A8FE9.6070905@trueblade.com>	
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	
	<4A9BBA2B.6010903@simplistix.co.uk>	
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	
	<4AA4F94C.9080702@simplistix.co.uk>	
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>	
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
Message-ID: <4AA61606.6060002@simplistix.co.uk>

Tarek Ziad? wrote:
> - an extra function called "long_description", to be able to point a
> file for the long description field

I can't comment on the others, but this is unnecessary. Why do you need 
more than:

long_decription="some lump of text"

or

long_description_path ="path/relative/to/directory/containing/setup.py"

...with it being an error for both to be specified?

cheers,

Chris

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

From reinout at vanrees.org  Tue Sep  8 10:29:55 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 8 Sep 2009 08:29:55 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
	<1099b90b0909021050v986dcbsf0759ff5d567d33f@mail.gmail.com>
	<94bdd2610909030934s8ed4688v2885920a8ae3101b@mail.gmail.com>
	<1099b90b0909031058y6c5f1a1frf0ae5cb7f84934ce@mail.gmail.com>
	<20090904000502.D35203A409E@sparrow.telecommunity.com>
	<h7qvqk$heq$1@ger.gmane.org> <h7rc43$sk5$1@ger.gmane.org>
	<1099b90b0909040955m1d4a94e9l3e49b8aaf5ecc6eb@mail.gmail.com>
	<h7s0tt$vir$1@ger.gmane.org>
	<20090904220030.6568C3A4093@sparrow.telecommunity.com>
Message-ID: <slrnhac5g3.sof.reinout@isengrim.local>

On 2009-09-04, P.J. Eby <pje at telecommunity.com> wrote:
> At 09:30 PM 9/4/2009 +0000, Reinout van Rees wrote:
>>There's one thing I couldn't find out: does the zipfile module report
>>filenames as slashes or does it use the OS's preference?  /me has no windows
>>around to test it on.  So there might be an OS inconsistency there.  Running
>>the tests on windows will uncover that, of course.
>
> If you use the pkg_resources get_metadata and 
> metadata_isdir/metadata_listdir operations, you can use /-separated 
> paths regardless of platform.

Ah, thanks.  That's 18 lines of code gone in exchange for just 4 :-)  No more
"import zipfile".


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From reinout at vanrees.org  Tue Sep  8 10:35:34 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 8 Sep 2009 08:35:34 +0000 (UTC)
Subject: [Distutils] scripts versus console_scripts
References: <h7lqmu$k13$1@ger.gmane.org>
	<3EF9CD0F-4853-4C90-8EEB-CCC7DD125EC2@zooko.com>
Message-ID: <slrnhac5qm.sof.reinout@isengrim.local>

On 2009-09-05, Zooko Wilcox-O'Hearn <zooko at zooko.com> wrote:
> On Wednesday,2009-09-02, at 7:07 , Reinout van Rees wrote:
>
>> First things first: what I want to accomplish is to install  
>> pyflakes and docutils in a buildout.  That is, I want to have a bin/ 
>> pyflakes and bin/rst2* scripts.
>
> See also
>
> http://pypi.python.org/pypi/setuptools_pyflakes
>
> Which adds a setuptools command to run pyflakes.

I had not spotted that one.  Anyway, when my branch is merged, buildout
supports it out of the box :-)  I think I've nailed down everything there is
to nail down (apart from running tests on windows which I cannot).


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ronaldoussoren at mac.com  Tue Sep  8 10:38:31 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 08 Sep 2009 10:38:31 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA6136A.7080904@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
Message-ID: <46DB287F-261D-45D3-A7C3-264B84EB3FC5@mac.com>


On 8 Sep, 2009, at 10:18, Chris Withers wrote:

> Ronald Oussoren wrote:
>> I have a number of packages where the only logic on setup.py is set  
>> flags based on the python version or OS. Examples:
>> * depend on pysqlite in old versions of python where sqlite wasn't  
>> in the stdlib
>
> <mini rant>
> If Python had a packaging system *and* used it for the standard  
> library, then things like this wouldn't be a problem...
> The setup.cfg could just say "requires sqlite greater than version  
> x.y.z", and if it was in the standard library, it would be used  
> unless a newer version was needed. It would also mean it would be  
> possible to release bug fix versions of the standard library  
> packages without having to roll a whole python release.

Yes, it is sad that only wsgiref is included in the stdlib with an egg- 
info file.

> Better yet, since "python" should be a package as far as the  
> packaging system is concerned, library versions can just say what  
> versions of python they work with.

I like this idea, adding this to distutils and setuptools should be  
easy enough as well.

> </rant>
>
>> It would be nice if those could be expressed in a setup.cfg(.in)  
>> file, because that way to can introspect these packages without  
>> having to execute a setup.py file.
>
> No, you just have to execute setup.cfg instead :-(

Yes, but I'd be much happier about exanding a template than executing  
some arbitrary python code.  You obviously have to trust the author  
when you actually install and use the package, but it would be nice if  
one could extract useful information from a package before doing that.
>
> For me, setup.cfg should contain static stuff like name,  
> description, url and dependencies. Anything else that varies like  
> this can and should be in setup.py. We already have a fantastic  
> scripting language, why coem up with another one?

Because static stuff is not always completely static.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090908/0f02ceca/attachment.bin>

From reinout at vanrees.org  Tue Sep  8 10:38:16 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 8 Sep 2009 08:38:16 +0000 (UTC)
Subject: [Distutils] what does zc.recipe.egg do with disutils scripts?
References: <4AA581A0.20105@simplistix.co.uk>
	<1099b90b0909071620t24cd1324r168e015f9530e670@mail.gmail.com>
Message-ID: <slrnhac5vo.sof.reinout@isengrim.local>

On 2009-09-07, Jim Fulton <jim at zope.com> wrote:
> On Mon, Sep 7, 2009 at 5:56 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>> Hi,
>>
>> I'm trying to get docutils installed and running with this part:
>>
>> [docs]
>> recipe = zc.recipe.egg:scripts
>> eggs = docutils
>>
>> However, the following scripts specified in docutils' setup.py are not
>> installed:
>
> This recipe only supports console_script entry points.  There is work
> underway to add support for distutils scripts.

Chris, you could try out the zc.buildout/branches/reinout-scripts branch.
I've fixed it there.


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From floris.bruynooghe at gmail.com  Tue Sep  8 10:50:41 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 8 Sep 2009 09:50:41 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>
References: <aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<94bdd2610909070841r475f30bfu2da58f519fd56a8e@mail.gmail.com>
Message-ID: <20090908085041.GB7815@laurie.devork>

On Mon, Sep 07, 2009 at 05:41:40PM +0200, Tarek Ziad? wrote:
> The template engine will be restricted to "if", and the expression
> will be able to ^may only 3 values:
> 
> - the python version
> - sys.platform
> - os.name

The members of the structure/named-tuple returned os.uname() too
please, otherwise I won't have enough information.  On Windows I guess
the service pack versions etc are the equivalent.

Regards
Floris

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

From chris at simplistix.co.uk  Tue Sep  8 12:04:30 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 11:04:30 +0100
Subject: [Distutils] Distribute 0.6 released
In-Reply-To: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>
Message-ID: <4AA62C2E.30603@simplistix.co.uk>

Hi Tarek,

Tarek Ziad? wrote:
> I am pleased to announce the release of Distribute 0.6.
> 
> Distribute is a friendly fork of the Setuptools project.
> 
> You can get more info, download it and install it using the
> instructions from its PyPI page :
> http://pypi.python.org/pypi/distribute

I've been working on a branch of zc.buildout that uses distribute 
instead of setuptools:

http://svn.zope.org/zc.buildout/branches/use_distribute/

...and I've hit a problem at the first hurdle. I've changed dev.py to 
use distribute, but by the time the subprocess call is made to setup.py, 
even though .../eggs/distribute-0.6-py2.6.egg is on PYTHONPATH, I get:

   File ".../setup.py", line 20, in <module>
     from distribute import setup, find_packages
ImportError: No module named distribute

I wonder if you could try out that branch and see if you can reproduce 
it? If you can, any hints as to what the problem might be would be great :-)

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Sep  8 12:11:41 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 12:11:41 +0200
Subject: [Distutils] Distribute 0.6 released
In-Reply-To: <4AA62C2E.30603@simplistix.co.uk>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>
	<4AA62C2E.30603@simplistix.co.uk>
Message-ID: <94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>

On Tue, Sep 8, 2009 at 12:04 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Hi Tarek,
>

Hi Chris,

>
> I've been working on a branch of zc.buildout that uses distribute instead of
> setuptools:
>
> http://svn.zope.org/zc.buildout/branches/use_distribute/
>
> ...and I've hit a problem at the first hurdle. I've changed dev.py to use
> distribute, but by the time the subprocess call is made to setup.py, even
> though .../eggs/distribute-0.6-py2.6.egg is on PYTHONPATH, I get:
>
> ?File ".../setup.py", line 20, in <module>
> ? ?from distribute import setup, find_packages
> ImportError: No module named distribute

The 0.6 version of Distribute does not contain any "distribute"
package. It contains a "setuptools" packages.

If you want to change zc.buildout in order to use distribute,
you have to change the parts of zc.buildout that works with the
"setuptools" *distribution*
and change them so they work with the "distribute" *distribution*

So the change doesn't really concerns zc.buildout code, but all of its
bootstraping code

This is basically what I have done in this version of the boostrap.py script:

http://bitbucket.org/tarek/distribute/src/af557cf7dc1e/buildout/bootstrap.py

It patches a few functions in zc.buildout that harcode the usage of
setuptools distribution.

Now, as Jim said last month, the best way would be to change zc.buildout
so it uses any one of them (setuptools or distribute), by beaing able
to configure this dependency
instead of having it harcoded in the code.

Now for the next version of distribute (0.7) the current default
branch, it's another story :
everything is being renamed so Distribute doesn't compete anymor with Setuptools
namespace.

Regards
Tarek

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

From chris at simplistix.co.uk  Tue Sep  8 12:26:05 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 11:26:05 +0100
Subject: [Distutils] Distribute 0.6 released
In-Reply-To: <94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>	
	<4AA62C2E.30603@simplistix.co.uk>
	<94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>
Message-ID: <4AA6313D.9050006@simplistix.co.uk>

Tarek Ziad? wrote:
>>  File ".../setup.py", line 20, in <module>
>>    from distribute import setup, find_packages
>> ImportError: No module named distribute
> 
> The 0.6 version of Distribute does not contain any "distribute"
> package. It contains a "setuptools" packages.

Ah yes, I remember now...

> Now, as Jim said last month, the best way would be to change zc.buildout
> so it uses any one of them (setuptools or distribute), by beaing able
> to configure this dependency
> instead of having it harcoded in the code.

This just seems like extra work for no reason...

> Now for the next version of distribute (0.7) the current default
> branch, it's another story :
> everything is being renamed so Distribute doesn't compete anymor with Setuptools
> namespace.

I predict uptake of this version will be even slower than that of 0.6, 
which seems pretty slow... It's just such a shame PJE is so stubborn 
about doing a usable release of setuptools...

Chris

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

From david.lyon at preisshare.net  Tue Sep  8 13:00:43 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 08 Sep 2009 07:00:43 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA6136A.7080904@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
Message-ID: <13d2dc789ffc897481edc43e88432a31@preisshare.net>

On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers <chris at simplistix.co.uk>
wrote:
> <mini rant>
> If Python had a packaging system *and* used it for the standard library, 
> then things like this wouldn't be a problem...
> The setup.cfg could just say "requires sqlite greater than version 
> x.y.z", and if it was in the standard library, it would be used unless a 
> newer version was needed. 

+1

Actually, this was already discussed on this mailing list.

I suggested that a "requires" section could easily do this, something
along the lines of:

[Requires]
stdlib=sqlite>=1.5

So the concept of having an if/else test for this is superfluous.

> It would also mean it would be possible to 
> release bug fix versions of the standard library packages without having 
> to roll a whole python release.

+1

> Better yet, since "python" should be a package as far as the packaging 
> system is concerned, library versions can just say what versions of 
> python they work with.

+1 - good idea

David

From chris at simplistix.co.uk  Tue Sep  8 14:18:56 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 13:18:56 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <13d2dc789ffc897481edc43e88432a31@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<13d2dc789ffc897481edc43e88432a31@preisshare.net>
Message-ID: <4AA64BB0.7090309@simplistix.co.uk>

David Lyon wrote:
> On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers <chris at simplistix.co.uk>
> wrote:
>> <mini rant>
>> If Python had a packaging system *and* used it for the standard library, 
>> then things like this wouldn't be a problem...
>> The setup.cfg could just say "requires sqlite greater than version 
>> x.y.z", and if it was in the standard library, it would be used unless a 
>> newer version was needed. 
> 
> +1
> 
> Actually, this was already discussed on this mailing list.

Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev...
(CC'ing so they can tell me I'm wrong ;-) )

> I suggested that a "requires" section could easily do this, something
> along the lines of:
> 
> [Requires]
> stdlib=sqlite>=1.5

Tarek, How are requirements spelled for packages in your current setup.cfg?

I really don't see why anything should be different for standard library 
packages (ie: the stdlib= prefix in David's example). Python 
distributions should just declare all the versions they come with in the 
same way that whatever-is-being-built by Tarek can introspect in the 
same way as any other package...

> So the concept of having an if/else test for this is superfluous.

Right.

>> It would also mean it would be possible to 
>> release bug fix versions of the standard library packages without having 
>> to roll a whole python release.
> 
> +1

...which in turn would mean that the standard library is no longer a 
place where packages go to die...

>> Better yet, since "python" should be a package as far as the packaging 
>> system is concerned, library versions can just say what versions of 
>> python they work with.
> 
> +1 - good idea

...and for me, the "python" package should be just another package in 
the distributions dance, called "python" ;-)

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Sep  8 14:20:30 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 14:20:30 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA61606.6060002@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
Message-ID: <94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>

On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> - an extra function called "long_description", to be able to point a
>> file for the long description field
>
> I can't comment on the others, but this is unnecessary. Why do you need more
> than:
>
> long_decription="some lump of text"
>
> or
>
> long_description_path ="path/relative/to/directory/containing/setup.py"
>
> ...with it being an error for both to be specified?
>
> cheers,
>

The practice in the community is to create the long_description field
using a separate reStructuredText file
and reaching it in setup.py like this for example:

long_description = open('README.txt').read()

Having a callable that provides this feature in the template allows writing:

"""
[setup.cfg]

long_description: {$ long_description('README.txt') $}
"""

Thus avoiding to write anything in setup.py for that particular case.
the callable could be called "read_file()" maybe, so it's clearer.

long_description_path can't be added in the final PKG-INFO because
we want a self-contained metadata static file that doesn't require an
extra resource (like an external file)

Whereas having a file path in setup.cfg.in is acceptable, as long as
the resulting setup.cfg
contains everything needed to get the metadata of the package without
further depenencies.

so if by the time setup.cfg.in is compiled, the path cannot be found,
the field will have its value set to "UNKOWN" in setup.cfg

From ziade.tarek at gmail.com  Tue Sep  8 14:29:12 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 14:29:12 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA64BB0.7090309@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<13d2dc789ffc897481edc43e88432a31@preisshare.net>
	<4AA64BB0.7090309@simplistix.co.uk>
Message-ID: <94bdd2610909080529w4b3fc34cy43be7643a8e06391@mail.gmail.com>

2009/9/8 Chris Withers <chris at simplistix.co.uk>:
>> I suggested that a "requires" section could easily do this, something
>> along the lines of:
>>
>> [Requires]
>> stdlib=sqlite>=1.5
>
> Tarek, How are requirements spelled for packages in your current setup.cfg?

Sorry, that's another problem we are dealing with here e.g. How *one*
requirement is defined.
The .cfg file is just a format that holds values, like you would
express them in command line or in
arguments.

The "How are requirements spelled" part is the changes we will add in PEP 345.

The templating part is just here to make these requirements (or anything else)
vary, depending on a few environment values, so it can be read without
installing
the distribution, with a vanilla Python.

Please stop cross-posting in other mailing-lists it makes the
discussions confusing.

there are two discussions, to be talked in distutils-SIG:

1/ static metadata using a setup.cfg.in (the current one)
2/ changes that will occur in PEP 345, to include requirement definitions

Regards
Tarek

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

From eric at trueblade.com  Tue Sep  8 14:32:02 2009
From: eric at trueblade.com (Eric Smith)
Date: Tue, 08 Sep 2009 08:32:02 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	<4AA4F94C.9080702@simplistix.co.uk>	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>	<4AA6136A.7080904@simplistix.co.uk>	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
Message-ID: <4AA64EC2.1050202@trueblade.com>

Tarek Ziad? wrote:
> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<chris at simplistix.co.uk> wrote:
>> Tarek Ziad? wrote:
>>> - an extra function called "long_description", to be able to point a
>>> file for the long description field
>> I can't comment on the others, but this is unnecessary. Why do you need more
>> than:
>>
>> long_decription="some lump of text"
>>
>> or
>>
>> long_description_path ="path/relative/to/directory/containing/setup.py"
>>
>> ...with it being an error for both to be specified?
>>
>> cheers,
>>
> 
> The practice in the community is to create the long_description field
> using a separate reStructuredText file
> and reaching it in setup.py like this for example:
> 
> long_description = open('README.txt').read()
> 
> Having a callable that provides this feature in the template allows writing:
> 
> """
> [setup.cfg]
> 
> long_description: {$ long_description('README.txt') $}
> """
> 
> Thus avoiding to write anything in setup.py for that particular case.
> the callable could be called "read_file()" maybe, so it's clearer.
> 
> long_description_path can't be added in the final PKG-INFO because
> we want a self-contained metadata static file that doesn't require an
> extra resource (like an external file)
> 
> Whereas having a file path in setup.cfg.in is acceptable, as long as
> the resulting setup.cfg
> contains everything needed to get the metadata of the package without
> further depenencies.
> 
> so if by the time setup.cfg.in is compiled, the path cannot be found,
> the field will have its value set to "UNKOWN" in setup.cfg

Which all points out that it's setup.cfg that is the static metadata, 
and that you can generate it any way you want. If you want to use m4, 
use m4. If you want to use python, use python. If you want to have some 
makefile driven approach, or use autoconf, or whatever, do that.

setup.cfg should be entirely static except for some simple if-then-else 
logic involving versions, as Tarek has described earlier. That is, it 
should only contain logic that needs to be decided on the platform where 
the installation is taking place. This is basically what RPM provides.

Any other logic, in particular logic used solely for building setup.cfg, 
  should be outside the scope of this system, because you can use any 
tool at all for it.

From ziade.tarek at gmail.com  Tue Sep  8 14:53:49 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 14:53:49 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA64EC2.1050202@trueblade.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
Message-ID: <94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>

On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith<eric at trueblade.com> wrote:
> Tarek Ziad? wrote:
>>
>> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<chris at simplistix.co.uk>
>> wrote:
>>>
>>> Tarek Ziad? wrote:
>>>>
>>>> - an extra function called "long_description", to be able to point a
>>>> file for the long description field
>>>
>>> I can't comment on the others, but this is unnecessary. Why do you need
>>> more
>>> than:
>>>
>>> long_decription="some lump of text"
>>>
>>> or
>>>
>>> long_description_path ="path/relative/to/directory/containing/setup.py"
>>>
>>> ...with it being an error for both to be specified?
>>>
>>> cheers,
>>>
>>
>> The practice in the community is to create the long_description field
>> using a separate reStructuredText file
>> and reaching it in setup.py like this for example:
>>
>> long_description = open('README.txt').read()
>>
>> Having a callable that provides this feature in the template allows
>> writing:
>>
>> """
>> [setup.cfg]
>>
>> long_description: {$ long_description('README.txt') $}
>> """
>>
>> Thus avoiding to write anything in setup.py for that particular case.
>> the callable could be called "read_file()" maybe, so it's clearer.
>>
>> long_description_path can't be added in the final PKG-INFO because
>> we want a self-contained metadata static file that doesn't require an
>> extra resource (like an external file)
>>
>> Whereas having a file path in setup.cfg.in is acceptable, as long as
>> the resulting setup.cfg
>> contains everything needed to get the metadata of the package without
>> further depenencies.
>>
>> so if by the time setup.cfg.in is compiled, the path cannot be found,
>> the field will have its value set to "UNKOWN" in setup.cfg
>
> Which all points out that it's setup.cfg that is the static metadata, and
> that you can generate it any way you want. If you want to use m4, use m4. If
> you want to use python, use python. If you want to have some makefile driven
> approach, or use autoconf, or whatever, do that.
>
> setup.cfg should be entirely static except for some simple if-then-else
> logic involving versions, as Tarek has described earlier. That is, it should
> only contain logic that needs to be decided on the platform where the
> installation is taking place. This is basically what RPM provides.
>
> Any other logic, in particular logic used solely for building setup.cfg,
> ?should be outside the scope of this system, because you can use any tool at
> all for it.
>

So you are suggesting that setup.cfg includes the "if/else" logic
instead of having it
in a "setup.cfg.in" file ?

In that case, if we want to keep a configparser-compatible file, we
need to find another
way to express these if/else parts, which will probably lead to a
complex, non natural
syntax.

Having a "setup.cfg.in" file with if/else logic in it, to build the
setup.cfg independanlty
from the package code, using a function provided by python's stdlib, allows
us to have a simple syntax.

Regards
Tarek

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

From ncoghlan at gmail.com  Tue Sep  8 15:00:30 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 08 Sep 2009 23:00:30 +1000
Subject: [Distutils] [Python-Dev]  Static metadata using setup.cfg
In-Reply-To: <4AA64BB0.7090309@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>	<4A8A606D.6090306@taupro.com>	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>	<4A8A8FE9.6070905@trueblade.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	<4AA4F94C.9080702@simplistix.co.uk>	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>	<4AA6136A.7080904@simplistix.co.uk>	<13d2dc789ffc897481edc43e88432a31@preisshare.net>
	<4AA64BB0.7090309@simplistix.co.uk>
Message-ID: <4AA6556E.8070902@gmail.com>

Chris Withers wrote:
> David Lyon wrote:
>> On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers
>> <chris at simplistix.co.uk>
>> wrote:
>>> <mini rant>
>>> If Python had a packaging system *and* used it for the standard
>>> library, then things like this wouldn't be a problem...
>>> The setup.cfg could just say "requires sqlite greater than version
>>> x.y.z", and if it was in the standard library, it would be used
>>> unless a newer version was needed. 
>>
>> +1
>>
>> Actually, this was already discussed on this mailing list.
> 
> Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev...
> (CC'ing so they can tell me I'm wrong ;-) )

My recollection of the python-dev discussions was that the outcome was
"there isn't even a distutils-sig consensus yet, so it's a little early
for python-dev to be sticking its oar in". Also, I don't think providing
new metadata *describing* the standard library was particularly
controversial - it was more radical ideas of actually breaking up the
core distro into separate components that met resistance. Third party
installers having the power to easily "replace" standard library modules
for more than a single application was also a heavily debated feature
(since that way lies unintended coupling and application/library
installations that break previously installed applications).

It's probably also worth mentioning that on many of these topics there
is a recurring communications gap that usually becomes painful for the
distutils-sig side as core devs re-ask questions that were hashed out on
the distutils list long before. So I would suggest being prepared to
summarise and provide links to such discussions when this all becomes
settled enough to bring back to the whole of python-dev. The back and
forth of an archived mailing list discussion can sometimes be more
persuasive than the relatively sanitised summaries that end up in a PEP :)

That said, Tarek's response suggests that this still isn't ready for a
wider python-dev discussion, so I've set followup-to accordingly.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From chris at simplistix.co.uk  Tue Sep  8 15:49:35 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 14:49:35 +0100
Subject: [Distutils] Buildout using Distribute 0.6
In-Reply-To: <94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>	
	<4AA62C2E.30603@simplistix.co.uk>
	<94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>
Message-ID: <4AA660EF.1060307@simplistix.co.uk>

Tarek Ziad? wrote:
>> I've been working on a branch of zc.buildout that uses distribute instead of
>> setuptools:
>>
>> http://svn.zope.org/zc.buildout/branches/use_distribute/

Okay, I now have all but a couple of tests passing on this branch, with 
all the changes from the trunk merged in as of a few hours ago...

The test failures are a bit weird though:

File "...src/zc/buildout/bootstrap.txt", line 23, in bootstrap.txt
Failed example:
     print 'X'; print system(
         zc.buildout.easy_install._safe_arg(sys.executable)+' '+
         'bootstrap.py'); print 'X' # doctest: +ELLIPSIS
...
     Traceback (most recent call last):
       File "bootstrap.py", line 87, in <module>
         ws.require('zc.buildout' + VERSION)
       File ".../distribute-0.6-py2.6.egg/pkg_resources.py", line 621, 
in require
       File ".../distribute-0.6-py2.6.egg/pkg_resources.py", line 519, 
in resolve
     pkg_resources.DistributionNotFound: setuptools
     <BLANKLINE>

I can't find where setuptools is being required, any ideas?

The other one seems to be a difference in how buildout signatures are 
generated:

File "zc.buildout_co/zc.recipe.egg_/src/zc/recipe/egg/api.txt", line 97, 
in api.txt
Failed example:
     cat(sample_buildout, '.installed.cfg')
Expected:
...
     __buildout_signature__ = sample-6aWMvV2EJ9Ijq+bR8ugArQ==
             zc.recipe.egg-cAsnudgkduAa/Fd+WJIM6Q==
             distribute-0.6-py2.4.egg
             zc.buildout-+rYeCcmFuD1K/aB77XTj5A==
...
Got:
...
     __buildout_signature__ = sample-lpbdfaUB6wBah/5eldWn2w== 
zc.recipe.egg-EkSb+I3tVPPzlm3QwumIDA== distribute-0.6-py2.6.egg 
zc.buildout-mUvpjgUjaaBCXzejndcJIA==
...

Again, I'm open to suggestions as to why distribute appears to cause the 
line endings to vanish in __buildout_signature__?

I'm also curious: do these signatures change with each new version of 
rc.recipe.egg and distribute get released?

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Sep  8 15:58:54 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 15:58:54 +0200
Subject: [Distutils] Buildout using Distribute 0.6
In-Reply-To: <4AA660EF.1060307@simplistix.co.uk>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>
	<4AA62C2E.30603@simplistix.co.uk>
	<94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>
	<4AA660EF.1060307@simplistix.co.uk>
Message-ID: <94bdd2610909080658o700c11f2k82bb2bca433cc96c@mail.gmail.com>

On Tue, Sep 8, 2009 at 3:49 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>>
>>> I've been working on a branch of zc.buildout that uses distribute instead
>>> of
>>> setuptools:
>>>
>>> http://svn.zope.org/zc.buildout/branches/use_distribute/
>
> Okay, I now have all but a couple of tests passing on this branch, with all
> the changes from the trunk merged in as of a few hours ago...
>
> The test failures are a bit weird though:
>
> File "...src/zc/buildout/bootstrap.txt", line 23, in bootstrap.txt
> Failed example:
> ? ?print 'X'; print system(
> ? ? ? ?zc.buildout.easy_install._safe_arg(sys.executable)+' '+
> ? ? ? ?'bootstrap.py'); print 'X' # doctest: +ELLIPSIS
> ...
> ? ?Traceback (most recent call last):
> ? ? ?File "bootstrap.py", line 87, in <module>
> ? ? ? ?ws.require('zc.buildout' + VERSION)
> ? ? ?File ".../distribute-0.6-py2.6.egg/pkg_resources.py", line 621, in
> require
> ? ? ?File ".../distribute-0.6-py2.6.egg/pkg_resources.py", line 519, in
> resolve
> ? ?pkg_resources.DistributionNotFound: setuptools
> ? ?<BLANKLINE>
>
> I can't find where setuptools is being required, any ideas?

This is probably zc.buildout setup.py script because it contains
"install_requires = 'setuptools',"
That's why you need to install Distribute using distribute_setup.py
for instance, so it fakes setuptools
presence for all packages that contains this requirement.


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

From chris at simplistix.co.uk  Tue Sep  8 16:01:30 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 15:01:30 +0100
Subject: [Distutils] Buildout using Distribute 0.6
In-Reply-To: <94bdd2610909080658o700c11f2k82bb2bca433cc96c@mail.gmail.com>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>	
	<4AA62C2E.30603@simplistix.co.uk>	
	<94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>	
	<4AA660EF.1060307@simplistix.co.uk>
	<94bdd2610909080658o700c11f2k82bb2bca433cc96c@mail.gmail.com>
Message-ID: <4AA663BA.3060503@simplistix.co.uk>

Tarek Ziad? wrote:
> This is probably zc.buildout setup.py script because it contains
> "install_requires = 'setuptools',"

Not on my branch it doesn't...

> That's why you need to install Distribute using distribute_setup.py
> for instance,

Which my branch does...

My be worth taking a look at the code ;-)

http://svn.zope.org/zc.buildout/branches/use_distribute/

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Sep  8 16:14:38 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 16:14:38 +0200
Subject: [Distutils] Buildout using Distribute 0.6
In-Reply-To: <4AA663BA.3060503@simplistix.co.uk>
References: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>
	<4AA62C2E.30603@simplistix.co.uk>
	<94bdd2610909080311x7f127276h6e369beb4a02f0d1@mail.gmail.com>
	<4AA660EF.1060307@simplistix.co.uk>
	<94bdd2610909080658o700c11f2k82bb2bca433cc96c@mail.gmail.com>
	<4AA663BA.3060503@simplistix.co.uk>
Message-ID: <94bdd2610909080714y19a4c741j766ee88e0bb41566@mail.gmail.com>

On Tue, Sep 8, 2009 at 4:01 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> This is probably zc.buildout setup.py script because it contains
>> "install_requires = 'setuptools',"
>
> Not on my branch it doesn't...
>
>> That's why you need to install Distribute using distribute_setup.py
>> for instance,
>
> Which my branch does...
> My be worth taking a look at the code ;-)
>
> http://svn.zope.org/zc.buildout/branches/use_distribute/

Your traceback suggests something requires setuptools.
You migh want to put some logs in pkg_resources.resolve

also, make sure Distribute was properly installed: you should
have a "setuptools*.egg-info" directory besides Distribute.

From chris at simplistix.co.uk  Tue Sep  8 17:18:02 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 16:18:02 +0100
Subject: [Distutils] what does zc.recipe.egg do with disutils scripts?
In-Reply-To: <slrnhac5vo.sof.reinout@isengrim.local>
References: <4AA581A0.20105@simplistix.co.uk>	<1099b90b0909071620t24cd1324r168e015f9530e670@mail.gmail.com>
	<slrnhac5vo.sof.reinout@isengrim.local>
Message-ID: <4AA675AA.1040408@simplistix.co.uk>

Reinout van Rees wrote:
> On 2009-09-07, Jim Fulton <jim at zope.com> wrote:
>> On Mon, Sep 7, 2009 at 5:56 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>>> Hi,
>>>
>>> I'm trying to get docutils installed and running with this part:
>>>
>>> [docs]
>>> recipe = zc.recipe.egg:scripts
>>> eggs = docutils
>>>
>>> However, the following scripts specified in docutils' setup.py are not
>>> installed:
>> This recipe only supports console_script entry points.  There is work
>> underway to add support for distutils scripts.
> 
> Chris, you could try out the zc.buildout/branches/reinout-scripts branch.
> I've fixed it there.

How do I actually go about doing that?

If I just put that checkout in the develop line of my buildout will get 
picked?

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Sep  8 18:19:25 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 17:19:25 +0100
Subject: [Distutils] [buildout[ How do I use stuff specified in the
 distutils.command entry_point?
Message-ID: <4AA6840D.3@simplistix.co.uk>

Hi All,

Sphinx, among others, provides command in this entry point.

With this buildout:

[buildout]
parts = sphinx

[sphinx]
recipe = zc.recipe.egg
eggs = sphinx

And based on the entry points listed here:

http://bitbucket.org/birkenfeld/sphinx/src/447109cf9b01/setup.py#cl-182

I'd expect to be able to do:

$ bin/buildout setup setup.py build_sphinx

But I get:

Running setup script 'setup.py'.
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
    or: setup.py --help [cmd1 cmd2 ...]
    or: setup.py --help-commands
    or: setup.py cmd --help

error: invalid command 'build_sphinx'

Any ideas?

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Sep  8 18:23:00 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 17:23:00 +0100
Subject: [Distutils] [buildout] trunk failures on Windows
Message-ID: <4AA684E4.2070809@simplistix.co.uk>

Hi All,

Thought I'd try and help Reinout van Rees out by running the tests on 
his branch on Windows, but found problems even when trying to run the 
tests on trunk:

- running dev.py failed on Windows, I've fixed this in r103647

- Even so, running dev.py with Python 2.6 on Windows pops up a dialog 
box saying "The application failed to initialize properly (0xc0150004). 
Click OK to terminate the application". That said, the script still 
seems to run fine. This doesn't happen with Python 2.5 or 2.4.

- There are test failures with Python 2.6 on Windows, I've attached the 
full run in windows.txt.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: windows.txt
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090908/9ea44de0/attachment-0001.txt>

From reinout at vanrees.org  Tue Sep  8 21:27:04 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 8 Sep 2009 19:27:04 +0000 (UTC)
Subject: [Distutils] what does zc.recipe.egg do with disutils scripts?
References: <4AA581A0.20105@simplistix.co.uk>
	<1099b90b0909071620t24cd1324r168e015f9530e670@mail.gmail.com>
	<slrnhac5vo.sof.reinout@isengrim.local>
	<4AA675AA.1040408@simplistix.co.uk>
Message-ID: <h86b68$p9a$1@ger.gmane.org>

On 2009-09-08, Chris Withers <chris at simplistix.co.uk> wrote:
> Reinout van Rees wrote:
>> 
>> Chris, you could try out the zc.buildout/branches/reinout-scripts branch.
>> I've fixed it there.
>
> How do I actually go about doing that?
>
> If I just put that checkout in the develop line of my buildout will get 
> picked?

zc.buildout has a special "dev.py" bootstrap for bootstrapping itself with a
development checkout of itself.  So you actually need to get the buildout
development checkout in bin/buildout's sys.path.  dev.py is a good example.

Bit of a pain for regular use, for sure :-)

Jim: OK for me to merge the branch back to trunk?


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From reinout at vanrees.org  Tue Sep  8 21:36:20 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 8 Sep 2009 19:36:20 +0000 (UTC)
Subject: [Distutils] [buildout[ How do I use stuff specified in the
	distutils.command entry_point?
References: <4AA6840D.3@simplistix.co.uk>
Message-ID: <h86bnk$p9a$2@ger.gmane.org>

On 2009-09-08, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> Sphinx, among others, provides command in this entry point.
>
> With this buildout:
>
> [buildout]
> parts = sphinx
>
> [sphinx]
> recipe = zc.recipe.egg
> eggs = sphinx
>
> And based on the entry points listed here:
>
> http://bitbucket.org/birkenfeld/sphinx/src/447109cf9b01/setup.py#cl-182
>
> I'd expect to be able to do:
>
> $ bin/buildout setup setup.py build_sphinx
>
> But I get:
>
> Running setup script 'setup.py'.
> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>     or: setup.py --help [cmd1 cmd2 ...]
>     or: setup.py --help-commands
>     or: setup.py cmd --help
>
> error: invalid command 'build_sphinx'
>
> Any ideas?

Yes: "bin/buildout setup setup.py something" tells buildout to run the
"something" command with the setup.py in the current directory. And that won't
be sphinx' setup.py.

Secondly: such an console_scripts entry point only tells setuptools (and
buildout) to install that script in the bin directory.  It is not an extra
setup.py command (like "sdist" and "build").  For that, you need a different
entry point.

When I just take your example buildout and run it, I get the expected result

$> bin/buildout
Installing sphinx.
Getting distribution for 'sphinx'.
Got Sphinx 0.6.3.
Generated script '/private/tmp/bbb/bin/sphinx-build'.
Generated script '/private/tmp/bbb/bin/sphinx-quickstart'.
Generated script '/private/tmp/bbb/bin/sphinx-autogen'.


So buildout installs the three defined console_scripts just fine in the bin/
directory.


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From reinout at vanrees.org  Tue Sep  8 21:40:21 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 8 Sep 2009 19:40:21 +0000 (UTC)
Subject: [Distutils] [buildout] trunk failures on Windows
References: <4AA684E4.2070809@simplistix.co.uk>
Message-ID: <h86bv5$p9a$3@ger.gmane.org>

On 2009-09-08, Chris Withers <chris at simplistix.co.uk> wrote:
>
> Thought I'd try and help Reinout van Rees out by running the tests on 
> his branch on Windows

:-) Thanks

> - There are test failures with Python 2.6 on Windows, I've attached the 
> full run in windows.txt.

I noticed two things:

- "unrecognized format in .svn/entries": that's subversion 1.6's new entries
  format that is unrecognized by setuptools 0.6rc9 ("All hail distutils as
  that fixed this bug")

- The "bin directory already exists" error that keeps coming up suggests an
  os.remove (or however that's called) in a teardown method that uses a
  non-windows-friendly path separator.  Just a pure guess :-)


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From floris.bruynooghe at gmail.com  Tue Sep  8 22:43:39 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 8 Sep 2009 21:43:39 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
References: <4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
Message-ID: <20090908204339.GA13513@laurie.devork>

On Tue, Sep 08, 2009 at 02:53:49PM +0200, Tarek Ziad? wrote:
> On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith<eric at trueblade.com> wrote:
> > Tarek Ziad? wrote:
> >>
> >> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<chris at simplistix.co.uk>
> >> wrote:
> >>>
> >>> Tarek Ziad? wrote:
> >>>>
> >>>> - an extra function called "long_description", to be able to point a
> >>>> file for the long description field
> >>>
> >>> I can't comment on the others, but this is unnecessary. Why do you need
> >>> more
> >>> than:
> >>>
> >>> long_decription="some lump of text"
> >>>
> >>> or
> >>>
> >>> long_description_path ="path/relative/to/directory/containing/setup.py"
> >>>
> >>> ...with it being an error for both to be specified?
> >>>
> >>> cheers,
> >>>
> >>
> >> The practice in the community is to create the long_description field
> >> using a separate reStructuredText file
> >> and reaching it in setup.py like this for example:
> >>
> >> long_description = open('README.txt').read()
> >>
> >> Having a callable that provides this feature in the template allows
> >> writing:
> >>
> >> """
> >> [setup.cfg]
> >>
> >> long_description: {$ long_description('README.txt') $}
> >> """
> >>
> >> Thus avoiding to write anything in setup.py for that particular case.
> >> the callable could be called "read_file()" maybe, so it's clearer.
> >>
> >> long_description_path can't be added in the final PKG-INFO because
> >> we want a self-contained metadata static file that doesn't require an
> >> extra resource (like an external file)
> >>
> >> Whereas having a file path in setup.cfg.in is acceptable, as long as
> >> the resulting setup.cfg
> >> contains everything needed to get the metadata of the package without
> >> further depenencies.
> >>
> >> so if by the time setup.cfg.in is compiled, the path cannot be found,
> >> the field will have its value set to "UNKOWN" in setup.cfg
> >
> > Which all points out that it's setup.cfg that is the static metadata, and
> > that you can generate it any way you want. If you want to use m4, use m4. If
> > you want to use python, use python. If you want to have some makefile driven
> > approach, or use autoconf, or whatever, do that.
> >
> > setup.cfg should be entirely static except for some simple if-then-else
> > logic involving versions, as Tarek has described earlier. That is, it should
> > only contain logic that needs to be decided on the platform where the
> > installation is taking place. This is basically what RPM provides.
> >
> > Any other logic, in particular logic used solely for building setup.cfg,
> > ?should be outside the scope of this system, because you can use any tool at
> > all for it.
> >
> 
> So you are suggesting that setup.cfg includes the "if/else" logic
> instead of having it
> in a "setup.cfg.in" file ?

I'm more in favour of your original idea to have setup.cfg being
completely static and have the if/else logic in setup.cfg.in.

Regards
Floris

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

From ziade.tarek at gmail.com  Tue Sep  8 23:20:29 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 23:20:29 +0200
Subject: [Distutils] Distribute 0.6.1 released
Message-ID: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>

Hello

I am happy to announce the release of Distribute 0.6.1.

Changes:

* zip_ok is now True by default.
* package_index.urlopen now catches BadStatusLine and malformed url errors.
* Fixed invalid URL error catching.
* Fixed invalid bootstraping with easy_install installation. Thanks to
Florian Shchulze for the help
* Removed buildout/bootstrap.py. A new repository at bitbucket.org
will create a specific bootstrap.py script.
* The bootstrap process leave setuptools alone if detected in the
system and --root, --user or --prefix is provided, but is not in the
same location.

The next release of the 0.6 series will try to adress all remaining
bugs in the tracker,

The first 0.7 release is still under heavy work.

Cheers
Tarek


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

From florian.schulze at gmx.net  Tue Sep  8 23:23:45 2009
From: florian.schulze at gmx.net (Florian Schulze)
Date: Tue, 08 Sep 2009 23:23:45 +0200
Subject: [Distutils] virtualenv-distribute 1.3.4dev-1 released
Message-ID: <op.uzyi1vznhjnvn3@news.gmane.org>

Hi!

I'm happy to announce the release of virtualenv-distribute 1.3.4dev-1,  
which is a fork of virtualenv which uses distribute 0.6.1 instead of  
setuptools.

Any feedback welcome.

Regards,
Florian Schulze


From ziade.tarek at gmail.com  Tue Sep  8 23:46:19 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Sep 2009 23:46:19 +0200
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
Message-ID: <94bdd2610909081446l37597e9cm9b88550ecfa87db6@mail.gmail.com>

On Tue, Sep 8, 2009 at 11:20 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> Hello
>
> I am happy to announce the release of Distribute 0.6.1.
>
> Changes:
>
> * zip_ok is now True by default.

I mean False of course ;)

From chris at simplistix.co.uk  Wed Sep  9 00:18:23 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 08 Sep 2009 23:18:23 +0100
Subject: [Distutils] virtualenv-distribute 1.3.4dev-1 released
In-Reply-To: <op.uzyi1vznhjnvn3@news.gmane.org>
References: <op.uzyi1vznhjnvn3@news.gmane.org>
Message-ID: <4AA6D82F.4070108@simplistix.co.uk>

Florian Schulze wrote:
> I'm happy to announce the release of virtualenv-distribute 1.3.4dev-1, 
> which is a fork of virtualenv which uses distribute 0.6.1 instead of 
> setuptools.

Wow, it's a shame this is needed. Did Ian just flat-out refuse to switch 
to distribute?

Chris

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

From david.lyon at preisshare.net  Wed Sep  9 01:01:09 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 08 Sep 2009 19:01:09 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
Message-ID: <04d68d8985d312f82af157e2547ef776@preisshare.net>

On Tue, 8 Sep 2009 14:20:30 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> The practice in the community is to create the long_description field
> using a separate reStructuredText file
> and reaching it in setup.py like this for example:
> 
> long_description = open('README.txt').read()
> 
> Having a callable that provides this feature in the template allows
> writing:
> 
> """
> [setup.cfg]
> 
> long_description: {$ long_description('README.txt') $}
> """

If the config file is actually a code file... (mixing config
with code)... what has been accomplished?

I was always led to believe that mixing static data with code was
bad programming practice. Have configuration files for configuration
and program files for programs.

Why have a static data file?

Why not go back to setup.py which was mixed data/code....?

David








From david.lyon at preisshare.net  Wed Sep  9 01:19:17 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 08 Sep 2009 19:19:17 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
Message-ID: <df6d14bc6f0bf0b621943a16a515da99@preisshare.net>

On Tue, 8 Sep 2009 10:26:19 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> I am restricting the template language to two expressions: "if" and
"else"
> 
> The values you can work with in the "if" and "else" section will be
> restricted to :
> 
> - the python version (string)
> - the os.name (string)
> - the os.platform (string)
> - an extra function called "long_description", to be able to point a
> file for the long description field
> 
> and nothing else.
> 
> How anyone could abuse of that kind of expressions ?

What about nested if statements?

Real world example, if os=="linux2" and window_manager=="kde": ..

elif os=="linux2" and window_manager=="gnome": ..

How would that be handled?

David


From ziade.tarek at gmail.com  Wed Sep  9 01:31:56 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 9 Sep 2009 01:31:56 +0200
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <0BFF1831-41E1-4E45-92EC-F3E51FFE79F7@underboss.org>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
	<0BFF1831-41E1-4E45-92EC-F3E51FFE79F7@underboss.org>
Message-ID: <94bdd2610909081631y4c4ceee0u2f5147035bcc02c3@mail.gmail.com>

On Wed, Sep 9, 2009 at 1:25 AM, Philip Jenvey<pjenvey at underboss.org> wrote:
>
> On Sep 8, 2009, at 2:20 PM, Tarek Ziad? wrote:
>
>> Hello
>>
>> I am happy to announce the release of Distribute 0.6.1.
>>
>
> Excellent!
>
> I've found one issue: distribute_setup.py uses 2.6's site.USER_SITE.

Right, I'll fix it right away and this can be applied in the
distribute_setup.py that is available online
(so virtualenv-distribute can be fixed as well)

Tarek

>
> --
> Philip Jenvey
>
>



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

From ziade.tarek at gmail.com  Wed Sep  9 01:42:21 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 9 Sep 2009 01:42:21 +0200
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <94bdd2610909081631y4c4ceee0u2f5147035bcc02c3@mail.gmail.com>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
	<0BFF1831-41E1-4E45-92EC-F3E51FFE79F7@underboss.org>
	<94bdd2610909081631y4c4ceee0u2f5147035bcc02c3@mail.gmail.com>
Message-ID: <94bdd2610909081642t77df8660u820a0806ce739877@mail.gmail.com>

On Wed, Sep 9, 2009 at 1:31 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Wed, Sep 9, 2009 at 1:25 AM, Philip Jenvey<pjenvey at underboss.org> wrote:
>>
>> On Sep 8, 2009, at 2:20 PM, Tarek Ziad? wrote:
>>
>>> Hello
>>>
>>> I am happy to announce the release of Distribute 0.6.1.
>>>
>>
>> Excellent!
>>
>> I've found one issue: distribute_setup.py uses 2.6's site.USER_SITE.
>
> Right, I'll fix it right away and this can be applied in the
> distribute_setup.py that is available online
> (so virtualenv-distribute can be fixed as well)
>

Done, Thx

It's time to add a test for a minimal coverage of all supported py
versions to avoid this problem again

http://bitbucket.org/tarek/distribute/issue/42


> Tarek
>
>>
>> --
>> Philip Jenvey
>>
>>
>
>
>
> --
> Tarek Ziad? | http://ziade.org |???????????
>



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

From ben+python at benfinney.id.au  Wed Sep  9 01:56:53 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 09 Sep 2009 09:56:53 +1000
Subject: [Distutils] Configuration via imperative or declarative language
	(was: Static metadata using setup.cfg)
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
Message-ID: <87tyzd0z3u.fsf_-_@benfinney.id.au>

Eric Smith <eric at trueblade.com> writes:

> setup.cfg should be entirely static except for some simple
> if-then-else logic involving versions, as Tarek has described earlier.
> That is, it should only contain logic that needs to be decided on the
> platform where the installation is taking place. This is basically
> what RPM provides.

Floris Bruynooghe <floris.bruynooghe at gmail.com> writes:

> I'm more in favour of your original idea to have setup.cfg being
> completely static and have the if/else logic in setup.cfg.in.

A word on terminology here: The distinction being drawn isn't anything
to do with ?static? (since even a ?foo.py? file is static, i.e. the file
doesn't change).

Instead, the distinction is whether or not ?setup.cfg? should be purely
declarative <URL:http://en.wikipedia.org/wiki/Declarative_programming>.
That is, whether it should:

* specify ?what?, not ?how?
* have no side-effects when used

The metadata being discussed is static. What's at issue is how that
metadata should be encoded: in an imperative language (like a Python
program file) or a declarative language (like a ConfigParser file).

-- 
 \     ?Creativity can be a social contribution, but only in so far as |
  `\            society is free to use the results.? ?Richard Stallman |
_o__)                                                                  |
Ben Finney


From greg.ewing at canterbury.ac.nz  Wed Sep  9 02:24:59 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 09 Sep 2009 12:24:59 +1200
Subject: [Distutils] Configuration via imperative or declarative
 language (was: Static metadata using setup.cfg)
In-Reply-To: <87tyzd0z3u.fsf_-_@benfinney.id.au>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com> <87tyzd0z3u.fsf_-_@benfinney.id.au>
Message-ID: <4AA6F5DB.3010806@canterbury.ac.nz>

Ben Finney wrote:

> The metadata being discussed is static. What's at issue is how that
> metadata should be encoded: in an imperative language (like a Python
> program file) or a declarative language (like a ConfigParser file).

I'm not sure that exactly expresses the distinction either.
Depending on exactly what you understand by "declarative",
a program writtenin a functional language can be considered
purely declarative, yet it can be impossible to tell what it
will do without running it.

I think what people mean here by "static" is more like
"can be elaborated without requiring non-trivial amounts of
computation". Not just to minimise the amount of work a
tool using the config file needs to do, but also to ease
the task of debugging it when things don't work properly.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Wed Sep  9 01:31:42 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 09 Sep 2009 11:31:42 +1200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
Message-ID: <4AA6E95E.9000003@canterbury.ac.nz>

Tarek Ziad? wrote:

> In that case, if we want to keep a configparser-compatible file, we
> need to find another
> way to express these if/else parts, which will probably lead to a
> complex, non natural
> syntax.

Maybe the conditions could be expressed in the
section headers?

[requires platform="linux"]
...

[requires platform="win32"]:
...

Then it's not so much if-then-else logic as just
tagging parts of the file with conditions under
which they apply.

-- 
Greg

From david.lyon at preisshare.net  Wed Sep  9 06:28:48 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 09 Sep 2009 00:28:48 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA6E95E.9000003@canterbury.ac.nz>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
	<4AA6E95E.9000003@canterbury.ac.nz>
Message-ID: <0e1c9aa712cdf1a846d763a65d7d404a@preisshare.net>

On Wed, 09 Sep 2009 11:31:42 +1200, Greg Ewing
<greg.ewing at canterbury.ac.nz>
wrote:
> Maybe the conditions could be expressed in the
> section headers?
> 
> [requires platform="linux"]
> ...
> 
> [requires platform="win32"]:
> ...
> 
> Then it's not so much if-then-else logic as just
> tagging parts of the file with conditions under
> which they apply.

+1

or just..

[requires linux2]
...

[requires win32]:
...

[requires kde]
...

[requires gnome]
...


[requires darwin]
...

David


From ziade.tarek at gmail.com  Wed Sep  9 09:32:53 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 9 Sep 2009 09:32:53 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA6E95E.9000003@canterbury.ac.nz>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
	<4AA6E95E.9000003@canterbury.ac.nz>
Message-ID: <94bdd2610909090032s2ffbb740pfcd66bc60a231dca@mail.gmail.com>

On Wed, Sep 9, 2009 at 1:31 AM, Greg Ewing<greg.ewing at canterbury.ac.nz> wrote:
> Tarek Ziad? wrote:
>
>> In that case, if we want to keep a configparser-compatible file, we
>> need to find another
>> way to express these if/else parts, which will probably lead to a
>> complex, non natural
>> syntax.
>
> Maybe the conditions could be expressed in the
> section headers?
>
> [requires platform="linux"]
> ...
>
> [requires platform="win32"]:
> ...
>
> Then it's not so much if-then-else logic as just
> tagging parts of the file with conditions under
> which they apply.

The problem is that we need more complex conditions like:
"platform == linux and python >= 2.5"

in that case, the ConfigParser format is making it hard to do it
like you've described, unless the section is the full expression :

[requires platform="linux" and python >="2.5"]

Notice that this *does* work with ConfigParser but you can't express
'else' conditions easily. But this is not a great deal, I can accomodate not
having elses.

Maybe the expression can be located in a specific variable for readability:

"""
[setup]
name = foo
conditional-sections = one, two

[one]
condition: platform="linux" and python >= "2.5"
require: lxml

[two]
condition: platform="win32" and python >= "2.5"
require: docutils
"""

This would be more powerfull since each section could define any metadata,
under some conditions.

I would be ok with that shape, even if I do find this more readable:

"""
[setup]
name = foo

{$ if platform="linux" and python >= "2.5": $}
require: lxml
{$ :endif $}

{$ platform="win32" and python >= "2.5": $)
require: docutils
{$ :endif $}
"""

In any case, the restrictions to what variables the expressions can
work with would stay the same.

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



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

From chris at simplistix.co.uk  Wed Sep  9 10:21:39 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 09 Sep 2009 09:21:39 +0100
Subject: [Distutils] [buildout] How do I use stuff specified in
 the	distutils.command entry_point?
In-Reply-To: <h86bnk$p9a$2@ger.gmane.org>
References: <4AA6840D.3@simplistix.co.uk> <h86bnk$p9a$2@ger.gmane.org>
Message-ID: <4AA76593.3090706@simplistix.co.uk>

Hi Reinout,

I'm afraid you're getting confused...

Reinout van Rees wrote:
>> And based on the entry points listed here:
>>
>> http://bitbucket.org/birkenfeld/sphinx/src/447109cf9b01/setup.py#cl-182

I'm referring to the distutils.commands entry point in the above *not* 
console_scripts.

> Yes: "bin/buildout setup setup.py something" tells buildout to run the
> "something" command with the setup.py in the current directory. And that won't
> be sphinx' setup.py.

It doesn't need to be Sphinx's setup.py, distutils.commands, as an entry 
point, adds commands to disutuils (eg: bdist_egg, etc)

> Secondly: such an console_scripts entry point only tells setuptools (and
> buildout) to install that script in the bin directory.  It is not an extra
> setup.py command (like "sdist" and "build").  For that, you need a different
> entry point.

Yes, the distutils.commands entry point, which defines build_sphinx 
*not* sphinx_build ;-)

The problem is that bin/buildout only has zc.buildout and setuptools 
available as eggs, so "bin/buildout setup setup.py" seems a bit limited 
to me :-S

I found a workaround, which was to define an interpreter in my [sphinx] 
section and then do:

bin/py setup.py build_sphinx

...but that just felt a bit wrong :-S

Can anyone tell me what the *right* way is to get this to work?

cheers,

Chris

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

From chris at simplistix.co.uk  Wed Sep  9 11:29:55 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 09 Sep 2009 10:29:55 +0100
Subject: [Distutils] uses for setup.cfg and extracting data from it
Message-ID: <4AA77593.9010809@simplistix.co.uk>

Hi All,

Do people generally source control their package's setup.cfg?

http://docs.python.org/distutils/configfile.html sort of implies it 
should be editable by the person installing the package, but I've never 
personally used a package where that's the case...

Assuming the distutils docs are out of date and this file is really 
"owned" by the package maintainer, how do I extract information from it 
in setup.py (and elsewhere for that matter!)

I'm looking for somewhere consistent to store the following for all my 
packages:

- mailing lists url

- issue tracker url

- change log url

- documentation url

...such that I can generate a sensible long_description for use on PyPI 
but also such that I can include the information in the Sphinx docs...

cheers,

Chris

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

From pjenvey at underboss.org  Wed Sep  9 01:25:18 2009
From: pjenvey at underboss.org (Philip Jenvey)
Date: Tue, 8 Sep 2009 16:25:18 -0700
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
Message-ID: <0BFF1831-41E1-4E45-92EC-F3E51FFE79F7@underboss.org>


On Sep 8, 2009, at 2:20 PM, Tarek Ziad? wrote:

> Hello
>
> I am happy to announce the release of Distribute 0.6.1.
>

Excellent!

I've found one issue: distribute_setup.py uses 2.6's site.USER_SITE.

--
Philip Jenvey


From reinout at vanrees.org  Wed Sep  9 12:40:42 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 9 Sep 2009 10:40:42 +0000 (UTC)
Subject: [Distutils] [buildout] How do I use stuff specified in
	the	distutils.command entry_point?
References: <4AA6840D.3@simplistix.co.uk> <h86bnk$p9a$2@ger.gmane.org>
	<4AA76593.3090706@simplistix.co.uk>
Message-ID: <slrnhaf1ha.1aj.reinout@isengrim.local>

On 2009-09-09, Chris Withers <chris at simplistix.co.uk> wrote:
>
> I'm afraid you're getting confused...

You're right :-)

> Reinout van Rees wrote:
>>> And based on the entry points listed here:
>>>
>>> http://bitbucket.org/birkenfeld/sphinx/src/447109cf9b01/setup.py#cl-182
>
> I'm referring to the distutils.commands entry point in the above *not* 
> console_scripts.

Missed that one.

> The problem is that bin/buildout only has zc.buildout and setuptools 
> available as eggs, so "bin/buildout setup setup.py" seems a bit limited 
> to me :-S
>
> I found a workaround, which was to define an interpreter in my [sphinx] 
> section and then do:
>
> bin/py setup.py build_sphinx
>
> ...but that just felt a bit wrong :-S
>
> Can anyone tell me what the *right* way is to get this to work?

>From what I've seen, your workaround is the right way to do it.  The one item
that struck me is that not even the recipe eggs end up on bin/buildout's
sys.path.  So buildout is about setting stuff up in the right way so that
subsequent commands can run OK.

Until you talked about it, I never encountered "bin/buildout setup setup.py",
so I wonder how common it is.  It also means I should probably shut up about
it to prevent saying dumb things :-)


Btw: there is a recipe for setting up a sphinx area in your buildout:
http://pypi.python.org/pypi/collective.recipe.sphinxbuilder/0.6.3

Personally I use it just once to create a directory structure in my buildout.
Afterwards I store the results in svn and rip out
collective.recipe.sphinxbuilder again to allow me to edit config files
directly instead of having them generated.


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ben+python at benfinney.id.au  Wed Sep  9 15:25:46 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 09 Sep 2009 23:25:46 +1000
Subject: [Distutils] uses for setup.cfg and extracting data from it
References: <4AA77593.9010809@simplistix.co.uk>
Message-ID: <878wgo1c85.fsf@benfinney.id.au>

Chris Withers <chris at simplistix.co.uk> writes:

> Do people generally source control their package's setup.cfg?

Yes. I prefer the distribution metadata to be declarative, for the
reasons you touch on later in your message. So where it makes sense I
store it in ?setup.cfg? or some other declarative file, and put it under
VCS like any other file needed for generating the distribution.

> http://docs.python.org/distutils/configfile.html sort of implies it
> should be editable by the person installing the package

Yes, that's part of its purpose: to allow customisation of the various
actions of distutils.

> but I've never personally used a package where that's the case...

I don't understand. When you, as the person installing the distribution,
get the sdist for that distribution, you can edit (or create, if it
didn't exist) the ?setup.cfg?. What's stopping you from doing so?

> Assuming the distutils docs are out of date and this file is really
> "owned" by the package maintainer

If the distribution maintainer generates and distributes sdist files,
then they can ?own? the ?setup.cfg? file without hindering the
recipient's customisation of the same file at installation time.

> how do I extract information from it in setup.py (and elsewhere for
> that matter!)

That's one of the pain points of the current distutils capability:
there's no standard-library way to extract that information. Various
efforts are under way to try to change that, but the legacy of existing
distributions is heavy and long.

You'll probably be interested in the discussions currently ongoing in
the Distutils SIG, regarding how to get the distribution metadata so
it's stored declaratively to make it easier to extract.

-- 
 \         ?I have yet to see any problem, however complicated, which, |
  `\      when you looked at it in the right way, did not become still |
_o__)                                more complicated.? ?Paul Anderson |
Ben Finney


From pje at telecommunity.com  Wed Sep  9 16:31:48 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 09 Sep 2009 10:31:48 -0400
Subject: [Distutils] uses for setup.cfg and extracting data from it
In-Reply-To: <878wgo1c85.fsf@benfinney.id.au>
References: <4AA77593.9010809@simplistix.co.uk>
	<878wgo1c85.fsf@benfinney.id.au>
Message-ID: <20090909143159.426783A403D@sparrow.telecommunity.com>

At 11:25 PM 9/9/2009 +1000, Ben Finney wrote:
>That's one of the pain points of the current distutils capability: 
>there's no standard-library way to extract that information.

If you're talking about setup.cfg (and all the other distutils .cfg 
files), all you need to do is create a Distribution object and call 
parse_config_files() on it, then access the appropriate 
attributes.  Take you maybe 3 or 4 lines of code.

If you're talking about setup.py, all you need to do is use the 
distutils functions that allow you to run a setup.py without 
executing any of its commands.  (Of course, you then need to be able 
to deal with badly-behaved setup scripts, and it's true there's no 
stdlib support for that.)


From ndbecker2 at gmail.com  Wed Sep  9 16:45:30 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 09 Sep 2009 10:45:30 -0400
Subject: [Distutils] Distribute 0.6.1 released
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
Message-ID: <h88f2a$jls$2@ger.gmane.org>

Tarek Ziad? wrote:

> Hello
> 
> I am happy to announce the release of Distribute 0.6.1.
> 
> Changes:
> 
> * zip_ok is now True by default.
> * package_index.urlopen now catches BadStatusLine and malformed url
> errors. * Fixed invalid URL error catching.
> * Fixed invalid bootstraping with easy_install installation. Thanks to
> Florian Shchulze for the help
> * Removed buildout/bootstrap.py. A new repository at bitbucket.org
> will create a specific bootstrap.py script.
> * The bootstrap process leave setuptools alone if detected in the
> system and --root, --user or --prefix is provided, but is not in the
> same location.
> 
> The next release of the 0.6 series will try to adress all remaining
> bugs in the tracker,
> 
> The first 0.7 release is still under heavy work.
> 
Is there some summary of advantages of distribute compared to setuptools?


From ziade.tarek at gmail.com  Wed Sep  9 17:36:07 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 9 Sep 2009 17:36:07 +0200
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <h88f2a$jls$2@ger.gmane.org>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
	<h88f2a$jls$2@ger.gmane.org>
Message-ID: <94bdd2610909090836p2d032a70q74ea3d6b3bebe9ef@mail.gmail.com>

On Wed, Sep 9, 2009 at 4:45 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
>>
> Is there some summary of advantages of distribute compared to setuptools?

For 0.6.x series, the only advantage is that we are fixing all the
bugs that were added in setuptools issue
tracker since a year or so (plus some other fixes and enhancement)

* See: http://bitbucket.org/tarek/distribute/wiki/bug_listing
* and the changeset file since 0.6.1

For the upcoming 0.7.x series:

* py3k support (maybe this will be also added in 0.6.3)
* splitting of the code in smaller logical distributions.

Regards
Tarek

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

From hanno at hannosch.eu  Wed Sep  9 17:41:06 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Wed, 9 Sep 2009 17:41:06 +0200
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <h88f2a$jls$2@ger.gmane.org>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
	<h88f2a$jls$2@ger.gmane.org>
Message-ID: <5cae42b20909090841v7a1d06fp13f5030289946a28@mail.gmail.com>

On Wed, Sep 9, 2009 at 4:45 PM, Neal Becker<ndbecker2 at gmail.com> wrote:
> Is there some summary of advantages of distribute compared to setuptools?

The changelog entries as found at
http://pypi.python.org/pypi/distribute#changes should be a good start.

The Distribute 0.6 series is essentially setuptools with more bugs fixed.

One process related advantage distribute has over setuptools is, that
you can actually contribute patches and code to the project and get
those released after a reasonable time. We welcome contributors to the
project :-)

Hanno

From theller at ctypes.org  Wed Sep  9 20:26:09 2009
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 09 Sep 2009 20:26:09 +0200
Subject: [Distutils] pkgutil.extend_path and .pkg files
Message-ID: <h88s00$7nv$1@ger.gmane.org>

pkgutil is somehow connected to setuptools, so I assume this
is the right place to ask this question.

I'm exploring pkgutil.extend_path(), together with a pkg-file
somewhere on my PYTHONPATH.

I am wondering if it is somehow possible to interpret relative
pathnames in the pkg-file relative to the directory which
contains the pkg-file?

-- 
Thanks,
Thomas


From floris.bruynooghe at gmail.com  Thu Sep 10 01:10:23 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Thu, 10 Sep 2009 00:10:23 +0100
Subject: [Distutils] pkgutil.extend_path and .pkg files
In-Reply-To: <h88s00$7nv$1@ger.gmane.org>
References: <h88s00$7nv$1@ger.gmane.org>
Message-ID: <20090909231023.GA8103@laurie.devork>

On Wed, Sep 09, 2009 at 08:26:09PM +0200, Thomas Heller wrote:
> I'm exploring pkgutil.extend_path(), together with a pkg-file
> somewhere on my PYTHONPATH.
> 
> I am wondering if it is somehow possible to interpret relative
> pathnames in the pkg-file relative to the directory which
> contains the pkg-file?

That's how site.addsitedir() works, and pkgutil.extend_path() claims
to have the same behaviour for .pth files (with noted non-applicable
exception) so if it doesn't then I guess it would be a bug.

Regards
Floris

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

From greg.ewing at canterbury.ac.nz  Thu Sep 10 01:58:39 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 10 Sep 2009 11:58:39 +1200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>
	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
Message-ID: <4AA8412F.2030801@canterbury.ac.nz>

Tarek Ziad? wrote:

> long_description: {$ long_description('README.txt') $}

A couple of thoughts:

1. Is there anything about this function that would
restrict it's use to the long_description field, or
could it be called something more general like
"from_file" and used in other contexts?

2. I'm against any syntax in the setup.cfg file that
resembles line noise (as the {$ $} does to my eyes).

-- 
Greg

From greg.ewing at canterbury.ac.nz  Thu Sep 10 02:07:30 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 10 Sep 2009 12:07:30 +1200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <0e1c9aa712cdf1a846d763a65d7d404a@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
	<4AA6E95E.9000003@canterbury.ac.nz>
	<0e1c9aa712cdf1a846d763a65d7d404a@preisshare.net>
Message-ID: <4AA84342.7070702@canterbury.ac.nz>

David Lyon wrote:

> or just..
> 
> [requires linux2]
> ...
> 
> [requires win32]:
> ...

Perhaps, if the sets of "tokens" used in the various fields
one might be interested in are disjoint. It would require
more intelligence from tools processing the data, though,
and might be harder to extend to accommodate future
requirements. Explicit might be better than implicit here.

-- 
Greg

From david.lyon at preisshare.net  Thu Sep 10 02:23:26 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 09 Sep 2009 20:23:26 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA84342.7070702@canterbury.ac.nz>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
	<4AA6E95E.9000003@canterbury.ac.nz>
	<0e1c9aa712cdf1a846d763a65d7d404a@preisshare.net>
	<4AA84342.7070702@canterbury.ac.nz>
Message-ID: <c73f54ad1d6aef0c3e345c5b1901e938@preisshare.net>

On Thu, 10 Sep 2009 12:07:30 +1200, Greg Ewing
<greg.ewing at canterbury.ac.nz>
wrote:
>> or just..
>> 
>> [requires linux2]
>> ...
>> 
>> [requires win32]:
>> ...
> 
> Perhaps, if the sets of "tokens" used in the various fields
> one might be interested in are disjoint. It would require
> more intelligence from tools processing the data, though,
> and might be harder to extend to accommodate future
> requirements. Explicit might be better than implicit here.

It was a quick hack...

Usually when installing, different platforms require special
tweeking. What I mean is that on say (weird) platform Z for
some reason some basic thing that is on every other platform
isn't on it.

So what I mean is:

"""
[setup]
name=mywebframework
version=1.5

[dependencies]
packages = mywebtemplates >= 1.5
    objectmapper >= 2.1

[dependencies linux2]
packages = pyopenssl > 1.0
    pyodbc >= 1.5

[dependencies win32]
packages = win32com >= 1.1
"""

So, what this means is that mywebframework always requires
mywebtemplates, but when it is running on linux it needs
pyopenssl, and when it is on win32 it requires win32com.

On win32, there is odbc built in. On linux there is not.

This is a fairly real world example of having different
dependencies on different platforms.

David




From david.lyon at preisshare.net  Thu Sep 10 03:26:15 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 09 Sep 2009 21:26:15 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AA84342.7070702@canterbury.ac.nz>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AA64EC2.1050202@trueblade.com>
	<94bdd2610909080553t121e3e81qbcd3983a4e67bfa8@mail.gmail.com>
	<4AA6E95E.9000003@canterbury.ac.nz>
	<0e1c9aa712cdf1a846d763a65d7d404a@preisshare.net>
	<4AA84342.7070702@canterbury.ac.nz>
Message-ID: <e97d7cfd2a71010bf2b60b00795c5156@preisshare.net>

On Thu, 10 Sep 2009 12:07:30 +1200, Greg Ewing
<greg.ewing at canterbury.ac.nz>
wrote:
> David Lyon wrote:
> 
>> or just..
>> 
>> [requires linux2]
>> ...
>> 
>> [requires win32]:
>> ...
> 
> Perhaps, if the sets of "tokens" used in the various fields
> one might be interested in are disjoint. It would require
> more intelligence from tools processing the data, though,
> and might be harder to extend to accommodate future
> requirements. Explicit might be better than implicit here.

Another example, 

instead of say:
"""
${if python_version < '2.5':}$
install_requires: jsonlib
${:else:}$
install_requires: lxml
${:endif}$
"""

something like this:

"""
[setup]
name = mywebframework
version = 1.5

[python_version < '2.5']
install_requires = jasonlib

[python_version >= '2.5']
install_requires = lxml

"""

David






From chris at simplistix.co.uk  Thu Sep 10 11:34:36 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 10 Sep 2009 10:34:36 +0100
Subject: [Distutils] collective.recipe.sphinxbuilder
In-Reply-To: <slrnhaf1ha.1aj.reinout@isengrim.local>
References: <4AA6840D.3@simplistix.co.uk>
	<h86bnk$p9a$2@ger.gmane.org>	<4AA76593.3090706@simplistix.co.uk>
	<slrnhaf1ha.1aj.reinout@isengrim.local>
Message-ID: <4AA8C82C.7070801@simplistix.co.uk>

Reinout van Rees wrote:
> Personally I use it just once to create a directory structure in my buildout.
> Afterwards I store the results in svn and rip out
> collective.recipe.sphinxbuilder again to allow me to edit config files
> directly instead of having them generated.

Interesting, I'm actually looking at it currently for its packaging of 
the sphinx-build console script in a buildout-friendly fashion...

cheers,

Chris

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

From chris at simplistix.co.uk  Thu Sep 10 15:05:37 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 10 Sep 2009 14:05:37 +0100
Subject: [Distutils] problem with
	http://nightly.ziade.org/distribute_setup.py
In-Reply-To: <94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>
References: <4AA8DEC9.8000506@simplistix.co.uk>
	<94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>
Message-ID: <4AA8F9A1.6060406@simplistix.co.uk>

Tarek Ziad? wrote:
> we have dropped the releases of egg format in 0.6.1 for various reasons, 

Huh? Where are these reasons documented?

> and
> the use_setuptools function cannot work anymore because it is exclusively using
> binary eggs and their ability to be used in sys.path as-is with zero
> installation.

So much for drop-in compatibility with setuptools :-(

> Florian Schulze and I started another repo to create a new bootstrap.py
> that will bootstrap a zc.buildout environment using Distribute.
> 
> http://bitbucket.org/tarek/buildout-distribute/

How about working on the buildout branch I'm working on rather than 
doing stuff separately all the time?

Chris

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

From ziade.tarek at gmail.com  Thu Sep 10 15:13:48 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 10 Sep 2009 15:13:48 +0200
Subject: [Distutils] problem with
	http://nightly.ziade.org/distribute_setup.py
In-Reply-To: <4AA8F9A1.6060406@simplistix.co.uk>
References: <4AA8DEC9.8000506@simplistix.co.uk>
	<94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>
	<4AA8F9A1.6060406@simplistix.co.uk>
Message-ID: <94bdd2610909100613h4000320cq9cf0846f240d3c00@mail.gmail.com>

On Thu, Sep 10, 2009 at 3:05 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> we have dropped the releases of egg format in 0.6.1 for various reasons,
>
> Huh? Where are these reasons documented?

Because besides zc.buildout bootstraping, the distribute_setup.py is not be
considered as part of the code API.

>
>> and
>> the use_setuptools function cannot work anymore because it is exclusively
>> using
>> binary eggs and their ability to be used in sys.path as-is with zero
>> installation.
>
> So much for drop-in compatibility with setuptools :-(

This is not a compatibility issue. The code stays unchanged. This is just
a change in the way we release this project: no more binary releases
in bdist_egg format
that is.  Just a plain source release.

The ability to create an egg still exists, nothing has changed.

>
>> Florian Schulze and I started another repo to create a new bootstrap.py
>> that will bootstrap a zc.buildout environment using Distribute.
>>
>> http://bitbucket.org/tarek/buildout-distribute/
>
> How about working on the buildout branch I'm working on rather than doing
> stuff separately all the time?

Because it's not the zc.buildout project. It's a project that creates
a zc.buildout
environment using distribute, like what virtualenv-distribute does with
virtualenv.


n.b. :
Please, when you send a private mail, do not send the replies in the
mailing list
like that. It's confusing for people that try to follow the threads.
The best way
is to send all your requests to distutils-SIG, thx.


Tarek

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

From chris at simplistix.co.uk  Thu Sep 10 15:17:38 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 10 Sep 2009 14:17:38 +0100
Subject: [Distutils] problem with
	http://nightly.ziade.org/distribute_setup.py
In-Reply-To: <94bdd2610909100613h4000320cq9cf0846f240d3c00@mail.gmail.com>
References: <4AA8DEC9.8000506@simplistix.co.uk>	
	<94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>	
	<4AA8F9A1.6060406@simplistix.co.uk>
	<94bdd2610909100613h4000320cq9cf0846f240d3c00@mail.gmail.com>
Message-ID: <4AA8FC72.7060901@simplistix.co.uk>

Tarek Ziad? wrote:
> On Thu, Sep 10, 2009 at 3:05 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>> Tarek Ziad? wrote:
>>> we have dropped the releases of egg format in 0.6.1 for various reasons,
>> Huh? Where are these reasons documented?
> 
> Because besides zc.buildout bootstraping, the distribute_setup.py is not be
> considered as part of the code API.

What does that have to do with egg format releases of the 0.6 branch?

> This is not a compatibility issue. The code stays unchanged. This is just
> a change in the way we release this project: no more binary releases
> in bdist_egg format
> that is.  Just a plain source release.

Setuptools is available as an egg, so if you want 100% backwards 
compatability, then distribute needs to be too...

>>> http://bitbucket.org/tarek/buildout-distribute/
>> How about working on the buildout branch I'm working on rather than doing
>> stuff separately all the time?
> 
> Because it's not the zc.buildout project. It's a project that creates
> a zc.buildout
> environment using distribute, like what virtualenv-distribute does with
> virtualenv.

*sigh*

How many forks of how many projects do you want?

Chris

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

From ziade.tarek at gmail.com  Thu Sep 10 15:27:22 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 10 Sep 2009 15:27:22 +0200
Subject: [Distutils] problem with
	http://nightly.ziade.org/distribute_setup.py
In-Reply-To: <4AA8FC72.7060901@simplistix.co.uk>
References: <4AA8DEC9.8000506@simplistix.co.uk>
	<94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>
	<4AA8F9A1.6060406@simplistix.co.uk>
	<94bdd2610909100613h4000320cq9cf0846f240d3c00@mail.gmail.com>
	<4AA8FC72.7060901@simplistix.co.uk>
Message-ID: <94bdd2610909100627q6363f41agb38c7d7f34768585@mail.gmail.com>

On Thu, Sep 10, 2009 at 3:17 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>>
>> Because it's not the zc.buildout project. It's a project that creates
>> a zc.buildout
>> environment using distribute, like what virtualenv-distribute does with
>> virtualenv.
>
> *sigh*
>
> How many forks of how many projects do you want?

I am not forking anything. I don't plan to integrate Distribute in zc.buildout
right now.

As Jim said, and as I repeated, the only thing that could be possibly done in
zc.buildout is to make it compatible with any pre-requested distribution
(distribute/setuptools/etc).

I am just going to provide a script to make it easier for people to set up
distribute in a zc.buildout project.

That's just a bootstrap script....

From chris at simplistix.co.uk  Thu Sep 10 15:29:39 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 10 Sep 2009 14:29:39 +0100
Subject: [Distutils] problem with
	http://nightly.ziade.org/distribute_setup.py
In-Reply-To: <94bdd2610909100627q6363f41agb38c7d7f34768585@mail.gmail.com>
References: <4AA8DEC9.8000506@simplistix.co.uk>	
	<94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>	
	<4AA8F9A1.6060406@simplistix.co.uk>	
	<94bdd2610909100613h4000320cq9cf0846f240d3c00@mail.gmail.com>	
	<4AA8FC72.7060901@simplistix.co.uk>
	<94bdd2610909100627q6363f41agb38c7d7f34768585@mail.gmail.com>
Message-ID: <4AA8FF43.9080001@simplistix.co.uk>

Tarek Ziad? wrote:
>> How many forks of how many projects do you want?
> 
> I am not forking anything. I don't plan to integrate Distribute in zc.buildout
> right now.

Right, so people have to use a special bootstrap.py to get distribute?
That bootstrap.py will diverge from the one in buildout at some point 
causing problems.

> As Jim said, and as I repeated, the only thing that could be possibly done in
> zc.buildout is to make it compatible with any pre-requested distribution
> (distribute/setuptools/etc).

Huh? The branch I have is all but complete... Well, it was until you 
pulled the rug out from underneath me by not sticking to the backwards 
compatibility you promised...

Chris

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

From ziade.tarek at gmail.com  Thu Sep 10 15:37:43 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 10 Sep 2009 15:37:43 +0200
Subject: [Distutils] problem with
	http://nightly.ziade.org/distribute_setup.py
In-Reply-To: <4AA8FF43.9080001@simplistix.co.uk>
References: <4AA8DEC9.8000506@simplistix.co.uk>
	<94bdd2610909100603i5d8385e1i81eb87c214f75d73@mail.gmail.com>
	<4AA8F9A1.6060406@simplistix.co.uk>
	<94bdd2610909100613h4000320cq9cf0846f240d3c00@mail.gmail.com>
	<4AA8FC72.7060901@simplistix.co.uk>
	<94bdd2610909100627q6363f41agb38c7d7f34768585@mail.gmail.com>
	<4AA8FF43.9080001@simplistix.co.uk>
Message-ID: <94bdd2610909100637g4488e85bq8e6229310d30f410@mail.gmail.com>

On Thu, Sep 10, 2009 at 3:29 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>>
>>> How many forks of how many projects do you want?
>>
>> I am not forking anything. I don't plan to integrate Distribute in
>> zc.buildout
>> right now.
>
> Right, so people have to use a special bootstrap.py to get distribute?
> That bootstrap.py will diverge from the one in buildout at some point
> causing problems.

What problem ?

If you want a zc.buildout with Distribute, install Distribute after
your regular
bootstrap and you have it.


>
>> As Jim said, and as I repeated, the only thing that could be possibly done
>> in
>> zc.buildout is to make it compatible with any pre-requested distribution
>> (distribute/setuptools/etc).
>
> Huh? The branch I have is all but complete... Well, it was until you pulled
> the rug out from underneath me by not sticking to the backwards
> compatibility you promised...

Sure, I made an error by changing this script like that. I am going to
reintroduce this function so you can run it.

You can use the 0.6 script until 0.6.3 is out.


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



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

From chris at simplistix.co.uk  Fri Sep 11 11:53:05 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 10:53:05 +0100
Subject: [Distutils] distutils' sdist won't allow me to include a file
 called buildout.cfg in my source distribution
Message-ID: <4AAA1E01.605@simplistix.co.uk>

...which is kinda annoying :-(

The problem is, in Python 2.6.2, line 357 of sdist.py.

This ends up applying the following:

exclude_pattern: applying regex r'^build\.*'

...which of course chomps buildout.cfg, with no possibility to add it 
back in MANIFEST.in :-(

Where does the bug lie and should I submit a bug tracker issue?

cheers,

Chris

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

From ziade.tarek at gmail.com  Fri Sep 11 11:58:06 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 11:58:06 +0200
Subject: [Distutils] distutils' sdist won't allow me to include a file
	called buildout.cfg in my source distribution
In-Reply-To: <4AAA1E01.605@simplistix.co.uk>
References: <4AAA1E01.605@simplistix.co.uk>
Message-ID: <94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>

On Fri, Sep 11, 2009 at 11:53 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> ...which is kinda annoying :-(
>
> The problem is, in Python 2.6.2, line 357 of sdist.py.
>
> This ends up applying the following:
>
> exclude_pattern: applying regex r'^build\.*'
>
> ...which of course chomps buildout.cfg, with no possibility to add it back
> in MANIFEST.in :-(

You can disable the prune option with --no-prune

you can also uset the the MANIFEST.in template file to define
what's in your distribution.

That's for distutils. Beware that if you use Subversion and setuptools,
it doesn't work the same way depending on what you've included
in your repo, but at the end MANIFEST.in has the last word if you use it.

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

From ziade.tarek at gmail.com  Fri Sep 11 12:01:19 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 12:01:19 +0200
Subject: [Distutils] distutils' sdist won't allow me to include a file
	called buildout.cfg in my source distribution
In-Reply-To: <94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
References: <4AAA1E01.605@simplistix.co.uk>
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
Message-ID: <94bdd2610909110301i746346dbn73200921362534f9@mail.gmail.com>

On Fri, Sep 11, 2009 at 11:58 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Sep 11, 2009 at 11:53 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> ...which is kinda annoying :-(
>>
>> The problem is, in Python 2.6.2, line 357 of sdist.py.
>>
>> This ends up applying the following:
>>
>> exclude_pattern: applying regex r'^build\.*'
>>
>> ...which of course chomps buildout.cfg, with no possibility to add it back
>> in MANIFEST.in :-(
>
> You can disable the prune option with --no-prune
>
> you can also uset the the MANIFEST.in template file to define
> what's in your distribution.
>

Let me add an example :

"""
include buildout.cfg
include README.txt
recursive-include src *.py
"""

From chris at simplistix.co.uk  Fri Sep 11 12:02:50 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 11:02:50 +0100
Subject: [Distutils] distutils' sdist won't allow me to include a file
 called buildout.cfg in my source distribution
In-Reply-To: <94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
References: <4AAA1E01.605@simplistix.co.uk>
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
Message-ID: <4AAA204A.5010706@simplistix.co.uk>

Tarek Ziad? wrote:
> On Fri, Sep 11, 2009 at 11:53 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> ...which is kinda annoying :-(
>>
>> The problem is, in Python 2.6.2, line 357 of sdist.py.
>>
>> This ends up applying the following:
>>
>> exclude_pattern: applying regex r'^build\.*'
>>
>> ...which of course chomps buildout.cfg, with no possibility to add it back
>> in MANIFEST.in :-(
> 
> You can disable the prune option with --no-prune

To what? the sdist command? Can I put that in setup.cfg somewhere?

> you can also uset the the MANIFEST.in template file to define
> what's in your distribution.

My MANIFEST.in currently contains:

include *

> That's for distutils. Beware that if you use Subversion and setuptools,
> it doesn't work the same way depending on what you've included
> in your repo, but at the end MANIFEST.in has the last word if you use it.

I've tried with distutils, setuptools and distribute. All exhibit the 
same behaviour...

Chris

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

From ziade.tarek at gmail.com  Fri Sep 11 12:06:11 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 12:06:11 +0200
Subject: [Distutils] distutils' sdist won't allow me to include a file
	called buildout.cfg in my source distribution
In-Reply-To: <4AAA204A.5010706@simplistix.co.uk>
References: <4AAA1E01.605@simplistix.co.uk>
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
	<4AAA204A.5010706@simplistix.co.uk>
Message-ID: <94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>

On Fri, Sep 11, 2009 at 12:02 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> On Fri, Sep 11, 2009 at 11:53 AM, Chris Withers <chris at simplistix.co.uk>
>> wrote:
>>>
>>> ...which is kinda annoying :-(
>>>
>>> The problem is, in Python 2.6.2, line 357 of sdist.py.
>>>
>>> This ends up applying the following:
>>>
>>> exclude_pattern: applying regex r'^build\.*'
>>>
>>> ...which of course chomps buildout.cfg, with no possibility to add it
>>> back
>>> in MANIFEST.in :-(
>>
>> You can disable the prune option with --no-prune
>
> To what? the sdist command? Can I put that in setup.cfg somewhere?

yes you can, http://docs.python.org/distutils/configfile.html

>
>> you can also uset the the MANIFEST.in template file to define
>> what's in your distribution.
>
> My MANIFEST.in currently contains:
>
> include *
>

this is suppose to include all file alongside setup.py
(but no subdirs)

see http://docs.python.org/distutils/configfile.html

From chris at simplistix.co.uk  Fri Sep 11 12:07:45 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 11:07:45 +0100
Subject: [Distutils] setuptools and distribute do not support --no-prune
In-Reply-To: <94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
References: <4AAA1E01.605@simplistix.co.uk>
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
Message-ID: <4AAA2171.2060901@simplistix.co.uk>

Tarek Ziad? wrote:
>> ...which of course chomps buildout.cfg, with no possibility to add it back
>> in MANIFEST.in :-(
> 
> You can disable the prune option with --no-prune

Well, aside from the hassle this causes with having to manually exclude 
all the .svn files and the like, it also doesn't work on setuptools or 
distribute:

bin/docpy setup.py sdist --no-prune
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
    or: setup.py --help [cmd1 cmd2 ...]
    or: setup.py --help-commands
    or: setup.py cmd --help

error: option --no-prune not recognized

cheers,

Chris

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

From chris at simplistix.co.uk  Fri Sep 11 12:12:05 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 11:12:05 +0100
Subject: [Distutils] pruning overridea MANIFEST.in
In-Reply-To: <94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>
References: <4AAA1E01.605@simplistix.co.uk>	
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>	
	<4AAA204A.5010706@simplistix.co.uk>
	<94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>
Message-ID: <4AAA2275.9020700@simplistix.co.uk>

Tarek Ziad? wrote:
>> My MANIFEST.in currently contains:
>>
>> include *
>>
> 
> this is suppose to include all file alongside setup.py
> (but no subdirs)

I know! ;-)

It's not though...

Using disutils and with the following MANIFEST.in and 
DISTUTILS_DEBUG=true in the environment:

Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'sdist' command:
   {}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
checking if setup.py newer than MANIFEST
warning: sdist: standard file not found: should have one of README, 
README.txt
Distribution.get_command_obj(): creating 'build_py' command object
Distribution.get_command_obj(): creating 'build' command object
reading manifest template 'MANIFEST.in'
include buildout.cfg
include_pattern: applying regex r'^buildout\.cfg$'
  adding buildout.cfg
exclude_pattern: applying regex r'^build\.*'
  removing buildout.cfg

d'oh!

Chris

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

From chris at simplistix.co.uk  Fri Sep 11 12:13:40 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 11:13:40 +0100
Subject: [Distutils] pruning overrides MANIFEST.in
In-Reply-To: <4AAA2275.9020700@simplistix.co.uk>
References: <4AAA1E01.605@simplistix.co.uk>		<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>		<4AAA204A.5010706@simplistix.co.uk>	<94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>
	<4AAA2275.9020700@simplistix.co.uk>
Message-ID: <4AAA22D4.8060808@simplistix.co.uk>

Chris Withers wrote:
>> this is suppose to include all file alongside setup.py
>> (but no subdirs)
> 
> I know! ;-)
> 
> It's not though...
> 
> Using disutils and with the following MANIFEST.in 

Sorry:

"""
include buildout.cfg
"""

> and 
> DISTUTILS_DEBUG=true in the environment:
> 
> Distribution.parse_config_files():
> options (after parsing config files):
> no commands known yet
> options (after parsing command line):
> option dict for 'sdist' command:
>   {}
> running sdist
> Distribution.get_command_obj(): creating 'sdist' command object
> checking if setup.py newer than MANIFEST
> warning: sdist: standard file not found: should have one of README, 
> README.txt
> Distribution.get_command_obj(): creating 'build_py' command object
> Distribution.get_command_obj(): creating 'build' command object
> reading manifest template 'MANIFEST.in'
> include buildout.cfg
> include_pattern: applying regex r'^buildout\.cfg$'
>  adding buildout.cfg
> exclude_pattern: applying regex r'^build\.*'
>  removing buildout.cfg
> 
> d'oh!
> 
> Chris
> 

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

From ziade.tarek at gmail.com  Fri Sep 11 14:03:14 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 14:03:14 +0200
Subject: [Distutils] pruning overrides MANIFEST.in
In-Reply-To: <4AAA22D4.8060808@simplistix.co.uk>
References: <4AAA1E01.605@simplistix.co.uk>
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
	<4AAA204A.5010706@simplistix.co.uk>
	<94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>
	<4AAA2275.9020700@simplistix.co.uk>
	<4AAA22D4.8060808@simplistix.co.uk>
Message-ID: <94bdd2610909110503p151d203cscce233a813e09a20@mail.gmail.com>

2009/9/11 Chris Withers <chris at simplistix.co.uk>:
> Chris Withers wrote:
>>>
>>> this is suppose to include all file alongside setup.py
>>> (but no subdirs)
>>
>> I know! ;-)
>>
>> It's not though...
>>
>> Using disutils and with the following MANIFEST.in
>
> Sorry:
>
> """
> include buildout.cfg
> """


I tested and it works for me with distutils at 2.6 and I tried with the
current trunk:

MANIFEST.in:
  include buildout.cfg

setup.py:
  from distutils.core import setup
  setup(name='ok')

resulting MANIFEST, by calling "python setup.py sdist"
"""
buildout.cfg
setup.py
"""


I need to see the content of your setup.py, there must be an
interaction with something else.

From pje at telecommunity.com  Fri Sep 11 15:19:31 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 09:19:31 -0400
Subject: [Distutils] pkgutil.extend_path and .pkg files
In-Reply-To: <h88s00$7nv$1@ger.gmane.org>
References: <h88s00$7nv$1@ger.gmane.org>
Message-ID: <20090911131933.807EF3A403D@sparrow.telecommunity.com>

At 08:26 PM 9/9/2009 +0200, Thomas Heller wrote:
>pkgutil is somehow connected to setuptools

Not really.  Setuptools just provides a zipfile-compatible 
replacement for pkgutil.extend_path().


From chris at simplistix.co.uk  Fri Sep 11 15:23:38 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 14:23:38 +0100
Subject: [Distutils] pruning overrides MANIFEST.in
In-Reply-To: <94bdd2610909110503p151d203cscce233a813e09a20@mail.gmail.com>
References: <4AAA1E01.605@simplistix.co.uk>	
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>	
	<4AAA204A.5010706@simplistix.co.uk>	
	<94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>	
	<4AAA2275.9020700@simplistix.co.uk>	
	<4AAA22D4.8060808@simplistix.co.uk>
	<94bdd2610909110503p151d203cscce233a813e09a20@mail.gmail.com>
Message-ID: <4AAA4F5A.9000400@simplistix.co.uk>

Tarek Ziad? wrote:
> I tested and it works for me with distutils at 2.6 and I tried with the
> current trunk:

Well, something must be different, have you double checked your sys.path?

C:\LocalSVN\errorhandler\branches\docs>python -c "import sys; print 
'\n'.join(sys.path)"

C:\WINDOWS\system32\python25.zip
C:\Python25\DLLs
C:\Python25\lib
C:\Python25\lib\plat-win
C:\Python25\lib\lib-tk
C:\Python25
C:\Python25\lib\site-packages
C:\Python25\lib\site-packages\gtk-2.0
C:\Python25\lib\site-packages\win32
C:\Python25\lib\site-packages\win32\lib
C:\Python25\lib\site-packages\Pythonwin
C:\LocalSVN\errorhandler\branches\docs>del MANIFEST

C:\LocalSVN\errorhandler\branches\docs>type setup.py
import os
from distutils.core import setup

package_name = 'errorhandler'
package_dir = os.path.join(os.path.dirname(__file__),package_name)

setup(
     name=package_name,
     )

C:\LocalSVN\errorhandler\branches\docs>type MANIFEST.in
include buildout.cfg

C:\LocalSVN\errorhandler\branches\docs>\Python26\python.exe --version
Python 2.6.2

C:\LocalSVN\errorhandler\branches\docs>set DISTUTILS_DEBUG=true

C:\LocalSVN\errorhandler\branches\docs>\Python26\python.exe setup.py sdist
Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'sdist' command:
   {}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
warning: sdist: missing required meta-data: version, url
warning: sdist: missing meta-data: either (author and author_email) or 
(maintainer and maintainer_email) mus
t be supplied
checking if setup.py newer than MANIFEST
warning: sdist: standard file not found: should have one of README, 
README.txt
reading manifest template 'MANIFEST.in'
include buildout.cfg
include_pattern: applying regex r'^buildout\.cfg$'
  adding buildout.cfg
Distribution.get_command_obj(): creating 'build' command object
exclude_pattern: applying regex r'^build\.*'
  removing buildout.cfg

...

Maybe you have soem .rc file somewhere that distutils is picking up?

cheers,

Chris

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

From chris at simplistix.co.uk  Fri Sep 11 16:03:02 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 15:03:02 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>	<94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>	<4A9BBA2B.6010903@simplistix.co.uk>	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	<4AA4F94C.9080702@simplistix.co.uk>	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>	<4AA6136A.7080904@simplistix.co.uk>	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
Message-ID: <4AAA5896.9000807@simplistix.co.uk>

Tarek Ziad? wrote:
> The practice in the community is to create the long_description field
> using a separate reStructuredText file
> and reaching it in setup.py like this for example:
> 
> long_description = open('README.txt').read()
> 
> Having a callable that provides this feature in the template allows writing:
> 
> """
> [setup.cfg]
> 
> long_description: {$ long_description('README.txt') $}
> """

Exactly, so why have this complicated templating nonesense rather than 
just having:

[setup.cfg]

long_description_path: README.txt


> long_description_path can't be added in the final PKG-INFO because
> we want a self-contained metadata static file that doesn't require an
> extra resource (like an external file)

Why this requirement?

If this really is that strict, then only allow long_description_path in 
setup.cfg.in....

Chris

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

From ziade.tarek at gmail.com  Fri Sep 11 16:17:24 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 16:17:24 +0200
Subject: [Distutils] pruning overrides MANIFEST.in
In-Reply-To: <4AAA4F5A.9000400@simplistix.co.uk>
References: <4AAA1E01.605@simplistix.co.uk>
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>
	<4AAA204A.5010706@simplistix.co.uk>
	<94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>
	<4AAA2275.9020700@simplistix.co.uk>
	<4AAA22D4.8060808@simplistix.co.uk>
	<94bdd2610909110503p151d203cscce233a813e09a20@mail.gmail.com>
	<4AAA4F5A.9000400@simplistix.co.uk>
Message-ID: <94bdd2610909110717w5d68a12dm75db94c98d2a7599@mail.gmail.com>

On Fri, Sep 11, 2009 at 3:23 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> I tested and it works for me with distutils at 2.6 and I tried with the
>> current trunk:
>
> Well, something must be different, have you double checked your sys.path?
>
> C:\LocalSVN\errorhandler\branches\docs>python -c "import sys; print
> '\n'.join(sys.path)"
>
> C:\WINDOWS\system32\python25.zip

That's you python 2.5

> Distribution.get_command_obj(): creating 'build' command object
> exclude_pattern: applying regex r'^build\.*'
> ?removing buildout.cfg

That must be a win32 specific bug then on the way globs are translated
(\ should be escaped) with regular expressions. the exclude built on
my mac os  is :

'^build/.*'

which is correct. I will try on a vmware as soon I get a chance,

Until then you can fill an issue in bugs.python.org. I'll fix it as soon
as I have a failing example in a unit test

Tarek

From ziade.tarek at gmail.com  Fri Sep 11 16:23:53 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 16:23:53 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AAA5896.9000807@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<4A9BBA2B.6010903@simplistix.co.uk>
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>
	<4AA4F94C.9080702@simplistix.co.uk>
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>
	<4AA6136A.7080904@simplistix.co.uk>
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>
	<4AA61606.6060002@simplistix.co.uk>
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>
	<4AAA5896.9000807@simplistix.co.uk>
Message-ID: <94bdd2610909110723t2fbc394cn2f915f36d8706adc@mail.gmail.com>

On Fri, Sep 11, 2009 at 4:03 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> The practice in the community is to create the long_description field
>> using a separate reStructuredText file
>> and reaching it in setup.py like this for example:
>>
>> long_description = open('README.txt').read()
>>
>> Having a callable that provides this feature in the template allows
>> writing:
>>
>> """
>> [setup.cfg]
>>
>> long_description: {$ long_description('README.txt') $}
>> """
>
> Exactly, so why have this complicated templating nonesense rather than just
> having:
>
> [setup.cfg]
>
> long_description_path: README.txt
>
>
>> long_description_path can't be added in the final PKG-INFO because
>> we want a self-contained metadata static file that doesn't require an
>> extra resource (like an external file)
>
> Why this requirement?

Where this external file would it be located ?
There's just *one* metadata file that contains everything.

People are injecting files in it when they build the distribution and sometime
don't even ship it with the archive.

If you put a path you can't be sure that the file behind this path
will be available
on the system that reads setup.cfg.

And it would break the idea that we can have static metadata without
further processing the package (by installing it or opening its files)

From chris at simplistix.co.uk  Fri Sep 11 16:29:05 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 11 Sep 2009 15:29:05 +0100
Subject: [Distutils] pruning overrides MANIFEST.in
In-Reply-To: <94bdd2610909110717w5d68a12dm75db94c98d2a7599@mail.gmail.com>
References: <4AAA1E01.605@simplistix.co.uk>	
	<94bdd2610909110258w3895aaf7y34274fb4d8e05404@mail.gmail.com>	
	<4AAA204A.5010706@simplistix.co.uk>	
	<94bdd2610909110306p59f9f11fke4faa64ccac64bdb@mail.gmail.com>	
	<4AAA2275.9020700@simplistix.co.uk>	
	<4AAA22D4.8060808@simplistix.co.uk>	
	<94bdd2610909110503p151d203cscce233a813e09a20@mail.gmail.com>	
	<4AAA4F5A.9000400@simplistix.co.uk>
	<94bdd2610909110717w5d68a12dm75db94c98d2a7599@mail.gmail.com>
Message-ID: <4AAA5EB1.7000104@simplistix.co.uk>

Tarek Ziad? wrote:
> On Fri, Sep 11, 2009 at 3:23 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>> Tarek Ziad? wrote:
>>> I tested and it works for me with distutils at 2.6 and I tried with the
>>> current trunk:
>> Well, something must be different, have you double checked your sys.path?
>>
>> C:\LocalSVN\errorhandler\branches\docs>python -c "import sys; print
>> '\n'.join(sys.path)"
>>
>> C:\WINDOWS\system32\python25.zip
> 
> That's you python 2.5

Sorry, yes, forgot to use 2.6 for those first two bits, doesn't make any 
difference...

>> Distribution.get_command_obj(): creating 'build' command object
>> exclude_pattern: applying regex r'^build\.*'
>>  removing buildout.cfg
> 
> That must be a win32 specific bug then on the way globs are translated
> (\ should be escaped) with regular expressions. the exclude built on
> my mac os  is :
> 
> '^build/.*'
> 
> which is correct. I will try on a vmware as soon I get a chance,
> 
> Until then you can fill an issue in bugs.python.org. I'll fix it as soon
> as I have a failing example in a unit test

http://bugs.python.org/issue6884

cheers,

Chris

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

From ziade.tarek at gmail.com  Fri Sep 11 16:33:27 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 16:33:27 +0200
Subject: [Distutils] setup.cfg new format proposal
Message-ID: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>

Hello

here's a detailed proposal for the setup.cfg format. I've included all remarks,
and tried to make the syntax as simple as possible. I've dropped the
long_description
stuff and the template language stuff. (people can do it as a
post-release process)


A/ Config file structure:

"""
[setup]
foo: bar
conditional-sections: one, two

[one]
condition: test

[two]
condition: test
"""

2/ Execution environment:

  python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
  os_name = os.name
  platform = sys.platform
  uname = os.uname()
  python_version_info = sys.version_info

3/ Grammar:

comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 'not'
comparison: expr (comp_op expr)*
expr: 'python_version'|'python_version_info'|'os_name'|'uname'|'platform'|STRING
test: or_test
or_test: and_test ('or' and_test)*
and_test: not_test ('and' not_test)*
not_test: 'not' not_test | comparison

4/ Process

distutils will interpret [setup] and act upon, to fill the
Distribution object and its metadata attribute object.
It will look only for Metadata fields and ignores the others.

In case an option is passed in setup.py, it overrides the one in setup.cfg.

Let me know if it's good enough. I won't write a PEP for this change,
and I will just push it for information at python-dev as soon as I get
enough +1 :)

Regards
Tarek

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

From exarkun at twistedmatrix.com  Fri Sep 11 16:47:11 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Fri, 11 Sep 2009 14:47:11 -0000
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
Message-ID: <20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>

On 02:33 pm, ziade.tarek at gmail.com wrote:
>Hello
>
>here's a detailed proposal for the setup.cfg format. I've included all 
>remarks,
>and tried to make the syntax as simple as possible. I've dropped the
>long_description
>stuff and the template language stuff. (people can do it as a
>post-release process)
>
>
>A/ Config file structure:
>
>"""
>[setup]
>foo: bar
>conditional-sections: one, two
>
>[one]
>condition: test
>
>[two]
>condition: test
>"""

The idea here is that the [setup] section includes everything in section 
[one] if all of the "condition" clauses in [one] are satisfied, and 
includes everything in section [two] if all of the "condition" clauses 
in [two] are satisfied?
>2/ Execution environment:
>
>  python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
>  os_name = os.name
>  platform = sys.platform
>  uname = os.uname()
>  python_version_info = sys.version_info
>
>3/ Grammar:
>
>comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 
>'not'
>comparison: expr (comp_op expr)*
>expr: 
>'python_version'|'python_version_info'|'os_name'|'uname'|'platform'|STRING
>test: or_test
>or_test: and_test ('or' and_test)*
>and_test: not_test ('and' not_test)*
>not_test: 'not' not_test | comparison

What's "STRING"?  What's the precedence of and, or, and not?  What does 
this mean?

    os_name > uname > 7

What does "is" mean?

Is this all really Python, with lots of features thrown out?
>
>4/ Process
>
>distutils will interpret [setup] and act upon, to fill the
>Distribution object and its metadata attribute object.
>It will look only for Metadata fields and ignores the others.
>
>In case an option is passed in setup.py, it overrides the one in 
>setup.cfg.
>
>Let me know if it's good enough. I won't write a PEP for this change,
>and I will just push it for information at python-dev as soon as I get
>enough +1 :)

I'm a little skeptical about creating a new mini language (particularly 
one with branching) for setup.cfg, but I haven't really been paying 
close attention to this discussion.  Still, it might be good to give a 
brief summary of the justification for this someplace.  Maybe you were 
already planning to do that.

Jean-Paul

From ziade.tarek at gmail.com  Fri Sep 11 17:14:57 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 17:14:57 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
Message-ID: <94bdd2610909110814s3e09735duedd37e8a984fb7d3@mail.gmail.com>

2009/9/11  <exarkun at twistedmatrix.com>:
> On 02:33 pm, ziade.tarek at gmail.com wrote:
>>
>> Hello
>>
>> here's a detailed proposal for the setup.cfg format. I've included all
>> remarks,
>> and tried to make the syntax as simple as possible. I've dropped the
>> long_description
>> stuff and the template language stuff. (people can do it as a
>> post-release process)
>>
>>
>> A/ Config file structure:
>>
>> """
>> [setup]
>> foo: bar
>> conditional-sections: one, two
>>
>> [one]
>> condition: test
>>
>> [two]
>> condition: test
>> """
>
> The idea here is that the [setup] section includes everything in section
> [one] if all of the "condition" clauses in [one] are satisfied, and includes
> everything in section [two] if all of the "condition" clauses in [two] are
> satisfied?


yes, here's a concrete example :

"""
[setup]
name: distutils
version: 1.2
conditional-sections: py26, py3

[py26]
condition: python_version <= 2.6
install_requires = lxml

[py3]
condition: python_version >= 3
install_requires = foo
"""

>>
>> 2/ Execution environment:
>>
>> ?python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
>> ?os_name = os.name
>> ?platform = sys.platform
>> ?uname = os.uname()
>> ?python_version_info = sys.version_info
>>
>> 3/ Grammar:
>>
>> comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 'not'
>> comparison: expr (comp_op expr)*
>> expr:
>> 'python_version'|'python_version_info'|'os_name'|'uname'|'platform'|STRING
>> test: or_test
>> or_test: and_test ('or' and_test)*
>> and_test: not_test ('and' not_test)*
>> not_test: 'not' not_test | comparison
>
> What's "STRING"? ?What's the precedence of and, or, and not? ?What does this
> mean?

STRING is any string value that will be compared to one of the values
provided in the environment,

Also, I've just realized that uname() is a tuple, so I need to flatten
it in strings to restrict the grammar:

- os_sysname
- os_nodename
- os_release
- os_version
- os_machine


>
> ? os_name > uname > 7
>
> What does "is" mean?

That can be dropped since we have '==' and it's all strings.

so:

comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'

>
> Is this all really Python, with lots of features thrown out?

I copy-pasted part of Python grammar and restricted to what we need yes,
but the idea is just to have string comparisons with ands and ors

>>
>> 4/ Process
>>
>> distutils will interpret [setup] and act upon, to fill the
>> Distribution object and its metadata attribute object.
>> It will look only for Metadata fields and ignores the others.
>>
>> In case an option is passed in setup.py, it overrides the one in
>> setup.cfg.
>>
>> Let me know if it's good enough. I won't write a PEP for this change,
>> and I will just push it for information at python-dev as soon as I get
>> enough +1 :)
>
> I'm a little skeptical about creating a new mini language (particularly one
> with branching) for setup.cfg, but I haven't really been paying close
> attention to this discussion. ?Still, it might be good to give a brief
> summary of the justification for this someplace. ?Maybe you were already
> planning to do that.

The idea is to be able to get with setup.cfg all the metadata without running
any code from the distribution, and without installing it.

Which is possible for most cases. (if not possible, setup.py  can still be used)

the mini-language is to be able to adapt these metadata depending on
the execution context. I'll add a doc somewhere.

Tarek

From ziade.tarek at gmail.com  Fri Sep 11 17:14:58 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 17:14:58 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
Message-ID: <94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>

2009/9/11  <exarkun at twistedmatrix.com>:
> On 02:33 pm, ziade.tarek at gmail.com wrote:
>>
>> Hello
>>
>> here's a detailed proposal for the setup.cfg format. I've included all
>> remarks,
>> and tried to make the syntax as simple as possible. I've dropped the
>> long_description
>> stuff and the template language stuff. (people can do it as a
>> post-release process)
>>
>>
>> A/ Config file structure:
>>
>> """
>> [setup]
>> foo: bar
>> conditional-sections: one, two
>>
>> [one]
>> condition: test
>>
>> [two]
>> condition: test
>> """
>
> The idea here is that the [setup] section includes everything in section
> [one] if all of the "condition" clauses in [one] are satisfied, and includes
> everything in section [two] if all of the "condition" clauses in [two] are
> satisfied?


yes, here's a concrete example :

"""
[setup]
name: distutils
version: 1.2
conditional-sections: py26, py3

[py26]
condition: python_version <= 2.6
install_requires = lxml

[py3]
condition: python_version >= 3
install_requires = foo
"""

>>
>> 2/ Execution environment:
>>
>> ?python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
>> ?os_name = os.name
>> ?platform = sys.platform
>> ?uname = os.uname()
>> ?python_version_info = sys.version_info
>>
>> 3/ Grammar:
>>
>> comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 'not'
>> comparison: expr (comp_op expr)*
>> expr:
>> 'python_version'|'python_version_info'|'os_name'|'uname'|'platform'|STRING
>> test: or_test
>> or_test: and_test ('or' and_test)*
>> and_test: not_test ('and' not_test)*
>> not_test: 'not' not_test | comparison
>
> What's "STRING"? ?What's the precedence of and, or, and not? ?What does this
> mean?

STRING is any string value that will be compared to one of the values
provided in the environment,

Also, I've just realized that uname() is a tuple, so I need to flatten
it in strings to restrict the grammar:

- os_sysname
- os_nodename
- os_release
- os_version
- os_machine


>
> ? os_name > uname > 7
>
> What does "is" mean?

That can be dropped since we have '==' and it's all strings.

so:

comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'

>
> Is this all really Python, with lots of features thrown out?

I copy-pasted part of Python grammar and restricted to what we need yes,
but the idea is just to have string comparisons with ands and ors

>>
>> 4/ Process
>>
>> distutils will interpret [setup] and act upon, to fill the
>> Distribution object and its metadata attribute object.
>> It will look only for Metadata fields and ignores the others.
>>
>> In case an option is passed in setup.py, it overrides the one in
>> setup.cfg.
>>
>> Let me know if it's good enough. I won't write a PEP for this change,
>> and I will just push it for information at python-dev as soon as I get
>> enough +1 :)
>
> I'm a little skeptical about creating a new mini language (particularly one
> with branching) for setup.cfg, but I haven't really been paying close
> attention to this discussion. ?Still, it might be good to give a brief
> summary of the justification for this someplace. ?Maybe you were already
> planning to do that.

The idea is to be able to get with setup.cfg all the metadata without running
any code from the distribution, and without installing it.

Which is possible for most cases. (if not possible, setup.py  can still be used)

the mini-language is to be able to adapt these metadata depending on
the execution context. I'll add a doc somewhere.

Tarek

From jim at zope.com  Fri Sep 11 17:36:22 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 11 Sep 2009 11:36:22 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
Message-ID: <1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>

On Fri, Sep 11, 2009 at 11:14 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> 2009/9/11 ?<exarkun at twistedmatrix.com>:
>> On 02:33 pm, ziade.tarek at gmail.com wrote:
>> I'm a little skeptical about creating a new mini language (particularly one
>> with branching) for setup.cfg,

Me too.

>> but I haven't really been paying close
>> attention to this discussion.

Me neither. :)

>> ?Still, it might be good to give a brief
>> summary of the justification for this someplace. ?Maybe you were already
>> planning to do that.
>
> The idea is to be able to get with setup.cfg all the metadata without running
> any code from the distribution, and without installing it.
>
> Which is possible for most cases. (if not possible, setup.py ?can still be used)
>
> the mini-language is to be able to adapt these metadata depending on
> the execution context. I'll add a doc somewhere.

Is that really necessary?  I mean, if you have to adapt the meta data
to the execution context, maybe you should fall back to writing a
setup.py.

I agree that more background and motivational information would be
very helpful, as would some real world examples. I know that >90%
(maybe 99% :) of the packages I distribute don't adapt to their
execution context (beyond what distutils does internally) or need
anything but meta data.

Jim

-- 
Jim Fulton

From ziade.tarek at gmail.com  Fri Sep 11 17:49:51 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 17:49:51 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
Message-ID: <94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>

On Fri, Sep 11, 2009 at 5:36 PM, Jim Fulton <jim at zope.com> wrote:
> On Fri, Sep 11, 2009 at 11:14 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> 2009/9/11 ?<exarkun at twistedmatrix.com>:
>>> On 02:33 pm, ziade.tarek at gmail.com wrote:
>>> I'm a little skeptical about creating a new mini language (particularly one
>>> with branching) for setup.cfg,
>
> Me too.
>
>>> but I haven't really been paying close
>>> attention to this discussion.
>
> Me neither. :)
>
>>> ?Still, it might be good to give a brief
>>> summary of the justification for this someplace. ?Maybe you were already
>>> planning to do that.
>>
>> The idea is to be able to get with setup.cfg all the metadata without running
>> any code from the distribution, and without installing it.
>>
>> Which is possible for most cases. (if not possible, setup.py ?can still be used)
>>
>> the mini-language is to be able to adapt these metadata depending on
>> the execution context. I'll add a doc somewhere.
>
> Is that really necessary? ?I mean, if you have to adapt the meta data
> to the execution context, maybe you should fall back to writing a
> setup.py.

The main background motivation is the future adding of
"install_requires" in PEP 345.

So you can for example define a list of dependencies that changes wether
you are under windows or linux, etc..

The second motivation is : why do I need to run some code to get the
metadata fields ?
do I need to install a package to gets its metadata ?

In 99% of the cases that would'nt be necessary.

try to run this with lxml source tarball:

$ python setup.py --name

I don't know what it is doing, but a whole lot more that what it is
suppose to do
just to let me know the 'name' metadata.

So if name was in setup.cfg, it would be better.

>
> I agree that more background and motivational information would be
> very helpful, as would some real world examples. I know that >90%
> (maybe 99% :) of the packages I distribute don't adapt to their
> execution context (beyond what distutils does internally) or need
> anything but meta data.

That's why you could push your fields in the static setup.cfg.

(and probably have an 'empty' setup.py file)

I will prepare a document summarizing. Maybe a PEP would be required then
if it's not an obvious change.


Tarek

From floris.bruynooghe at gmail.com  Fri Sep 11 18:32:32 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Fri, 11 Sep 2009 17:32:32 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
Message-ID: <20090911163232.GB2903@laurie.devork>

On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
[...]
> That can be dropped since we have '==' and it's all strings.

'2.6' < '2.10'?

Although not close you must be wary of this.  Bring on PEP 386 ;-)

Regards
Floris

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

From michal at michalklich.com  Fri Sep 11 18:55:09 2009
From: michal at michalklich.com (=?UTF-8?Q?Micha=C5=82_Klich?=)
Date: Fri, 11 Sep 2009 18:55:09 +0200
Subject: [Distutils] distutils bdist_rpm and %postun section of spec file
Message-ID: <696781e0909110955x1fde5c7dj8c0a64238932e1e9@mail.gmail.com>

Hello,
I am looking for some advise in creating rpm package using bdist_rpm.
I have managed to create post_install part using information
http://stackoverflow.com/questions/1321270/how-to-extend-distutils-with-a-simple-post-install-script
Now i would like to add some code to %postun part of spec file to revert
changes done by my post_install command.
Is there a way to add it in setup.py or do i have to manually edit spec
file?

-- 
Micha? Klich

klich.michal at gmail.com
michal at michalklich.com
http://www.michalklich.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090911/51056d83/attachment.htm>

From ziade.tarek at gmail.com  Fri Sep 11 19:02:53 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Sep 2009 19:02:53 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090911163232.GB2903@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090911163232.GB2903@laurie.devork>
Message-ID: <94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>

On Fri, Sep 11, 2009 at 6:32 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
> [...]
>> That can be dropped since we have '==' and it's all strings.
>
> '2.6' < '2.10'?
>
> Although not close you must be wary of this. ?Bring on PEP 386 ;-)

Right. Maybe we can drop < >, >= and >=, completely.

In real world use cases, we can use "or" to make a section work for
2.6, 3.1, etc.. for python versions.

I can't think of a use case where "in" and "==" is not enough.

From jim at zope.com  Fri Sep 11 19:40:57 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 11 Sep 2009 13:40:57 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
Message-ID: <1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>

On Fri, Sep 11, 2009 at 11:49 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Sep 11, 2009 at 5:36 PM, Jim Fulton <jim at zope.com> wrote:
>> On Fri, Sep 11, 2009 at 11:14 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> 2009/9/11 ?<exarkun at twistedmatrix.com>:
>>>> On 02:33 pm, ziade.tarek at gmail.com wrote:
>>>> I'm a little skeptical about creating a new mini language (particularly one
>>>> with branching) for setup.cfg,
>>
>> Me too.
>>
>>>> but I haven't really been paying close
>>>> attention to this discussion.
>>
>> Me neither. :)
>>
>>>> ?Still, it might be good to give a brief
>>>> summary of the justification for this someplace. ?Maybe you were already
>>>> planning to do that.
>>>
>>> The idea is to be able to get with setup.cfg all the metadata without running
>>> any code from the distribution, and without installing it.
>>>
>>> Which is possible for most cases. (if not possible, setup.py ?can still be used)
>>>
>>> the mini-language is to be able to adapt these metadata depending on
>>> the execution context. I'll add a doc somewhere.
>>
>> Is that really necessary? ?I mean, if you have to adapt the meta data
>> to the execution context, maybe you should fall back to writing a
>> setup.py.
>
> The main background motivation is the future adding of
> "install_requires" in PEP 345.
>
> So you can for example define a list of dependencies that changes wether
> you are under windows or linux, etc..

OK. I've never had that situation. I'm sure someone has, but it
doesn't see common.

> The second motivation is : why do I need to run some code to get the
> metadata fields ?

Turning the config file into code means you'd be running code. :)

Still, I suspect that 99% (or some very high percentage) of cases
wouldn't need conditional logic in meta data files.


> do I need to install a package to gets its metadata ?

This is an important use case.  It is orthogonal to defining packages
with static meta data.

...

>
> try to run this with lxml source tarball:
>
> $ python setup.py --name
>
> I don't know what it is doing, but a whole lot more that what it is
> suppose to do
> just to let me know the 'name' metadata.
>
> So if name was in setup.cfg, it would be better.

Somewhat. I think the main concern though is to get the meta data
without installing.

In any case, I think a sufficiently large percentage of cases can be
handled without logic in the setup.cfg.


>
>>
>> I agree that more background and motivational information would be
>> very helpful, as would some real world examples. I know that >90%
>> (maybe 99% :) of the packages I distribute don't adapt to their
>> execution context (beyond what distutils does internally) or need
>> anything but meta data.
>
> That's why you could push your fields in the static setup.cfg.
>
> (and probably have an 'empty' setup.py file)

Yup. Don't get me wrong. I'm in favor of being able to define packages
with static meta data. I just don't consider configuration files with
logic in them to be static. :)

Jim


-- 
Jim Fulton

From o.borderline at gmail.com  Fri Sep 11 22:15:07 2009
From: o.borderline at gmail.com (OB)
Date: Fri, 11 Sep 2009 13:15:07 -0700
Subject: [Distutils] Compile C code and install to script dir?
Message-ID: <C6CFFDDB.8384%o.borderline@gmail.com>

Hello!

I am trying to get distutils to compile a single C script and install the
binary to the same script directory as the entry point scripts that are
generated for the python part of the module. I would like to use all the
includes, CFLAGS, etc that are used when compiling extension modules, but
this C script is not an extension. Is there a way to do this through setup,
or do I need to use distutils.ccompiler.new_compiler() and try to hunt down
CFLAGS, default libs, etc?

I am using setuptools 0.6c9 and distutils with Python 2.5.4.

Any help would be greatly appreciated!

Thanks,
Orion



From ben+python at benfinney.id.au  Sat Sep 12 00:14:54 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 12 Sep 2009 08:14:54 +1000
Subject: [Distutils] uses for setup.cfg and extracting data from it
References: <4AA77593.9010809@simplistix.co.uk>
	<878wgo1c85.fsf@benfinney.id.au>
	<20090909143159.426783A403D@sparrow.telecommunity.com>
Message-ID: <87my51yvq9.fsf@benfinney.id.au>

"P.J. Eby" <pje at telecommunity.com> writes:

> If you're talking about setup.py, all you need to do is use the
> distutils functions that allow you to run a setup.py without executing
> any of its commands.

Specifically, I want to programmatically access the metadata that is
held in the arguments to the ?distutils.setup()? call. Without, as you
say, executing any Distutils command.

I am not aware of any ?distutils? public functions that can do that, and
reading <URL:http://docs.python.org/distutils/> again doesn't enlighten
me. Would you be more specific about what these functions are?

-- 
 \     ?Guaranteed to work throughout its useful life.? ?packaging for |
  `\                                          clockwork toy, Hong Kong |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Sat Sep 12 00:28:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Sep 2009 00:28:01 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
Message-ID: <94bdd2610909111528w527c9455madf4d32a9b9373fa@mail.gmail.com>

On Fri, Sep 11, 2009 at 7:40 PM, Jim Fulton <jim at zope.com> wrote:
>
>> The second motivation is : why do I need to run some code to get the
>> metadata fields ?
>
> Turning the config file into code means you'd be running code. :)

Well that's very different. You will be running a function that is
provided in the stdlib,
in a vanilla Python, and that will be restricted to string comparisons
basically.

In other words, it is more likely to be a translation of setup.cfg
into a "localized"
setup.cfg.


>
>> do I need to install a package to gets its metadata ?
>
> This is an important use case. ?It is orthogonal to defining packages
> with static meta data.

Sure. but both can exist. although It would require a flag in
setup.cfg indicating that
it is not standalone. e.g. doesn't provides all metadata without
requiring to execute some
code in the distribution.

If the flag is not present, you know you can work with setup.cfg alone.


> Somewhat. I think the main concern though is to get the meta data
> without installing.

Well, without running the setup.py code at the minimum, to extract the metadata
if they are platform-dependant. Which can start to happen more and
more the day we add the famous "requires" in the metadata.

For instance, how can I say that I need simplejson only if it's Python
2.5 or above ?

People will have to download the package and run something to know it,
where they could just read the setup.cfg file.

The simplejson dependency will appear at PyPI *only* if the person that ran
the register command used python 2.5 when he did... that's a problem indeed.

Security-wise, if the micro-language is restricted to string comparisons,
with a restricted list of variables, people and tool will be able to query
setup.cfg with no risk.

>
> In any case, I think a sufficiently large percentage of cases can be
> handled without logic in the setup.cfg.

yes

>>> I agree that more background and motivational information would be
>>> very helpful, as would some real world examples. I know that >90%
>>> (maybe 99% :) of the packages I distribute don't adapt to their
>>> execution context (beyond what distutils does internally) or need
>>> anything but meta data.
>>
>> That's why you could push your fields in the static setup.cfg.
>>
>> (and probably have an 'empty' setup.py file)
>
> Yup. Don't get me wrong. I'm in favor of being able to define packages
> with static meta data. I just don't consider configuration files with
> logic in them to be static. :)
>

Let's call it differently then, because if we want static metadata,
we will have to provide that logic for the 1% that needs it.

In any case, is such a feature is a problem for the 99% left ?

You could still add your metadata in the [setup] section and
never use that feature.

From zooko at zooko.com  Sat Sep 12 01:21:48 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Fri, 11 Sep 2009 17:21:48 -0600
Subject: [Distutils] Distribute 0.6.1 released
In-Reply-To: <94bdd2610909081446l37597e9cm9b88550ecfa87db6@mail.gmail.com>
References: <94bdd2610909081420q6af87df6h3807c3c0c68262ad@mail.gmail.com>
	<94bdd2610909081446l37597e9cm9b88550ecfa87db6@mail.gmail.com>
Message-ID: <D85E1E1E-59E0-41CA-B4B6-761D9490DCEA@zooko.com>

On Tuesday,2009-09-08, at 15:46 , Tarek Ziad? wrote:

> On Tue, Sep 8, 2009 at 11:20 PM, Tarek Ziad?<ziade.tarek at gmail.com>  
> wrote:
>> Hello
>>
>> I am happy to announce the release of Distribute 0.6.1.
>>
>> Changes:
>>
>> * zip_ok is now True by default.
>
> I mean False of course ;)

But wait, "zip_ok" is a flag on a package which tells whether this  
package has something in it that breaks when loaded from a .zip  
file.  My proposal in http://bugs.python.org/setuptools/issue33 was  
*not* to make zip_ok default to False, but instead to make  
always_unzip default to True!  always_unzip is a flag in your system  
which tells whether you want to unzip packages when installing them.   
I guess I don't precisely *object* to setting zip_ok to default  
False, at least for now, but I prefer setting always_unzip to default  
to True.  Some people might like to configure their local system to  
install packages zipped unless that package says that it won't work  
that way.

Regards,

Zooko

From pje at telecommunity.com  Sat Sep 12 02:22:03 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 20:22:03 -0400
Subject: [Distutils] uses for setup.cfg and extracting data from it
In-Reply-To: <87my51yvq9.fsf@benfinney.id.au>
References: <4AA77593.9010809@simplistix.co.uk>
	<878wgo1c85.fsf@benfinney.id.au>
	<20090909143159.426783A403D@sparrow.telecommunity.com>
	<87my51yvq9.fsf@benfinney.id.au>
Message-ID: <20090912002159.2C60E3A403D@sparrow.telecommunity.com>

At 08:14 AM 9/12/2009 +1000, Ben Finney wrote:
>Specifically, I want to programmatically access the metadata that is 
>held in the arguments to the ???distutils.setup()??? call. Without, 
>as you say, executing any Distutils command. I am not aware of any 
>???distutils??? public functions that can do that, and reading 
><URL:http://docs.python.org/distutils/> again doesn't enlighten me. 
>Would you be more specific about what these functions are?

http://docs.python.org/distutils/apiref.html#module-distutils.core - 
specifically the run_setup() function.  (It appears the docs do not 
have link anchors for individual functions, alas.)

distutils.core.run_setup("setup.py", [], "init") will return you an 
initialized Distribution object from running the setup script, 
without parsing any configuration files or executing any 
commands.  You could use "config" or "commandline" instead of "init" 
if you wanted those pieces of processing to be done as well - i.e. if 
you wanted to be sure any setup.cfg options were processed.

This will work with a sufficiently well-behaved setup.py; setup 
scripts that try to do build or install steps outside of any 
distutils command may produce side-effects when run.  (Which is why 
setuptools always runs setup scripts in a loose sandbox that detects 
when a script tries to modify the filesystem outside the setup directory.)


From pje at telecommunity.com  Sat Sep 12 02:25:27 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 20:25:27 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909111528w527c9455madf4d32a9b9373fa@mail.gmail.co
 m>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<94bdd2610909111528w527c9455madf4d32a9b9373fa@mail.gmail.com>
Message-ID: <20090912002522.DE0D93A403D@sparrow.telecommunity.com>

At 12:28 AM 9/12/2009 +0200, Tarek Ziad? wrote:
>On Fri, Sep 11, 2009 at 7:40 PM, Jim Fulton <jim at zope.com> wrote:
> >
> >> The second motivation is : why do I need to run some code to get the
> >> metadata fields ?
> >
> > Turning the config file into code means you'd be running code. :)
>
>Well that's very different. You will be running a function that is
>provided in the stdlib,
>in a vanilla Python, and that will be restricted to string comparisons
>basically.
>
>In other words, it is more likely to be a translation of setup.cfg
>into a "localized"
>setup.cfg.

But in that case, why not just have a 100% static format without any 
dynamic content whatsoever, and run a "configure.py" or some such 
(perhaps "distconfig.py") to generate it?  Since it's not setup.py, 
there are no backward compatibility issues, and we can actually get 
the full benefit of environment-specific configuration (e.g. library 
locations, etc.).


From ziade.tarek at gmail.com  Sat Sep 12 02:50:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Sep 2009 02:50:25 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090912002522.DE0D93A403D@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<94bdd2610909111528w527c9455madf4d32a9b9373fa@mail.gmail.com>
	<20090912002522.DE0D93A403D@sparrow.telecommunity.com>
Message-ID: <94bdd2610909111750p55af1383ocb5708c5fd848352@mail.gmail.com>

2009/9/12 P.J. Eby <pje at telecommunity.com>:
> At 12:28 AM 9/12/2009 +0200, Tarek Ziad? wrote:
>>
>> On Fri, Sep 11, 2009 at 7:40 PM, Jim Fulton <jim at zope.com> wrote:
>> >
>> >> The second motivation is : why do I need to run some code to get the
>> >> metadata fields ?
>> >
>> > Turning the config file into code means you'd be running code. :)
>>
>> Well that's very different. You will be running a function that is
>> provided in the stdlib,
>> in a vanilla Python, and that will be restricted to string comparisons
>> basically.
>>
>> In other words, it is more likely to be a translation of setup.cfg
>> into a "localized"
>> setup.cfg.
>
> But in that case, why not just have a 100% static format without any dynamic
> content whatsoever, and run a "configure.py" or some such (perhaps
> "distconfig.py") to generate it? ?Since it's not setup.py, there are no
> backward compatibility issues, and we can actually get the full benefit of
> environment-specific configuration (e.g. library locations, etc.).

The benefit of the not-so-static setup.cfg I can see:

1/ If the code used to read setup.cfg knows how to translate a setup.cfg into
   "a localized" one, given a list of strings that defines the python
execution environment

2/ if it is located in the stdlib and is restricted to that usage

it means that we can even provide an XML-RPC service at PyPI so people
can query the metadata for their platform with zero download and zero
third-party
code execution.

I can see a use case of the configure.py file you are describing:
prepare the compilation some C Extensions by looking for some libs etc,

But that's something that can already be done with setup.py when you build
or install the distribution.

So what would be the metadata field that would require to look for a
library location ?

From ziade.tarek at gmail.com  Sat Sep 12 02:52:17 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Sep 2009 02:52:17 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
Message-ID: <94bdd2610909111752i5b147a3cx791611ae3a130d45@mail.gmail.com>

On Fri, Sep 11, 2009 at 5:49 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> I agree that more background and motivational information would be
>> very helpful, as would some real world examples. I know that >90%
>> (maybe 99% :) of the packages I distribute don't adapt to their
>> execution context (beyond what distutils does internally) or need
>> anything but meta data.

That's a first draft:

http://tarekziade.wordpress.com/2009/09/12/static-metadata-for-distutils/

I blogged it to get some more feedback.

From pje at telecommunity.com  Sat Sep 12 03:57:28 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 11 Sep 2009 21:57:28 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909111750p55af1383ocb5708c5fd848352@mail.gmail.co
 m>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<94bdd2610909111528w527c9455madf4d32a9b9373fa@mail.gmail.com>
	<20090912002522.DE0D93A403D@sparrow.telecommunity.com>
	<94bdd2610909111750p55af1383ocb5708c5fd848352@mail.gmail.com>
Message-ID: <20090912015723.1F3783A403D@sparrow.telecommunity.com>

At 02:50 AM 9/12/2009 +0200, Tarek Ziad? wrote:
>it means that we can even provide an XML-RPC service at PyPI so people
>can query the metadata for their platform with zero download and zero
>third-party
>code execution.

Ah, now that does sound rather useful, as it would allow installation 
and similar tools to resolve dependencies without first needing to 
build or download binaries.


>I can see a use case of the configure.py file you are describing:
>prepare the compilation some C Extensions by looking for some libs etc,
>
>But that's something that can already be done with setup.py when you build
>or install the distribution.
>
>So what would be the metadata field that would require to look for a
>library location ?

I had in mind that if you had such a configure script, it could also 
generate a manifest of files to be installed, e.g. translation files, 
docs, data, scripts, etc., for the use of a simplified installer 
system.  (Ala the BUILDS proposal of about a year ago.)



From floris.bruynooghe at gmail.com  Sat Sep 12 11:45:17 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Sat, 12 Sep 2009 10:45:17 +0100
Subject: [Distutils] Compile C code and install to script dir?
In-Reply-To: <C6CFFDDB.8384%o.borderline@gmail.com>
References: <C6CFFDDB.8384%o.borderline@gmail.com>
Message-ID: <20090912094517.GA11875@laurie.devork>

On Fri, Sep 11, 2009 at 01:15:07PM -0700, OB wrote:
> I am trying to get distutils to compile a single C script and install the
> binary to the same script directory as the entry point scripts that are
> generated for the python part of the module. I would like to use all the
> includes, CFLAGS, etc that are used when compiling extension modules, but
> this C script is not an extension. Is there a way to do this through setup,
> or do I need to use distutils.ccompiler.new_compiler() and try to hunt down
> CFLAGS, default libs, etc?

(Ignoring the setuptools part of your question as I don't use that,
but I'm pretty sure it's very similar if not the same)

If you don't want to create the compiler the easiest is to extend the
build_ext command:

"""
from distutils.command.build_ext import build_ext

class MyBuildExt(build_ext):
    def run(self):
        build_ext.run(self)
        self.compiler.link_executable(['hello.c'], 'hello')

setup(name='foo',
      ...
      cmdclass = {'build_ext': MyBuildExt})
"""

Here build_ext.run() will be setting all the include dirs, macros,
libs, rpaths etc into the compiler, which is what you want I think.
Obviously play around with the arguments to link_executable(), or you
could do it in 2 steps and create the object files first with
self.compiler.compile() if you want/need.

If you don't want to extend build_ext then you've got to create the
compiler with distutils.ccompiler.new_compiler() and
distutils.sysconfig.customize_compiler().  Hunting down the settings
is a bit harder then, you'll be reading build_ext.finalize_options()
and build_ext.run() to figure this out.

Regards
Floris

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

From floris.bruynooghe at gmail.com  Sat Sep 12 16:42:01 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Sat, 12 Sep 2009 15:42:01 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909111752i5b147a3cx791611ae3a130d45@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<94bdd2610909111752i5b147a3cx791611ae3a130d45@mail.gmail.com>
Message-ID: <20090912144201.GA13831@laurie.devork>

On Sat, Sep 12, 2009 at 02:52:17AM +0200, Tarek Ziad? wrote:
> On Fri, Sep 11, 2009 at 5:49 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> >> I agree that more background and motivational information would be
> >> very helpful, as would some real world examples. I know that >90%
> >> (maybe 99% :) of the packages I distribute don't adapt to their
> >> execution context (beyond what distutils does internally) or need
> >> anything but meta data.
> 
> That's a first draft:
> 
> http://tarekziade.wordpress.com/2009/09/12/static-metadata-for-distutils/

Your example shows an empty setup() call but does not say which
package/module is supposed to be installed.

I'm confused now to how much you would like in setup.cfg.  Is the idea
to leave the package/module/extension module/scripts etc in setup.py?

Regards
Floris

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

From floris.bruynooghe at gmail.com  Sat Sep 12 16:50:36 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Sat, 12 Sep 2009 15:50:36 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090911163232.GB2903@laurie.devork>
	<94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
Message-ID: <20090912145036.GB13831@laurie.devork>

On Fri, Sep 11, 2009 at 07:02:53PM +0200, Tarek Ziad? wrote:
> On Fri, Sep 11, 2009 at 6:32 PM, Floris Bruynooghe
> <floris.bruynooghe at gmail.com> wrote:
> > On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
> > [...]
> >> That can be dropped since we have '==' and it's all strings.
> >
> > '2.6' < '2.10'?
> >
> > Although not close you must be wary of this. ?Bring on PEP 386 ;-)
> 
> Right. Maybe we can drop < >, >= and >=, completely.
> 
> In real world use cases, we can use "or" to make a section work for
> 2.6, 3.1, etc.. for python versions.
> 
> I can't think of a use case where "in" and "==" is not enough.

Version comparison would be nice though.  Taking your example from
your blog post: if I where to try to install that on Python 2.4 I'd
have to edit the condition of the [py25] section to "in ('2.4',
'2.5')".  Maybe this is what you want though, in case you explicitly
don't support for 2.4.  OTOH it's nice if things would just work in
case of developers simply not having tried earlier versions.

This also shows how "in" implies a tuple or a list as data type, your
mini-language was trying to avoid that.  Or did I miss something?


Regards
Floris

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

From sridharr at activestate.com  Sat Sep 12 20:47:29 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sat, 12 Sep 2009 11:47:29 -0700
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090912015723.1F3783A403D@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<94bdd2610909111528w527c9455madf4d32a9b9373fa@mail.gmail.com>
	<20090912002522.DE0D93A403D@sparrow.telecommunity.com>
	<94bdd2610909111750p55af1383ocb5708c5fd848352@mail.gmail.com>
	<20090912015723.1F3783A403D@sparrow.telecommunity.com>
Message-ID: <op.uz5qhcmk1q4jlt@homeless.vn.shawcable.net>

On Fri, 11 Sep 2009 18:57:28 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 02:50 AM 9/12/2009 +0200, Tarek Ziad? wrote:
> it means that we can even provide an XML-RPC service at PyPI so people
> can query the metadata for their platform with zero download and zero
> third-party
> code execution.
>  Ah, now that does sound rather useful, as it would allow installation  
> and similar tools to resolve dependencies without first needing to build  
> or download binaries.

Yes, it is useful. PyPM relies on this 'static metadata', as fetched from  
PKG-INFO and requires.txt, *before* building the packages (on the backend  
server). If the package developer used a configure.py like mechanism to  
*conditionally* generate this PKG-INFO or requires.txt before uploading  
the tarball, then PyPM will use *that* metadata for all of the platforms  
... which is not we want.

I'm +1 on Tarek's proposal actually .. although Jim Fulton has a point  
regarding having conditionals in setup.cfg.

Regardless of the specifics, installer tools should be able to query the  
metadata for a given system (not current system). For example, one should  
be able to do something like this on Linux and Python-2.6:

   >> metadata = read_metadata('/path/to/source')
   >> metadata.get_install_requires_for(pyver=(2,5), osname='win32')

And this should happen without any execution of setup.py.

-srid

From ziade.tarek at gmail.com  Sun Sep 13 00:31:33 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 13 Sep 2009 00:31:33 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090912144201.GA13831@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<94bdd2610909111752i5b147a3cx791611ae3a130d45@mail.gmail.com>
	<20090912144201.GA13831@laurie.devork>
Message-ID: <94bdd2610909121531s63e3eb6bjd6c1b7a0140e46a0@mail.gmail.com>

On Sat, Sep 12, 2009 at 4:42 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> On Sat, Sep 12, 2009 at 02:52:17AM +0200, Tarek Ziad? wrote:
>> On Fri, Sep 11, 2009 at 5:49 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> >> I agree that more background and motivational information would be
>> >> very helpful, as would some real world examples. I know that >90%
>> >> (maybe 99% :) of the packages I distribute don't adapt to their
>> >> execution context (beyond what distutils does internally) or need
>> >> anything but meta data.
>>
>> That's a first draft:
>>
>> http://tarekziade.wordpress.com/2009/09/12/static-metadata-for-distutils/
>
> Your example shows an empty setup() call but does not say which
> package/module is supposed to be installed.

I'll complete it, right.

>
> I'm confused now to how much you would like in setup.cfg. ?Is the idea
> to leave the package/module/extension module/scripts etc in setup.py?

The target is to push all fields that belong to the Metadata (see PEP 314)
in the static file.

So anything else required by a command would stay in setup.py

Regards
Tarek

From ziade.tarek at gmail.com  Sun Sep 13 00:37:09 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 13 Sep 2009 00:37:09 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090912145036.GB13831@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090911163232.GB2903@laurie.devork>
	<94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
	<20090912145036.GB13831@laurie.devork>
Message-ID: <94bdd2610909121537i415d0014h5055ab369512bb48@mail.gmail.com>

On Sat, Sep 12, 2009 at 4:50 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
>>
>> I can't think of a use case where "in" and "==" is not enough.
>
> Version comparison would be nice though. ?Taking your example from
> your blog post: if I where to try to install that on Python 2.4 I'd
> have to edit the condition of the [py25] section to "in ('2.4',
> '2.5')".

or simply do:

"""
condition: python_version ==  '2.4' or python_version == '2.5'
"""

It's more verbose, but I don't think it's too bad

>?Maybe this is what you want though, in case you explicitly
> don't support for 2.4. ?OTOH it's nice if things would just work in
> case of developers simply not having tried earlier versions.
>
> This also shows how "in" implies a tuple or a list as data type, your
> mini-language was trying to avoid that. ?Or did I miss something?

I was thinking about the "in" operator exclusively restricted to strings.
for example:

"""
condition: 'i386' in os_machine
"""

In real python, that would be: 'i386' in os.uname()[-1]

From greg.ewing at canterbury.ac.nz  Sun Sep 13 02:56:02 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 13 Sep 2009 12:56:02 +1200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
Message-ID: <4AAC4322.8060508@canterbury.ac.nz>

Tarek Ziad? wrote:

 > [setup]
 > foo: bar
 > conditional-sections: one, two

Is conditional-sections: really necessary? Isn't the
presence of a conditions: line in a section enough to
mark it as conditional?

-- 
Greg

From glyph at twistedmatrix.com  Mon Sep 14 16:13:55 2009
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Mon, 14 Sep 2009 10:13:55 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
Message-ID: <d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>

On Fri, Sep 11, 2009 at 1:40 PM, Jim Fulton <jim at zope.com> wrote:

> On Fri, Sep 11, 2009 at 11:49 AM, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
> > On Fri, Sep 11, 2009 at 5:36 PM, Jim Fulton <jim at zope.com> wrote:
> >> On Fri, Sep 11, 2009 at 11:14 AM, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
> >>> 2009/9/11  <exarkun at twistedmatrix.com>:
> >>>> On 02:33 pm, ziade.tarek at gmail.com wrote:
> >>>> I'm a little skeptical about creating a new mini language
> (particularly one
> >>>> with branching) for setup.cfg,
> >>
> >> Me too.
>

Me three.  Even after hearing the motivating use-cases, like:

> So you can for example define a list of dependencies that changes wether
> > you are under windows or linux, etc..
>
> OK. I've never had that situation. I'm sure someone has, but it
> doesn't see common.


Twisted actually has this.  On Windows, we need pywin32 to implement many of
the features which can be implemented with just the stdlib on Posix.  But
this is the only thing I can imagine computing based on the execution
environment.

> try to run this with lxml source tarball:
> >
> > $ python setup.py --name
> >
> > I don't know what it is doing, but a whole lot more that what it is
> > suppose to do
> > just to let me know the 'name' metadata.
> >
> > So if name was in setup.cfg, it would be better.
>

One big problem I have with this discussion is that it seems to be
approaching the whole problem backwards.  Distutils projects seem to have a
history of defining new file formats rather than or before new APIs.
 (PKG-INFO, MANIFEST.in, egg-info, etc etc).

I may be missing some context, but I did about an hour of googling around
before responding here, and for the life of me I can't find a simple answer
to the question: how do I currently programatically get the metadata out of
a distribution?

The answer seems to be a bizarre combination of running setup.py, maybe
reading PKG-INFO, maybe something to do with egg-info...?  Or maybe making
some direct calls with xmlrpclib?  Or setuptools?  Setuptools must be able
to do it internally, but I can't find an API in the documentation.

Before trying to make the metadata static, let's try to have the metadata,
for real, at all.  Here's an example of something I want to be able to do
with metadata:

from distutils.something import (
    load_metadata, pypi_metadata, installed_metadata)
meta = installed_metadata("Twisted")
meta2 = load_metadata("/home/glyph/Downloads/Twisted-x.y")
meta3 = pypi_metadata("Twisted")
if meta2.version > meta.version:
    print 'More recent version of Twisted already downloaded!'
if meta3.version > meta2.version:
    print 'More recent version of Twisted is available online!'


Important points here:

   - I can get the same metadata, in the same format, from PyPI, from a
   directory containing the distribution, and from my installed system.
   - There are supported functions that abstract this stuff away for me.
    Working with the packages, I don't have to know how the metadata is
   actually declared.
   - There is a single data structure, hopefully with some API documentation
   I can look at.

Now, maybe the data structure that I want already exists and I just don't
know about it (is it a distutils Distribution, maybe?) but it's certainly
hard to get a handle on one.

In order to be useful, the code that loads this metadata is going to need to
execute setup.py sometimes anyway.  Tarek, as you said in your blog post,
"there will always be edge cases".  So it doesn't seem too useful to be
focusing on getting rid of that requirement right away.  And when you
download from PyPI, you probably eventually have to execute a bunch of
untrusted code that somebody uploaded to a wiki, as root.  Again it would be
nice to fix that, but we have a long way to go :).

For what it's worth, on the implementation side of things, I think that the
library code on the client side should receive enough metadata that it can
do the job of applying the execution environment locally.  I don't
necessarily want to send pypi a bunch of information about my machine just
to figure out what distutils would tell me if I tried to install something.

If there were such an API then setup.cfg would simply be a small
implementation detail.  The problem with lxml will still need to be
addressed, by promoting awareness of the fact that your setup.py may be
executed to do things other than install or submit your package.  Before
adding conditional support to setup.cfg I would want to have a separate
'metadata.py' whose responsibilities were clearer: just produce the
metadata, don't do any pre-build steps.  Ideally that would be easy to load
correctly from setup.py as well.

Inspecting metadata could also be made easier by having an API more like
this for setup.py:

d = Distribution(... metadata ....)
if d.installing:
    my_project.custom_prepare_for_build()
d.setup()

since you can't really tell what setup() is going to do until you've already
called it.

So finally, if there's still no standard programmatic way to get at the
distribution metadata after setup.cfg is modified to have conditional
expressions in it, what exactly is the point?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090914/519c2650/attachment.htm>

From faassen at startifact.com  Mon Sep 14 16:28:42 2009
From: faassen at startifact.com (Martijn Faassen)
Date: Mon, 14 Sep 2009 16:28:42 +0200
Subject: [Distutils] [buidout] ignoring site-packages
Message-ID: <h8ljus$f1o$1@ger.gmane.org>

Hi there,

A long-standing issue with using buildout is that even though it creates 
a restricted environment, it still uses the site-packages of the system 
python and there's no way to get rid of it. This is why for instance the 
Grok project tells people to create their buildouts within a "virtualenv 
--no-site-packages" virtual env. Because if we don't, a lot of people 
(especially all Mac OS X users that don't create their own python) will 
have a failing buildout due to conflicting libraries.

The following code snippet could be added to the buildout-generated 
scripts, after the 'sys.path[:]' assignment:

import site
packages = set(sys.path)
site_packages = set()
site.addsitepackages(site_packages)
packages = packages.difference(site_packages)
sys.path = list(packages)

This cleans all site packages out of sys.path before any further code is 
executed.

How to make sure we run without site packages? We could of course add an 
option to buildout when it's run:

$ bin/buildout --no-site-packages

Unfortunately this would mean all buildout users would need to remember 
this. It therefore seems sensible to me to also add one to buildout.cfg:

[buildout]
no-site-packages = true

What do people think?

See also this bug:

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

Regards,

Martijn


From chris at simplistix.co.uk  Mon Sep 14 17:04:51 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 14 Sep 2009 16:04:51 +0100
Subject: [Distutils] [buidout] ignoring site-packages
In-Reply-To: <h8ljus$f1o$1@ger.gmane.org>
References: <h8ljus$f1o$1@ger.gmane.org>
Message-ID: <4AAE5B93.2050800@simplistix.co.uk>

Martijn Faassen wrote:
> A long-standing issue with using buildout is that even though it creates 
> a restricted environment, it still uses the site-packages of the system 

I thought the --no-site-packages stuff had already been implemented and 
was just waiting for Jim to review the branch?

cheers,

Chris

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

From ziade.tarek at gmail.com  Mon Sep 14 17:05:24 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Sep 2009 17:05:24 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
Message-ID: <94bdd2610909140805p5e337c50p6433ace5f2073cfc@mail.gmail.com>

On Mon, Sep 14, 2009 at 4:13 PM, Glyph Lefkowitz
<glyph at twistedmatrix.com> wrote:
> I may be missing some context, but I did about an hour of googling around
> before responding here, and for the life of me I can't find a simple answer
> to the question: how do I currently programatically get the metadata out of
> a distribution?

You can't do it with Distutils to get metadata of installed distributions.

If you have the source, you can just do :

$ python setup.py --field

(where field is the metadata - PEP 314)

This need you are describing is exactly the purpose of PEP 376 in fact.


> The answer seems to be a bizarre combination of running setup.py, maybe
> reading PKG-INFO, maybe something to do with egg-info...? ?Or maybe making
> some direct calls with xmlrpclib? ?Or setuptools? ?Setuptools must be able
> to do it internally, but I can't find an API in the documentation.
> Before trying to make the metadata static, let's try to have the metadata,
> for real, at all. ?Here's an example of something I want to be able to do
> with metadata:
>
> from distutils.something import (
> ?? ?load_metadata, pypi_metadata, installed_metadata)
> meta = installed_metadata("Twisted")
> meta2 = load_metadata("/home/glyph/Downloads/Twisted-x.y")
> meta3 = pypi_metadata("Twisted")
> if meta2.version > meta.version:
> ?? ?print 'More recent version of Twisted already downloaded!'
> if meta3.version > meta2.version:
> ?? ?print 'More recent version of Twisted is available online!'
>
> Important points here:
>
> I can get the same metadata, in the same format, from PyPI, from a directory
> containing the distribution, and from my installed system.
> There are supported functions that abstract this stuff away for me. ?Working
> with the packages, I don't have to know how the metadata is actually
> declared.
> There is a single data structure, hopefully with some API documentation I
> can look at.
>
> Now, maybe the data structure that I want already exists and I just don't
> know about it (is it a distutils Distribution, maybe?) but it's certainly
> hard to get a handle on one.

Basically, what you are describing is PKG-INFO, the file that contains all
metadata, and that's what PyPI sends you back through XLM RPC.

And the static setup.cfg [setup] section ressembles a lot at the final PKG-INGO
the Distribution class creates.

For installed packages, setuptools does provides a similar feature
through it's pkg_resources module, which knows how to look for the PKG-INFO file
of a given distribution in your system (several format exists, it can
be an egg-info file, or
a PKG-INFO file inside an egg info directory. PEP 376 tries
to put a standard on that)

So yes, your example would be what we would want, and if we add the
static setup.cfg thing in distutils, an API would be able to send you back the
metadata as they wil be in the PKG-INFO

> In order to be useful, the code that loads this metadata is going to need to
> execute setup.py sometimes anyway.

Not sure to understand, when installing you mean ?

> Tarek, as you said in your blog post,
> "there will always be edge cases". ?So it doesn't seem too useful to be
> focusing on getting rid of that requirement right away. ?And when you
> download from PyPI, you probably eventually have to execute a bunch of
> untrusted code that somebody uploaded to a wiki, as root. ?Again it would be
> nice to fix that, but we have a long way to go :).
> For what it's worth, on the implementation side of things, I think that the
> library code on the client side should receive enough metadata that it can
> do the job of applying the execution environment locally. ?I don't
> necessarily want to send pypi a bunch of information about my machine just
> to figure out what distutils would tell me if I tried to install something.

Right, that's a good point the execution could be on client-side,
that wouldn't matter.

I kinda like the zero download principle though, to query PyPI on distributions
that fits your target system.

> If there were such an API then setup.cfg would simply be a small
> implementation detail. ?The problem with lxml will still need to be
> addressed, by promoting awareness of the fact that your setup.py may be
> executed to do things other than install or submit your package. ?Before
> adding conditional support to setup.cfg I would want to have a separate
> 'metadata.py' whose responsibilities were clearer: just produce the
> metadata, don't do any pre-build steps. ?Ideally that would be easy to load
> correctly from setup.py as well.

That wouldn't be different from setup.py I guess, because as long as you
let people write a Python module they can do whatever they want.

Now if we say  "metadata.py" is:
- a module that returns an instance of the Distribution class, that we
use in setup.py
- shall not have any dependency except vanilla python
- executed whith a restricted list of paths (basically, just Python's lib)

That would be better than the current situation.

But in any case, this is not opposed to what we've proposed for
setup.cfg, it could
be combined imho.

For clarity, maybe the [setup] section should be replaced by a plain PKG-INFO
file alongside setup.py and setup.cfg, that is loaded by the Distribution class
with the micro-language still present.

So we're "PKG-INFO"-ing at every stage (pypi, installed package,
source directory)


Tarek

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

From faassen at startifact.com  Mon Sep 14 23:11:27 2009
From: faassen at startifact.com (Martijn Faassen)
Date: Mon, 14 Sep 2009 23:11:27 +0200
Subject: [Distutils] [buidout] ignoring site-packages
In-Reply-To: <4AAE5B93.2050800@simplistix.co.uk>
References: <h8ljus$f1o$1@ger.gmane.org> <4AAE5B93.2050800@simplistix.co.uk>
Message-ID: <h8mbhv$81u$1@ger.gmane.org>

Chris Withers wrote:
> Martijn Faassen wrote:
>> A long-standing issue with using buildout is that even though it 
>> creates a restricted environment, it still uses the site-packages of 
>> the system 
> 
> I thought the --no-site-packages stuff had already been implemented and 
> was just waiting for Jim to review the branch?

I hadn't realized Gary did so much work. I glanced at the branch briefly 
today and it looked very interesting. I'm looking forward to seeing 
those features. (And thanks to Gary if he's listening!)

Regards,

Martijn


From o.borderline at gmail.com  Tue Sep 15 00:10:31 2009
From: o.borderline at gmail.com (OB)
Date: Mon, 14 Sep 2009 15:10:31 -0700
Subject: [Distutils] Compile C code and install to script dir?
In-Reply-To: <20090912094517.GA11875@laurie.devork>
Message-ID: <C6D40D67.83FD%o.borderline@gmail.com>

Thank you for the quick response. Unfortunately, there are still a few
difficulties I am having.

One issue is that I do not have an Extention in this package to piggyback
the hello.c -> hello compilation onto. This compilation would also be
performed for /every/ Extension given in ext_modules. If no extensions are
given, the compilation never happens. If files that are not really python
extensions are given, distutils crashes when trying to construct the egg
because there is no real extension.

Another issue for me is that the link_executable command seems to not
include data the environment variable LDPATH, unlike link_shared_object and
preprocess. This isn't a huge deal, but it meant that I had to manually
insert the LDPATH flags into link_executable's extra_preargs

If, instead of overriding build_ext, I try to do this outside of setup, a
few issues get much harder. Without access to build_ext's self.build_temp
and self.build_lib, how do I put the compiled binary into the right egg
directory? 

Any further advice would be greatly appreciated!
-Orion

On 9/12/09 2:45 am, "Floris Bruynooghe" <floris.bruynooghe at gmail.com> wrote:

> On Fri, Sep 11, 2009 at 01:15:07PM -0700, OB wrote:
>> I am trying to get distutils to compile a single C script and install the
>> binary to the same script directory as the entry point scripts that are
>> generated for the python part of the module. I would like to use all the
>> includes, CFLAGS, etc that are used when compiling extension modules, but
>> this C script is not an extension. Is there a way to do this through setup,
>> or do I need to use distutils.ccompiler.new_compiler() and try to hunt down
>> CFLAGS, default libs, etc?
> 
> (Ignoring the setuptools part of your question as I don't use that,
> but I'm pretty sure it's very similar if not the same)
> 
> If you don't want to create the compiler the easiest is to extend the
> build_ext command:
> 
> """
> from distutils.command.build_ext import build_ext
> 
> class MyBuildExt(build_ext):
>     def run(self):
>         build_ext.run(self)
>         self.compiler.link_executable(['hello.c'], 'hello')
> 
> setup(name='foo',
>       ...
>       cmdclass = {'build_ext': MyBuildExt})
> """
> 
> Here build_ext.run() will be setting all the include dirs, macros,
> libs, rpaths etc into the compiler, which is what you want I think.
> Obviously play around with the arguments to link_executable(), or you
> could do it in 2 steps and create the object files first with
> self.compiler.compile() if you want/need.
> 
> If you don't want to extend build_ext then you've got to create the
> compiler with distutils.ccompiler.new_compiler() and
> distutils.sysconfig.customize_compiler().  Hunting down the settings
> is a bit harder then, you'll be reading build_ext.finalize_options()
> and build_ext.run() to figure this out.
> 
> Regards
> Floris



From pje at telecommunity.com  Tue Sep 15 01:05:06 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 14 Sep 2009 19:05:06 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.co
 m>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
Message-ID: <20090914230506.7ACCB3A4069@sparrow.telecommunity.com>

At 10:13 AM 9/14/2009 -0400, Glyph Lefkowitz wrote:
>Setuptools must be able to do it internally, but I can't find an API 
>in the documentation.

The only time setuptools pays any attention to PKG-INFO metadata is 
to get a package's version when the filename isn't enough to 
determine it - something that usually happens only on an 
in-development copy of a package.

All of the metadata that it uses comes from setuptools-defined files, 
and is provided via the API of Distribution objects:

http://peak.telecommunity.com/DevCenter/PkgResources#distribution-objects


From david.lyon at preisshare.net  Tue Sep 15 02:24:43 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 14 Sep 2009 20:24:43 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
Message-ID: <b425edbbe1b7e1f29bcc36e1904a3667@preisshare.net>

On Mon, 14 Sep 2009 10:13:55 -0400, Glyph Lefkowitz wrote:
>> >>>> I'm a little skeptical about creating a new mini language
>> (particularly one
>> >>>> with branching) for setup.cfg,
>> >>
>> >> Me too.
>>
> 
> Me three.  Even after hearing the motivating use-cases, like:
> 
>> So you can for example define a list of dependencies that changes wether
>> > you are under windows or linux, etc..

Me four.

>> OK. I've never had that situation. I'm sure someone has, but it
>> doesn't see common.

If you follow answers and questions posted to distutils list you
notice after a while that windows users get less answers to
questions on distutils relatated questions. Linux a little more.

I have come to conclude that "edge-cases" just means windows
or to a less degree linux users. It's a distutils sort of keyword 
for people that don't get acknowledged as even existing.

Is it distutils platform bias? I wonder..


> Twisted actually has this.  On Windows, we need pywin32 to implement many
> of
> the features which can be implemented with just the stdlib on Posix.  But
> this is the only thing I can imagine computing based on the execution
> environment.

It's true for many windows packages.

> One big problem I have with this discussion is that it seems to be
> approaching the whole problem backwards.  Distutils projects seem to have
a
> history of defining new file formats rather than or before new APIs.
>  (PKG-INFO, MANIFEST.in, egg-info, etc etc).

And also a history of being highly selective about who can be blessed
to work on code. I think windows programmers have substantially reduced
chances of making contributions.

> I may be missing some context, but I did about an hour of googling around
> before responding here, and for the life of me I can't find a simple
answer
> to the question: how do I currently programatically get the metadata out
of
> a distribution?

That's easy....

Here's a workhorse file you can get from the python package manager..

http://pythonpkgmgr.svn.sourceforge.net/viewvc/pythonpkgmgr/Packaging.py?revision=103&view=markup

At the command line:

C:\Documents and Settings\DL\Desktop\pythonpkgmgr>python packaging.py
--metadata
 pygame
Package Manager Test
 - using configuration file C:\Documents and
Settings\DL\Desktop\pythonpkgmgr\py
thonpkgmgr.ini
 - Changing to python 2.6 in C:\Python26\
 - checking package
Metadata is as follows:
['Metadata-Version: 1.0\n', 'Name: pywin32\n', 'Version: 214\n', 'Summary:
Pytho
n for Window Extensions\n', 'Home-page:
http://sourceforge.net/projects/pywin32/
\n', 'Author: Mark Hammond (et al)\n', 'Author-email:
mhammond at users.sourceforge
.net\n', 'License: PSF\n', 'Description: Python extensions for Microsoft
Windows
\n', '        Provides access to much of the Win32 API, the\n', '       
ability
 to create and use COM objects, and the\n', '        Pythonwin
environment.\n',
'Platform: UNKNOWN\n']

In code:

pm = PackageManager()
info = pm.package_information("pygame")
print " - checking package %s" % package
if "PKG-INFO" in info.keys():
    print "Metadata is as follows:"
    print info["PKG-INFO"]
else:
    print "No Metadata found"

> The answer seems to be a bizarre combination of running setup.py, maybe
> reading PKG-INFO, maybe something to do with egg-info...?  Or maybe
making
> some direct calls with xmlrpclib?  Or setuptools?  Setuptools must be
able
> to do it internally, but I can't find an API in the documentation.

You're right. Distutils can't do it at the moment.

> Before trying to make the metadata static, let's try to have the
metadata,
> for real, at all.  Here's an example of something I want to be able to do
> with metadata:
> 
> from distutils.something import (
>     load_metadata, pypi_metadata, installed_metadata)
> meta = installed_metadata("Twisted")
> meta2 = load_metadata("/home/glyph/Downloads/Twisted-x.y")
> meta3 = pypi_metadata("Twisted")
> if meta2.version > meta.version:
>     print 'More recent version of Twisted already downloaded!'
> if meta3.version > meta2.version:
>     print 'More recent version of Twisted is available online!'

+1

> So finally, if there's still no standard programmatic way to get at the
> distribution metadata after setup.cfg is modified to have conditional
> expressions in it, what exactly is the point?

Originally, we could only have conditional 'code' in programs. But now
there's a push to move it out of python code and create a new mini
language (that isn't python) stored within configuration files.

The end result will be two languages (python and the new language) sitting
in two places (setup.py and setup.cfg) able to do exactly the same thing.

I think that will get confusing.. especially for us windows users...

We've never been allowed to have code in configuration files..
  
So I am watching to see how this one pans out...

David




From ziade.tarek at gmail.com  Tue Sep 15 09:16:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 09:16:01 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AAC4322.8060508@canterbury.ac.nz>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
Message-ID: <94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>

On Sun, Sep 13, 2009 at 2:56 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Tarek Ziad? wrote:
>
>> [setup]
>> foo: bar
>> conditional-sections: one, two
>
> Is conditional-sections: really necessary? Isn't the
> presence of a conditions: line in a section enough to
> mark it as conditional?

I find having a conditional section explicitely defined better that
doing a convention on names because if someone implements
a command that uses that name (it's likely to be improbable but...)
it will break his ability to use setup.cfg to give options to his commands

Tarek


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

From greg.ewing at canterbury.ac.nz  Tue Sep 15 10:47:16 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 15 Sep 2009 20:47:16 +1200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
Message-ID: <4AAF5494.9090207@canterbury.ac.nz>

Tarek Ziad? wrote:

> I find having a conditional section explicitely defined better that
> doing a convention on names because if someone implements
> a command that uses that name (it's likely to be improbable but...)
> it will break his ability to use setup.cfg to give options to his commands

I don't follow that. If a "conditions:" line is being
used to express the condition, then you can't use the
name "conditions" for anything else anyway.

-- 
Greg

From ziade.tarek at gmail.com  Tue Sep 15 11:00:41 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 11:00:41 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AAF5494.9090207@canterbury.ac.nz>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
Message-ID: <94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>

On Tue, Sep 15, 2009 at 10:47 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Tarek Ziad? wrote:
>
>> I find having a conditional section explicitely defined better that
>> doing a convention on names because if someone implements
>> a command that uses that name (it's likely to be improbable but...)
>> it will break his ability to use setup.cfg to give options to his commands
>
> I don't follow that. If a "conditions:" line is being
> used to express the condition, then you can't use the
> name "conditions" for anything else anyway.

setupt.cfg is also used by commands that is.

Imagine a command with the name "foo", that has an option called "condition".

The setup.cfg file might look like this:

"""
[global]
verbose: 1

[setup]
name: MyDistribution
version: 1.0

[only_windows]
condition: sys_platform == 'win32'
requires: pywin32

[foo]
verbose: 1
condition: badababdalolo
""""

Here, the foo section is not supposed to be used by the setup section,
it's just a section for the command value, which is allowed (see
http://docs.python.org/distutils/configfile.html)

Now Distutils, if told to grab all sections that have a "condition"
variable in them, will fail at reading "badababdalolo".

With an explicit list of the conditional sections, the probelm can't
occur, because it's explicit:

"""
[global]
verbose: 1

[setup]
name: MyDistribution
version: 1.0

conditional-sections: only_windows

[only_windows]
condition: sys_platform == 'win32'
requires: pywin32

[foo]
verbose: 1
condition: badababdalolo
""""

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

From jeff at taupro.com  Tue Sep 15 13:34:06 2009
From: jeff at taupro.com (Jeff Rush)
Date: Tue, 15 Sep 2009 06:34:06 -0500
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<4AAC4322.8060508@canterbury.ac.nz>	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
Message-ID: <4AAF7BAE.2010506@taupro.com>

Tarek Ziad? wrote:
> 
> Imagine a command with the name "foo", that has an option called "condition".
> 
> The setup.cfg file might look like this:
> 
> """
> [global]
> verbose: 1
> 
> [setup]
> name: MyDistribution
> version: 1.0
> 
> [only_windows]
> condition: sys_platform == 'win32'
> requires: pywin32
> 
> [foo]
> verbose: 1
> condition: badababdalolo
> """"
> 
> Here, the foo section is not supposed to be used by the setup section,
> it's just a section for the command value, which is allowed (see
> http://docs.python.org/distutils/configfile.html)

Ooh, nasty.  I would -want- this case to error out because it could
introduce a hard to find problem.  Perhaps that condition: is intended
for use by [setup] but a tired person forgot to list it in [setup].  He
keeps looking at his setup.cfg and cannot see why it doesn't use his
condition.  I'd rather a big error popped up than a silent ambiguity.

-Jeff

From ziade.tarek at gmail.com  Tue Sep 15 13:38:22 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 13:38:22 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AAF7BAE.2010506@taupro.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<4AAF7BAE.2010506@taupro.com>
Message-ID: <94bdd2610909150438w20424c95r1d093cd375e25aa@mail.gmail.com>

On Tue, Sep 15, 2009 at 1:34 PM, Jeff Rush <jeff at taupro.com> wrote:
> Tarek Ziad? wrote:
>>
>> Imagine a command with the name "foo", that has an option called "condition".
>>
>> The setup.cfg file might look like this:
>>
>> """
>> [global]
>> verbose: 1
>>
>> [setup]
>> name: MyDistribution
>> version: 1.0
>>
>> [only_windows]
>> condition: sys_platform == 'win32'
>> requires: pywin32
>>
>> [foo]
>> verbose: 1
>> condition: badababdalolo
>> """"
>>
>> Here, the foo section is not supposed to be used by the setup section,
>> it's just a section for the command value, which is allowed (see
>> http://docs.python.org/distutils/configfile.html)
>
> Ooh, nasty. ?I would -want- this case to error out because it could
> introduce a hard to find problem. ?Perhaps that condition: is intended
> for use by [setup] but a tired person forgot to list it in [setup]. ?He
> keeps looking at his setup.cfg and cannot see why it doesn't use his
> condition. ?I'd rather a big error popped up than a silent ambiguity.

Another options is to prefix those sections that are to be used with [setup]:

"""
[global]
verbose: 1

[setup]
name: MyDistribution
version: 1.0

[setup:only_windows]
condition: sys_platform == 'win32'
requires: pywin32

[setup:only_mac]
condition: sys_platform == 'darwin'
requires: pywin32

[foo]
verbose: 1
condition: badababdalolo
""""


>
> -Jeff
>



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

From floris.bruynooghe at gmail.com  Tue Sep 15 17:44:00 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 15 Sep 2009 16:44:00 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909150438w20424c95r1d093cd375e25aa@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<4AAF7BAE.2010506@taupro.com>
	<94bdd2610909150438w20424c95r1d093cd375e25aa@mail.gmail.com>
Message-ID: <20090915154400.GA21452@laurie.devork>

On Tue, Sep 15, 2009 at 01:38:22PM +0200, Tarek Ziad? wrote:
> Another options is to prefix those sections that are to be used with [setup]:
> 
> """
> [global]
> verbose: 1
> 
> [setup]
> name: MyDistribution
> version: 1.0
> 
> [setup:only_windows]
> condition: sys_platform == 'win32'
> requires: pywin32
> 
> [setup:only_mac]
> condition: sys_platform == 'darwin'
> requires: pywin32
> 
> [foo]
> verbose: 1
> condition: badababdalolo
> """"

That's quite nice, +1
And is it worth to consider erroring out when you have a [setup:.*]
section without a "condition: ..." line?

Regards
Floris

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

From floris.bruynooghe at gmail.com  Tue Sep 15 17:46:59 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 15 Sep 2009 16:46:59 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
Message-ID: <20090915154659.GB21452@laurie.devork>

On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
> Also, I've just realized that uname() is a tuple, so I need to flatten
> it in strings to restrict the grammar:
> 
> - os_sysname
> - os_nodename
> - os_release
> - os_version
> - os_machine

When I asked for this I was imagening (wrongly) way more to go in
setup.cfg then just the meta-data.  To be honest in that case I don't
think I've got a use for os.uname() to be available.  While nothing is
wrong with having it, if no one else thinks they need it maybe it's
unnecessary complication?

Regards
Floris

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

From wentland at cl.uni-heidelberg.de  Tue Sep 15 17:38:57 2009
From: wentland at cl.uni-heidelberg.de (Wolodja Wentland)
Date: Tue, 15 Sep 2009 17:38:57 +0200
Subject: [Distutils] Get install prefix for module at runtime
Message-ID: <20090915153857.GB17381@kinakuta.local>

Hi all,

i am pretty new to distutils (since yesterday)  and am struggling with
accessing installed data_files. I want to ship a library that benefits
from some data_files from another package.

My wishes:

    * distribution should go in 'PREFIX/lib/foo' (site-packages?)
    * datafiles should go in 'PREFIX/share/foo'
    * Access to data files from modules

My question is: "How to reliably access data files from a module in
foo?"

A thorough explanation follows. If you can answer the aforementioned
question just think tl;dr and skip it ;-)

Installation Schemes
====================

There seem to be three different installation schemes regarding setting
of this PREFIX. The following examples assume installation of package
'foo' which contains module 'bar' and data file 'baz.data'.

Default install (setup.py install)
-----------------------------------------

* Packages installation path:
    'sys.prefix/lib/pythonX.Y/site-packages/'

* Data files installation path:
    'sys.prefix/share/'

That means that in the aforementioned example the following file system
structure will be created upon installation:

Package:    /usr/lib/python2.5/site-packages/foo/bar.py
Data:       /usr/share/foo/baz.data

Home scheme (setup.py install --home=HOME)
---------------------------------------

* Packages installation path:
    'HOME/lib/python'

* Data files installation path:
    'HOME/share/'

Resulting structure:

Package:    HOME/lib/foo/bar.py
Data        HOME/share/foo/baz.data

Prefix scheme (setup.py --prefix=PREFIX)

* Package installation path:
    'PREFIX/lib/pythonX.Y/site-packages'

* Data installation path:
    'PREFIX/share/'

Resulting structure (for PREFIX==/usr/local)

Package:    /usr/local/lib/python2.5/site-packages/foo/bar.py
Data:       /usr/share/foo/baz.data

Finding Data files
==================

My problem is finding a reliable way to access the data files from
within bar.py.

Approach 1 - using module.__file__
----------------------------------

bar_path_elements = bar.__file__.split(os.path.sep)
prefix = os.path.join(
            os.path.sep,
            *itertools.takewhile(lambda el: el != 'lib'))

data_file_path = os.path.join(prefix, 'share', 'foo')

* Will this work reliably? 

* What if the user specifies a different data directory with
  '--install-data' ?

Approach 2 - writing a build.py file at installation time
---------------------------------------------------------

The last question made me think, that Approach 1 works for the three
standard installation schemes, but fails miserably if the user decides
to do anything fancy. As i do not comprehend all the options you can give
to 'setup.py install' or know about them i am not sure if there are not
many more problems hidden in there.

The solution seems to be to create a build.py file that includes this
information at installation time and access the data there. My problem
is just: HOW?

I tried with the following setup.py script, but am unsure how to access
the correct options:

--- snip ---
# -*- coding: UTF-8 -*-
#!/usr/bin/env python

from __future__ import with_statement

from distutils.core import setup
import sys
import getopt

def create_build_file():
    try:
        opts, args = getopt.getopt(sys.argv[1:], "", [])
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            What to do here????

    except getopt.GetoptError, err:
        pass

    with open('lib/mwdb/build.py', 'w') as build_fp:
        #build_fp.write('# -*- coding: UTF-8 -*-\n')
        #build_fp.write("LIB_PREFIX = '%s'\n"%(options.lib_prefix))
        #build_fp.write("DATA_PREFIX = '%s'\n"%(options.data_prefix))
        #build_fp.write("EXEC_PREFIX = '%s'\n"%(options.exec_prefix))

try:
    if 'install' == sys.argv[1]:
        create_build_file()
except IndexError:
    pass

 

setup(name='foo',
      version='0.1',
      packages=['foo']
      package_dir = { '':'lib' },
      ...
     )
--- snip ---

The problem i am facing now is: How to parse the options? Do I really have
to recreate the complete distutils option parsing logic - and probably
fail? All that without optparse! How can i get the aforementioned
options? Is the file creation way the correct way to handle this?

I really don't know what to do now and am also wondering why nobody had
that problem before! Are all other libraries shipped with external data
buggy for some installation schemes? How is this normally solved?

with kind regards and thanks for reading all this

    Wolodja Wentland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090915/e9221df5/attachment.pgp>

From ziade.tarek at gmail.com  Tue Sep 15 18:29:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 18:29:01 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090915154659.GB21452@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
Message-ID: <94bdd2610909150929k57e50de2nb956edf57145bba5@mail.gmail.com>

On Tue, Sep 15, 2009 at 5:46 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
>> Also, I've just realized that uname() is a tuple, so I need to flatten
>> it in strings to restrict the grammar:
>>
>> - os_sysname
>> - os_nodename
>> - os_release
>> - os_version
>> - os_machine
>
> When I asked for this I was imagening (wrongly) way more to go in
> setup.cfg then just the meta-data. ?To be honest in that case I don't
> think I've got a use for os.uname() to be available. ?While nothing is
> wrong with having it, if no one else thinks they need it maybe it's
> unnecessary complication?

I guess we could leave them since they don't hurt, and see after a version
if they are not used by people.

os_machine help though, knowing if it's a 32 or 64 bits machine


>
> Regards
> Floris
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From ziade.tarek at gmail.com  Tue Sep 15 18:29:31 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 18:29:31 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090915154400.GA21452@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<4AAF7BAE.2010506@taupro.com>
	<94bdd2610909150438w20424c95r1d093cd375e25aa@mail.gmail.com>
	<20090915154400.GA21452@laurie.devork>
Message-ID: <94bdd2610909150929p1a3e803ex7c52446b1360bd89@mail.gmail.com>

On Tue, Sep 15, 2009 at 5:44 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> That's quite nice, +1
> And is it worth to consider erroring out when you have a [setup:.*]
> section without a "condition: ..." line?

Sure,

From pje at telecommunity.com  Tue Sep 15 18:29:54 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 15 Sep 2009 12:29:54 -0400
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <20090915153857.GB17381@kinakuta.local>
References: <20090915153857.GB17381@kinakuta.local>
Message-ID: <20090915162954.BFFC93A4069@sparrow.telecommunity.com>

At 05:38 PM 9/15/2009 +0200, Wolodja Wentland wrote:
>How is this normally solved?

Installing the data with one project:
http://peak.telecommunity.com/DevCenter/setuptools#including-data-files


Retrieving it from the same or a different project:
http://peak.telecommunity.com/DevCenter/PkgResources#basic-resource-access


(Note: this assumes that the data files in question are static, i.e., 
constant data which does not change.  If by "data" you mean files 
that are actually changed by the programs involved, this is *not* the 
way to do it.)


From ziade.tarek at gmail.com  Tue Sep 15 18:37:47 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 18:37:47 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <20090915162954.BFFC93A4069@sparrow.telecommunity.com>
References: <20090915153857.GB17381@kinakuta.local>
	<20090915162954.BFFC93A4069@sparrow.telecommunity.com>
Message-ID: <94bdd2610909150937p14fc1c19kcfcfdec8c0982926@mail.gmail.com>

On Tue, Sep 15, 2009 at 6:29 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 05:38 PM 9/15/2009 +0200, Wolodja Wentland wrote:
>>
>> How is this normally solved?
>
> Installing the data with one project:
> http://peak.telecommunity.com/DevCenter/setuptools#including-data-files
>
>
> Retrieving it from the same or a different project:
> http://peak.telecommunity.com/DevCenter/PkgResources#basic-resource-access
>
>
> (Note: this assumes that the data files in question are static, i.e.,
> constant data which does not change. ?If by "data" you mean files that are
> actually changed by the programs involved, this is *not* the way to do it.)

Note #2: Beware that this also assumes that you use Setuptools instead
of Distutils for your project.

Things like "include_package_data" are not part of the Distutils project.

I'll answer for a Distutils solution as soon as I have some time
(hopefully tonight)

Tarek

From sridharr at activestate.com  Tue Sep 15 22:46:08 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 15 Sep 2009 13:46:08 -0700
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
Message-ID: <op.u0bfy60w1q4jlt@whymac>

On Mon, 14 Sep 2009 07:13:55 -0700, Glyph Lefkowitz  
<glyph at twistedmatrix.com> wrote:

>> So you can for example define a list of dependencies that changes wether
>> > you are under windows or linux, etc..
>>
>> OK. I've never had that situation. I'm sure someone has, but it
>> doesn't see common.
>
>
> Twisted actually has this.  On Windows, we need pywin32 to implement  
> many of
> the features which can be implemented with just the stdlib on Posix.  But
> this is the only thing I can imagine computing based on the execution
> environment.

I believe virtualenv requires pywin32. Maybe several other Python packages  
too.

> I may be missing some context, but I did about an hour of googling around
> before responding here, and for the life of me I can't find a simple  
> answer
> to the question: how do I currently programatically get the metadata out  
> of
> a distribution?

http://pypi.python.org/pypi/pkginfo/

> [...]  Before
> adding conditional support to setup.cfg I would want to have a separate
> 'metadata.py' whose responsibilities were clearer: just produce the
> metadata, don't do any pre-build steps.  Ideally that would be easy to  
> load
> correctly from setup.py as well.

I double users would follow this proposed convention. Once in a while, I  
stumble upon Python packages that do not even succeed at the "python  
setup.py" stage.

Even if they did, what prevents them from making metadata.py a little more  
sophisticated so as to introduce inadvertent bugs on other platforms?  
(Just today, argparse's new release broke on linux and mac, but not on  
Windows .. due to regex parsing behavior)

I vote for static metadata anyday.

> Inspecting metadata could also be made easier by having an API more like
> this for setup.py:
>
> d = Distribution(... metadata ....)
> if d.installing:
>     my_project.custom_prepare_for_build()
> d.setup()
>
> since you can't really tell what setup() is going to do until you've  
> already
> called it.

I doubt this would happen in practice even if widely suggested by  
distutils/setuptools.

> So finally, if there's still no standard programmatic way to get at the
> distribution metadata after setup.cfg is modified to have conditional
> expressions in it, what exactly is the point?

...

Conditional metadata for Python versions does not have to be very  
complicated in my opinion. Simply have the following in setup.cfg, and  
thus in PKG-INFO:

install_requires = ['lxml', 'multiprocessing[pyver<(2,6)]', 'argparse',  
'pywin32[platform.name=windows]']

>>> metadata.get_install_requires(for_pyver=(2,6),  
>>> platform=Platform(name='windows', arch='x86'))
['lxml', 'argparse', 'pywin32']

I don't imagine fields other than `install_requires` to vary based on the  
target environment.

Simple, no?

-srid

From sridharr at activestate.com  Tue Sep 15 22:54:27 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 15 Sep 2009 13:54:27 -0700
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
Message-ID: <op.u0bgc1b51q4jlt@whymac>

On Tue, 15 Sep 2009 02:00:41 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> [only_windows]
> condition: sys_platform == 'win32'
> requires: pywin32

I am ambivalent about using sys.platform. How do I specify Linux?

    >>> sys.platform
    'linux2'

"linux2"? What are the possible values for `sys.platform`? Is it even a  
well-defined list? What if Linux 3.x comes out .. and the package would  
stop using the conditional dependent package (that is dependent on  
'linux2')?

cf. http://code.google.com/p/platinfo/issues/detail?id=1

-srid


From pje at telecommunity.com  Tue Sep 15 23:12:46 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 15 Sep 2009 17:12:46 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <op.u0bfy60w1q4jlt@whymac>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>
	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>
	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>
	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
	<op.u0bfy60w1q4jlt@whymac>
Message-ID: <20090915211247.3347E3A4069@sparrow.telecommunity.com>

At 01:46 PM 9/15/2009 -0700, Sridhar Ratnakumar wrote:
>Conditional metadata for Python versions does not have to be very
>complicated in my opinion. Simply have the following in setup.cfg, and
>thus in PKG-INFO:
>
>install_requires = ['lxml', 'multiprocessing[pyver<(2,6)]', 'argparse',
>'pywin32[platform.name=windows]']

If you spelled that [python-lt-26] and [platform-windows], it'd even 
be syntax compatible with today's setuptools; there'd just need to be 
a way to specify default "extra" tags to be always 
installed.  (Technically, '.', and '_' characters would be usable as 
well as '-'.)


>I don't imagine fields other than `install_requires` to vary based on the
>target environment.

I have a package or two that change py_modules and the like based on 
environment, but I could probably refactor them to use separate installation.


From ziade.tarek at gmail.com  Tue Sep 15 23:15:04 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Sep 2009 23:15:04 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <op.u0bgc1b51q4jlt@whymac>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<op.u0bgc1b51q4jlt@whymac>
Message-ID: <94bdd2610909151415v207f3245rb1a284894e777c1c@mail.gmail.com>

2009/9/15 Sridhar Ratnakumar <sridharr at activestate.com>:
> On Tue, 15 Sep 2009 02:00:41 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>> [only_windows]
>> condition: sys_platform == 'win32'
>> requires: pywin32
>
> I am ambivalent about using sys.platform. How do I specify Linux?
>
> ? >>> sys.platform
> ? 'linux2'
>
> "linux2"? What are the possible values for `sys.platform`? Is it even a
> well-defined list?

Yes of course,

http://docs.python.org/library/sys.html

os.uname() also give you more details on the platform/


> What if Linux 3.x comes out .. and the package would stop
> using the conditional dependent package (that is dependent on 'linux2')?

The same thing that what would happen when Python 4 is out I guess,
all distributions will have to change their dependencies list (thus
the setup.cfg file)
accordingly in their next release.

>
> cf. http://code.google.com/p/platinfo/issues/detail?id=1
>



> -srid
>
>



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

From wentland at cl.uni-heidelberg.de  Tue Sep 15 23:24:38 2009
From: wentland at cl.uni-heidelberg.de (Wolodja Wentland)
Date: Tue, 15 Sep 2009 23:24:38 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <94bdd2610909150937p14fc1c19kcfcfdec8c0982926@mail.gmail.com>
References: <20090915153857.GB17381@kinakuta.local>
	<20090915162954.BFFC93A4069@sparrow.telecommunity.com>
	<94bdd2610909150937p14fc1c19kcfcfdec8c0982926@mail.gmail.com>
Message-ID: <20090915212438.GA12110@kinakuta.local>

On Tue, Sep 15, 2009 at 18:37 +0200, Tarek Ziad? wrote:
> > At 05:38 PM 9/15/2009 +0200, Wolodja Wentland wrote:

>>> How is this normally solved?

> Note #2: Beware that this also assumes that you use Setuptools instead
> of Distutils for your project.

I don't actually plan to use setuptools but distutils, although i will
definitely consider if there is no other way.

> I'll answer for a Distutils solution as soon as I have some time
> (hopefully tonight)
That would be great!

with kind regards

    Wolodja Wentland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090915/dc49c584/attachment.pgp>

From wentland at cl.uni-heidelberg.de  Tue Sep 15 22:37:16 2009
From: wentland at cl.uni-heidelberg.de (Wolodja Wentland)
Date: Tue, 15 Sep 2009 22:37:16 +0200
Subject: [Distutils] Greylisting?
Message-ID: <20090915203716.GB5522@kinakuta.local>

Hi all,

i've just seen the following in a mail header:

--- snip ---
X-Greylist: delayed 2135 seconds by postgrey-1.31 at albatross;
        Tue, 15 Sep 2009 18:14:38 CEST
--- snip ---

Why do my mail got delayed for more than 35 min? Is there anything I,
as a subscriber to this list, can do about it?

with kind regards

    Wolodja Wentland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090915/a6874e6e/attachment.pgp>

From barry at python.org  Tue Sep 15 23:45:05 2009
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Sep 2009 17:45:05 -0400
Subject: [Distutils] Greylisting?
In-Reply-To: <20090915203716.GB5522@kinakuta.local>
References: <20090915203716.GB5522@kinakuta.local>
Message-ID: <772AC947-16D3-4748-B118-6C1AD77AB35A@python.org>

On Sep 15, 2009, at 4:37 PM, Wolodja Wentland wrote:

> Hi all,
>
> i've just seen the following in a mail header:
>
> --- snip ---
> X-Greylist: delayed 2135 seconds by postgrey-1.31 at albatross;
>        Tue, 15 Sep 2009 18:14:38 CEST
> --- snip ---
>
> Why do my mail got delayed for more than 35 min? Is there anything I,
> as a subscriber to this list, can do about it?

You can't stop the greylisting since it's a site-wide anti-spam  
defense.  If you control your mail server, you might be able to adjust  
the retry delay though.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090915/2e27be4c/attachment.pgp>

From david.lyon at preisshare.net  Wed Sep 16 01:52:01 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 15 Sep 2009 19:52:01 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090915154659.GB21452@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
Message-ID: <cf1334183604772ec70ae49d9d19ea61@preisshare.net>

On Tue, 15 Sep 2009 16:46:59 +0100, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
>> Also, I've just realized that uname() is a tuple, so I need to flatten
>> it in strings to restrict the grammar:
>> 
>> - os_sysname
>> - os_nodename
>> - os_release
>> - os_version
>> - os_machine
> 
> When I asked for this I was imagening (wrongly) way more to go in
> setup.cfg then just the meta-data.  To be honest in that case I don't
> think I've got a use for os.uname() to be available.  While nothing is
> wrong with having it, if no one else thinks they need it maybe it's
> unnecessary complication?

I think it is an unneccessary complication.

And imo the discussion has gone way off track..

The use case isn't abstract. All this discussion is about trying
to rewrite two lines of code.

-- setup.py --
"""
    if sys.platform == 'win32':
        setup.dependencies.add('win32com','162')

    setup()

"""

That would be the simplest way to do it in code.

It appears as if "if sys.platform == 'win32':"
is an evil line of code - that certain people
want to go to great lengths to stomp out.

It's one line of code for crying out loud...

We don't need a mini-language just because we
don't like writing it the shortest way...

talk about platform bias gone utterly crazy...

David

 



From ssteinerx at gmail.com  Wed Sep 16 02:09:02 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Tue, 15 Sep 2009 20:09:02 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <cf1334183604772ec70ae49d9d19ea61@preisshare.net>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
Message-ID: <2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>


On Sep 15, 2009, at 7:52 PM, David Lyon wrote:

> And imo the discussion has gone way off track..
>
> The use case isn't abstract. All this discussion is about trying
> to rewrite two lines of code.
>
> -- setup.py --
> """
>    if sys.platform == 'win32':
>        setup.dependencies.add('win32com','162')
>
>    setup()
>
> """
>
> That would be the simplest way to do it in code.
>
> It appears as if "if sys.platform == 'win32':"
> is an evil line of code - that certain people
> want to go to great lengths to stomp out.
>
> It's one line of code for crying out loud...
>
> We don't need a mini-language just because we
> don't like writing it the shortest way...
>
> talk about platform bias gone utterly crazy...

Assuming that it really is that simple...

+1 on everything above.

A 1 line change is much better than a 30 message debate, BNF diagram,  
and DSL for a simple case.  If it doesn't work out for some reason,  
some _real_ reason, debate it then in context, if it ever comes up  
again.

S



From greg.ewing at canterbury.ac.nz  Wed Sep 16 02:30:48 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 16 Sep 2009 12:30:48 +1200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AAF7BAE.2010506@taupro.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<4AAF7BAE.2010506@taupro.com>
Message-ID: <4AB031B8.5050801@canterbury.ac.nz>

> Tarek Ziad? wrote:
> 
>>Imagine a command with the name "foo", that has an option called "condition".

If you really want to keep the entire keyword namespace
available for use as a section sees fit, it would be better
to put the conditions inside the section headers, as I
suggested earlier.

I think that would also make it easier to see which
sections are conditional when looking through the file.

-- 
Greg

From exarkun at twistedmatrix.com  Wed Sep 16 02:42:24 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 16 Sep 2009 00:42:24 -0000
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
Message-ID: <20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>

On 12:09 am, ssteinerx at gmail.com wrote:
>
>On Sep 15, 2009, at 7:52 PM, David Lyon wrote:
>>And imo the discussion has gone way off track..
>>
>>The use case isn't abstract. All this discussion is about trying
>>to rewrite two lines of code.
>>
>>-- setup.py --
>>"""
>>    if sys.platform == 'win32':
>>        setup.dependencies.add('win32com','162')
>>
>>    setup()
>>
>>"""
>>
>>That would be the simplest way to do it in code.
>>
>>It appears as if "if sys.platform == 'win32':"
>>is an evil line of code - that certain people
>>want to go to great lengths to stomp out.
>>
>>It's one line of code for crying out loud...
>>
>>We don't need a mini-language just because we
>>don't like writing it the shortest way...
>>
>>talk about platform bias gone utterly crazy...
>
>Assuming that it really is that simple...
>
>+1 on everything above.
>
>A 1 line change is much better than a 30 message debate, BNF diagram, 
>and DSL for a simple case.  If it doesn't work out for some reason, 
>some _real_ reason, debate it then in context, if it ever comes up 
>again.

I don't think it's really this simple.  The point is to have static 
definition of the package information.  Having a Python program define 
this information at runtime does not satisfy this requirement.  You can 
say that the simple sys.platform test is not evil, but how does that 
lead to a solution allowing PyPI to tell users what the dependencies for 
a package are on their platform?

Still, it may be that if the only use case here is conditionally 
declaring a dependency if the install target is Windows, a simpler 
solution might suffice.  I won't try to describe such a solution. 
Instead, I'll ask if that premise seems valid.

What use cases do we have?  There's the one described above, which lots 
of people have been talking about.  I think there's another one related 
to target Python version - eg, on Python 2.3, depend on simplejson, but 
on Python 2.6, don't.  What else?

Jean-Paul

From david.lyon at preisshare.net  Wed Sep 16 03:39:05 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 15 Sep 2009 21:39:05 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
Message-ID: <07c1198bf3553896049d8dd9f5099ac1@preisshare.net>

On Wed, 16 Sep 2009 00:42:24 -0000, exarkun at twistedmatrix.com wrote:

> I don't think it's really this simple.  

If it isn't, then it should be made to be that simple...

> The point is to have static definition of the package information.  

It would be a huge win for everybody if we could get over this
hurdle.

> Having a Python program define this information at runtime does not 
> satisfy this requirement.  

I agree with that. That's why I suggested it in the first place.

> You can 
> say that the simple sys.platform test is not evil, but how does that 
> lead to a solution allowing PyPI to tell users what the dependencies for 
> a package are on their platform?

I've been ardently campaigning for the static metadata to include
platform specific package definition for a number of months. I'll
just assume you missed my posts.

Here I'll just redescribe a typical win32/linux situation. On
win32 the odbc is built in, but you need win32com to access
it. On Linux, you don't have odbc so you need pyodbc.

"""
[setup]
name = myframework
version = 1.1

[dependencies]
packages = cherrypy, 1.1
    objectmapper, 1.5

[dependencies win32]
packages = win32com

[dependencies linux2]
packages = pyodbc

"""

It is really very simple.

> Still, it may be that if the only use case here is conditionally 
> declaring a dependency if the install target is Windows, a simpler 
> solution might suffice.  I won't try to describe such a solution. 
> Instead, I'll ask if that premise seems valid.

Yes. The premise is true for both windows and linux. They're similar
but different.

> What use cases do we have?  There's the one described above, which lots 
> of people have been talking about.  I think there's another one related 
> to target Python version - eg, on Python 2.3, depend on simplejson, but 
> on Python 2.6, don't.  What else?

Ok. Not what else, here's the complete list:

 1) Additional packages on old python versions . eg need lxml if
    xml support isn't available. simplejson.

 2) Additional packages due to o/s ommission. eg win32com on
    on windows and pyodbc on linux.

They are the typical use cases. 

It's either one or two lines in a config file or one or two lines
in the setup.py script.. 

So it is either

1) """
[dependencies linux2]
packages = pyodbc
"""

or..

2) """
    if setup.platform == "linux2":
        setup.dependencies.append('pyodbc')
"""

Anyway, the real issue here is philosophy. Eliminating
platform specifics vs making it simple for real world
use cases.

I'm also pretending that I didn't look in distutils code
and see how many "darwin" references there actually
are. But it isn't about that.. just being able to
conditionally install extra packages as required based
on whichever of the three major o/s the user happened to
choose.

David









From alex.gronholm at nextday.fi  Wed Sep 16 03:56:17 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 16 Sep 2009 04:56:17 +0300
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <07c1198bf3553896049d8dd9f5099ac1@preisshare.net>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<20090915154659.GB21452@laurie.devork>	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<07c1198bf3553896049d8dd9f5099ac1@preisshare.net>
Message-ID: <4AB045C1.2070209@nextday.fi>

David Lyon kirjoitti:
> On Wed, 16 Sep 2009 00:42:24 -0000, exarkun at twistedmatrix.com wrote:
>
>   
>> I don't think it's really this simple.  
>>     
>
> If it isn't, then it should be made to be that simple...
>
>   
>> The point is to have static definition of the package information.  
>>     
>
> It would be a huge win for everybody if we could get over this
> hurdle.
>
>   
>> Having a Python program define this information at runtime does not 
>> satisfy this requirement.  
>>     
>
> I agree with that. That's why I suggested it in the first place.
>
>   
>> You can 
>> say that the simple sys.platform test is not evil, but how does that 
>> lead to a solution allowing PyPI to tell users what the dependencies for 
>> a package are on their platform?
>>     
>
> I've been ardently campaigning for the static metadata to include
> platform specific package definition for a number of months. I'll
> just assume you missed my posts.
>
> Here I'll just redescribe a typical win32/linux situation. On
> win32 the odbc is built in, but you need win32com to access
> it. On Linux, you don't have odbc so you need pyodbc.
>
> """
> [setup]
> name = myframework
> version = 1.1
>
> [dependencies]
> packages = cherrypy, 1.1
>     objectmapper, 1.5
>
> [dependencies win32]
> packages = win32com
>
> [dependencies linux2]
> packages = pyodbc
>
> """
>
> It is really very simple.
>
>   
>> Still, it may be that if the only use case here is conditionally 
>> declaring a dependency if the install target is Windows, a simpler 
>> solution might suffice.  I won't try to describe such a solution. 
>> Instead, I'll ask if that premise seems valid.
>>     
>
> Yes. The premise is true for both windows and linux. They're similar
> but different.
>
>   
>> What use cases do we have?  There's the one described above, which lots 
>> of people have been talking about.  I think there's another one related 
>> to target Python version - eg, on Python 2.3, depend on simplejson, but 
>> on Python 2.6, don't.  What else?
>>     
>
> Ok. Not what else, here's the complete list:
>
>  1) Additional packages on old python versions . eg need lxml if
>     xml support isn't available. simplejson.
>
>  2) Additional packages due to o/s ommission. eg win32com on
>     on windows and pyodbc on linux.
>
> They are the typical use cases. 
>
> It's either one or two lines in a config file or one or two lines
> in the setup.py script.. 
>
> So it is either
>
> 1) """
> [dependencies linux2]
> packages = pyodbc
> """
>
> or..
>
> 2) """
>     if setup.platform == "linux2":
>         setup.dependencies.append('pyodbc')
> """
>
> Anyway, the real issue here is philosophy. Eliminating
> platform specifics vs making it simple for real world
> use cases.
>
> I'm also pretending that I didn't look in distutils code
> and see how many "darwin" references there actually
> are. But it isn't about that.. just being able to
> conditionally install extra packages as required based
> on whichever of the three major o/s the user happened to
> choose.
>
>   
Make sure you don't forget about Java (which is a "platform" of its own) 
and .NET.
> David
>
>
>
>
>
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: alex_gronholm.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090916/ce0481b1/attachment.vcf>

From ssteinerx at gmail.com  Wed Sep 16 04:23:37 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Tue, 15 Sep 2009 22:23:37 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
Message-ID: <68B6B789-8111-40AF-A350-BD278AC7C409@gmail.com>


On Sep 15, 2009, at 8:42 PM, exarkun at twistedmatrix.com wrote:

> What use cases do we have?  There's the one described above, which  
> lots of people have been talking about.  I think there's another one  
> related to target Python version - eg, on Python 2.3, depend on  
> simplejson, but on Python 2.6, don't.  What else?

Ok, so let's work backwards from use cases to tests to code.  Sounds  
like something I heard once, somewhere...

Do we start by breaking  it down by:

	Python Version

	Platform

and drill down from there?

Seems to me, from there there are lots of details to handle but,  
without those big chunks out of the way, there's really no way to  
meaningfully discuss any further details.

Anyone have any more "big chunks?"

S


	


From greg.ewing at canterbury.ac.nz  Wed Sep 16 10:21:18 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 16 Sep 2009 20:21:18 +1200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <op.u0bgc1b51q4jlt@whymac>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<op.u0bgc1b51q4jlt@whymac>
Message-ID: <4AB09FFE.7020307@canterbury.ac.nz>

Sridhar Ratnakumar wrote:

>    >>> sys.platform
>    'linux2'
> 
> "linux2"? What are the possible values for `sys.platform`?

This is why I usually write Python code that checks sys.platform
like

   if sys.platform.startswith("linux"):
     ...

So the condition language for the metadata needs a "startswith"
operator, I think.

-- 
Greg

From ziade.tarek at gmail.com  Wed Sep 16 12:11:26 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 16 Sep 2009 12:11:26 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AB031B8.5050801@canterbury.ac.nz>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<4AAF7BAE.2010506@taupro.com> <4AB031B8.5050801@canterbury.ac.nz>
Message-ID: <94bdd2610909160311s7874f3d2i7b39b2ce4d54ce88@mail.gmail.com>

On Wed, Sep 16, 2009 at 2:30 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Tarek Ziad? wrote:
>>
>>> Imagine a command with the name "foo", that has an option called
>>> "condition".
>
> If you really want to keep the entire keyword namespace
> available for use as a section sees fit, it would be better
> to put the conditions inside the section headers, as I
> suggested earlier.
>
> I think that would also make it easier to see which
> sections are conditional when looking through the file.

yes, that's another option. It just feel weird to my eyes but I guess
that's just me..


So this would be:

"""
[global]
verbose: 1

[setup]
name: MyDistribution
version: 1.0

[setup:sys_platform == 'win32']
requires: pywin32

[setup:sys_platform == 'darwin']
requires: foo

[setup:'linux' in sys_platform]
requires: bar


[foo]
verbose: 1
condition: badababdalolo
""""

I am not including 'requires' in the section like you have previously shown,
since it's a metadata field and since we will probably have other fields
in these section (see PEP 341 proposals like 'obsoles')


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

From ziade.tarek at gmail.com  Wed Sep 16 12:16:50 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 16 Sep 2009 12:16:50 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
Message-ID: <94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>

On Wed, Sep 16, 2009 at 2:42 AM,  <exarkun at twistedmatrix.com> wrote:
>
> What use cases do we have? ?There's the one described above, which lots of
> people have been talking about. ?I think there's another one related to
> target Python version - eg, on Python 2.3, depend on simplejson, but on
> Python 2.6, don't. ?What else?

So if I resume, so far the uses cases are:

- the OS given by os.name and sys.platform (linux/mac/windows/riscos/ce/ etc..)
- the architecture, given by os.uname() (32/64 bits)
- the python version, given sys.version_info


Tarek

From ziade.tarek at gmail.com  Wed Sep 16 12:23:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 16 Sep 2009 12:23:00 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AB09FFE.7020307@canterbury.ac.nz>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<op.u0bgc1b51q4jlt@whymac> <4AB09FFE.7020307@canterbury.ac.nz>
Message-ID: <94bdd2610909160323s22a8bd90ybe6542254aba19d1@mail.gmail.com>

On Wed, Sep 16, 2009 at 10:21 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Sridhar Ratnakumar wrote:
>
>> ? >>> sys.platform
>> ? 'linux2'
>>
>> "linux2"? What are the possible values for `sys.platform`?
>
> This is why I usually write Python code that checks sys.platform
> like
>
> ?if sys.platform.startswith("linux"):
> ? ?...
>
> So the condition language for the metadata needs a "startswith"
> operator, I think.

What about 'in' ?

'linux' in sys.platform should cover all cases

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



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

From wentland at cl.uni-heidelberg.de  Wed Sep 16 17:40:31 2009
From: wentland at cl.uni-heidelberg.de (Wolodja Wentland)
Date: Wed, 16 Sep 2009 17:40:31 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <20090915153857.GB17381@kinakuta.local>
References: <20090915153857.GB17381@kinakuta.local>
Message-ID: <20090916154031.GA16640@kinakuta.local>

On Tue, Sep 15, 2009 at 17:38 +0200, Wolodja Wentland wrote:
> My question is: "How to reliably access data files from a module in
> foo?"

> Approach 2 - writing a build.py file at installation time
> ---------------------------------------------------------
> 
> The last question made me think, that Approach 1 works for the three
> standard installation schemes, but fails miserably if the user decides
> to do anything fancy.

I implemented this approach like this:

--- snip ---
# -*- coding: UTF-8 -*-
#!/usr/bin/env python

from __future__ import with_statement

import distutils.core as core
from distutils.command.install import install as _install
import sys
import getopt
import os.path

class install(_install):
    """install command
    
    This specific install command will create a file 'build_config.py' which
    contains information on """
    def run(self): 
        with open('lib/foo/build_config.py', 'w') as build_fp:
            build_fp.write('# -*- coding: UTF-8 -*-\n\n')
            build_fp.write("DATA_DIR = '%s'\n"%(
                os.path.join(self.install_data, 'share')))
            build_fp.write("LIB_DIR = '%s'\n"%(self.install_lib))
            build_fp.write("SCRIPT_DIR = '%s'\n"%(self.install_scripts))
        _install.run(self)

core.setup(name='foo',
           version='0.1',
           description='Foo is Bar and Baz',
           author='Wolodja Wentland',
           ...
)
--- snip ---

Is this a good approach? Is there anything i can do better?

with kind regards

    Wolodja Wentland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090916/8de918cc/attachment.pgp>

From pje at telecommunity.com  Wed Sep 16 18:14:32 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 16 Sep 2009 12:14:32 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.co
 m>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
Message-ID: <20090916161435.26CB33A4079@sparrow.telecommunity.com>

At 12:16 PM 9/16/2009 +0200, Tarek Ziad? wrote:
>On Wed, Sep 16, 2009 at 2:42 AM,  <exarkun at twistedmatrix.com> wrote:
> >
> > What use cases do we have?  There's the one described above, which lots of
> > people have been talking about.  I think there's another one related to
> > target Python version - eg, on Python 2.3, depend on simplejson, but on
> > Python 2.6, don't.  What else?
>
>So if I resume, so far the uses cases are:
>
>- the OS given by os.name and sys.platform 
>(linux/mac/windows/riscos/ce/ etc..)
>- the architecture, given by os.uname() (32/64 bits)
>- the python version, given sys.version_info

Do we have anything besides dependencies that change based on the 
above?  If not, then we might be able to address this with the 
"extras" syntax mechanism already present in install_requires, and we 
might able to do it without even changing that syntax.


From wentland at cl.uni-heidelberg.de  Wed Sep 16 20:34:53 2009
From: wentland at cl.uni-heidelberg.de (Wolodja Wentland)
Date: Wed, 16 Sep 2009 20:34:53 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <20090916154031.GA16640@kinakuta.local>
References: <20090915153857.GB17381@kinakuta.local>
	<20090916154031.GA16640@kinakuta.local>
Message-ID: <20090916183453.GA4142@kinakuta.local>

On Wed, Sep 16, 2009 at 17:40 +0200, Wolodja Wentland wrote:
> On Tue, Sep 15, 2009 at 17:38 +0200, Wolodja Wentland wrote:
> > My question is: "How to reliably access data files from a module in
> > foo?"
> 
> > Approach 2 - writing a build.py file at installation time
> > ---------------------------------------------------------
> > 
> > The last question made me think, that Approach 1 works for the three
> > standard installation schemes, but fails miserably if the user decides
> > to do anything fancy.
> 
> I implemented this approach like this:
> 
> --- snip ---
> # -*- coding: UTF-8 -*-
> #!/usr/bin/env python
> 
> from __future__ import with_statement
> 
> import distutils.core as core
> from distutils.command.install import install as _install
> import sys
> import getopt
> import os.path
> 
> class install(_install):
>     """install command
>     
>     This specific install command will create a file 'build_config.py' which
>     contains information on """
>     def run(self): 
>         with open('lib/foo/build_config.py', 'w') as build_fp:
>             build_fp.write('# -*- coding: UTF-8 -*-\n\n')
>             build_fp.write("DATA_DIR = '%s'\n"%(
>                 os.path.join(self.install_data, 'share')))
>             build_fp.write("LIB_DIR = '%s'\n"%(self.install_lib))
>             build_fp.write("SCRIPT_DIR = '%s'\n"%(self.install_scripts))
>         _install.run(self)
> 
> core.setup(name='foo',
>            version='0.1',
>            description='Foo is Bar and Baz',
>            author='Wolodja Wentland',
>            ...
> )
> --- snip ---

I get the following error if i try to install the library:

--- snip ---
reating new virtualenv environment in /home/bar/.virtualenvs/test
  New python executable in /home/bar/.virtualenvs/test/bin/python
  Please make sure you remove any previous custom paths from your /home/bar/.pydistutils.cfg file.
  Installing setuptools...done.....
Unpacking ./dist/foo-0.1.tar.bz2
  Running setup.py egg_info for package from file:///home/bar/src/foo/dist/foo-0.1.tar.bz2
Installing collected packages: foo
  Running setup.py install for foo
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
       or: -c --help [cmd1 cmd2 ...]
       or: -c --help-commands
       or: -c cmd --help
    
    error: option --single-version-externally-managed not recognized
    Complete output from command /home/bar/.virtualenvs/test/bin/python -c "import setuptools; __file__='/tmp/pip-CITX4k-build/setup.py'; execfile('/tmp/pip-CITX4k-build/setup.py')" install --single-version-externally-managed --record /tmp/pip-8lWuFa-record/install-record.txt --install-headers /lib/include:
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]

   or: -c --help [cmd1 cmd2 ...]

   or: -c --help-commands

   or: -c cmd --help



error: option --single-version-externally-managed not recognized

----------------------------------------
Command /home/bar/.virtualenvs/test/bin/python -c "import setuptools; __file__='/tmp/pip-CITX4k-build/setup.py'; execfile('/tmp/pip-CITX4k-build/setup.py')" install --single-version-externally-managed --record /tmp/pip-8lWuFa-record/install-record.txt --install-headers /lib/include failed with error code 1
Storing complete log in ./pip-log.txt
  Complete output from command /home/bar/.virtualenvs/test/bin/python /usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/pip.py install -E test dist/foo-0.1.tar.bz2 /home/bar/.virtualenvs/test ___VENV_RESTART___:
  
----------------------------------------
Traceback (most recent call last):
  File "/usr/bin/pip", line 5, in <module>
    pkg_resources.run_script('pip==0.4', 'pip')
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 448, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1166, in run_script
    execfile(script_filename, namespace, namespace)
  File "/usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/EGG-INFO/scripts/pip", line 3, in <module>
    pip.main()
  File "/usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/pip.py", line 926, in main
    return command.main(initial_args, args[1:], options)
  File "/usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/pip.py", line 258, in main
    restart_in_venv(options.venv, site_packages, complete_args)
  File "/usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/pip.py", line 1009, in restart_in_venv
    call_subprocess([python, file] + args + [base, '___VENV_RESTART___'])
  File "/usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/pip.py", line 3643, in call_subprocess
    % (command_desc, proc.returncode))
pip.InstallationError: Command /home/bar/.virtualenvs/test/bin/python /usr/lib/python2.5/site-packages/pip-0.4-py2.5.egg/pip.py install -E test dist/foo-0.1.tar.bz2 /home/bar/.virtualenvs/test ___VENV_RESTART___ failed with error code 1
--- snip ---

What is causing this? How do i handle that error? Is this really the first time
someone faces that problem?

with kind regards

    Wolodja Wentland

P.S And could pip be changed to *only* print the traceback if
--verbose/--debug is given? Including that makes it so much harder  to
find the real error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090916/2bb28092/attachment-0001.pgp>

From sridharr at activestate.com  Wed Sep 16 20:55:52 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 16 Sep 2009 11:55:52 -0700
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916161435.26CB33A4079@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
Message-ID: <op.u0c5jebd1q4jlt@homeless.vn.shawcable.net>

On Wed, 16 Sep 2009 09:14:32 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> So if I resume, so far the uses cases are:
>  - the OS given by os.name and sys.platform  
> (linux/mac/windows/riscos/ce/ etc..)
> - the architecture, given by os.uname() (32/64 bits)
> - the python version, given sys.version_info
>  Do we have anything besides dependencies that change based on the  
> above?  If not, then we might be able to address this with the "extras"  
> syntax mechanism already present in install_requires, and we might able  
> to do it without even changing that syntax.

+1. This whole conditional semantics in setup.cfg (or a new setup.cfg.in)  
is unneeded if the requirements are small.

Just reproducing an related discussion from another thread:

On Tue, 15 Sep 2009 14:12:46 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 01:46 PM 9/15/2009 -0700, Sridhar Ratnakumar wrote:
>> install_requires = ['lxml', 'multiprocessing[pyver<(2,6)]', 'argparse',
>> 'pywin32[platform.name=windows]']
>
> If you spelled that [python-lt-26] and [platform-windows], it'd even be  
> syntax compatible with today's setuptools; there'd just need to be a way  
> to specify default "extra" tags to be always installed.  (Technically,  
> '.', and '_' characters would be usable as well as '-'.)

I prefer an explicit 'pyver<(2,6)' and it may be better to do a minor  
release of setuptools addressing this forward compatibility (with '<',  
'(', etc..).

-srid


From greg.ewing at canterbury.ac.nz  Wed Sep 16 23:49:13 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 17 Sep 2009 09:49:13 +1200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909160323s22a8bd90ybe6542254aba19d1@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<4AAC4322.8060508@canterbury.ac.nz>
	<94bdd2610909150016j1f073f6by38eb864d1afce2b7@mail.gmail.com>
	<4AAF5494.9090207@canterbury.ac.nz>
	<94bdd2610909150200ga389d40naf791323ee5658fe@mail.gmail.com>
	<op.u0bgc1b51q4jlt@whymac> <4AB09FFE.7020307@canterbury.ac.nz>
	<94bdd2610909160323s22a8bd90ybe6542254aba19d1@mail.gmail.com>
Message-ID: <4AB15D59.9070804@canterbury.ac.nz>

Tarek Ziad? wrote:

> What about 'in' ?

Yes, I guess that's good enough.

-- 
Greg

From ben+python at benfinney.id.au  Thu Sep 17 02:07:55 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Thu, 17 Sep 2009 10:07:55 +1000
Subject: [Distutils] uses for setup.cfg and extracting data from it
References: <4AA77593.9010809@simplistix.co.uk>
	<878wgo1c85.fsf@benfinney.id.au>
	<20090909143159.426783A403D@sparrow.telecommunity.com>
	<87my51yvq9.fsf@benfinney.id.au>
	<20090912002159.2C60E3A403D@sparrow.telecommunity.com>
Message-ID: <87ab0uxwkk.fsf@benfinney.id.au>

"P.J. Eby" <pje at telecommunity.com> writes:

> http://docs.python.org/distutils/apiref.html#module-distutils.core - 
> specifically the run_setup() function.  (It appears the docs do not
> have link anchors for individual functions, alas.)

<URL:http://docs.python.org/distutils/apiref.html#distutils.core.run_setup>

Sphinx (the system creating the documentation you see there) makes
anchors available for all the headings and functions etc., but hides the
links to them by default. When hovering on the heading for the function,
a ??? (U+00B6 PILCROW SIGN) appears, and that character is contained
within an anchor to the heading.

> distutils.core.run_setup("setup.py", [], "init") will return you an
> initialized Distribution object from running the setup script, without
> parsing any configuration files or executing any commands.
[?]

Thank you.

It's not working for me, though: my ?setup.py? does some processing to
generate the arguments for the ?setup()? call, and imports some standard
library modules::

===== setup.py
[?]
import textwrap
from setuptools import setup, find_packages

main_module_name = 'daemon'
main_module = __import__(main_module_name, fromlist=['version'])
version = main_module.version

short_description, long_description = (
    textwrap.dedent(d).strip()
    for d in main_module.__doc__.split(u'\n\n', 1)
    )


setup(
    name = "python-daemon",
    version = version.version,
    packages = find_packages(exclude=["test"]),
[?]
=====

(The full distribution I'm using to try this can be found at
<URL:http://pypi.python.org/packages/source/p/python-daemon/python-daemon-1.4.7.tar.gz>
if you want to follow along at home.)

When I try to use the ?run_setup? function to extract a Distribution
object, it's failing::

    >>> import distutils.core
    >>> dist = distutils.core.run_setup("setup.py", stop_after='init')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.5/distutils/core.py", line 220, in run_setup
        execfile(script_name, g, l)
      File "setup.py", line 23, in <module>
        for d in main_module.__doc__.split(u'\n\n', 1)
      File "setup.py", line 23, in <genexpr>
        for d in main_module.__doc__.split(u'\n\n', 1)
    NameError: global name 'textwrap' is not defined

> This will work with a sufficiently well-behaved setup.py; setup
> scripts that try to do build or install steps outside of any distutils
> command may produce side-effects when run.

Well, this ?setup.py? is fairly simple, and doesn't do any build or
install steps; it's merely trying to do some internal processing to
generate the arguments for ?setup()?.

-- 
 \       ?If you go flying back through time and you see somebody else |
  `\   flying forward into the future, it's probably best to avoid eye |
_o__)                                           contact.? ?Jack Handey |
Ben Finney


From david.lyon at preisshare.net  Thu Sep 17 02:10:07 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 16 Sep 2009 20:10:07 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916161435.26CB33A4079@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
Message-ID: <ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>

On Wed, 16 Sep 2009 12:14:32 -0400, "P.J. Eby" wrote:

> Do we have anything besides dependencies that change based on the 
> above?  If not, then we might be able to address this with the 
> "extras" syntax mechanism already present in install_requires, and we 
> might able to do it without even changing that syntax.

In the real world, yes. But let's not get ahead of ourselves yet.

Let's just focus on getting this one dependency issue out of the
way before muddying the water with other issues.

To answer the question, things like destination directory for
applications could change ie /opt/myapp or \Program Files\myapp
for linux and windows respectively. But this is a long way
off at our present work rate. We shouldn't think ahead too 
much.

David


From pje at telecommunity.com  Thu Sep 17 04:01:20 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 16 Sep 2009 22:01:20 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
Message-ID: <20090917020123.C342A3A4079@sparrow.telecommunity.com>

At 08:10 PM 9/16/2009 -0400, David Lyon wrote:
>To answer the question, things like destination directory for
>applications could change ie /opt/myapp or \Program Files\myapp
>for linux and windows respectively.

It's not the application's business what the installation directory 
is; certainly it's not an issue for the "static metadata" use case, 
nor is it something that should be specified in setup.py or 
setup.cfg, as that is 100% the user's business to choose, and the 
platform tools to supply a default for.


>But this is a long way
>off at our present work rate. We shouldn't think ahead too
>much.

I suspect there is some confusion here; I'm precisely suggesting that 
we not invent a new, general wheel if we can address the real use 
cases with a slight adjustment to something we already have (e.g. the 
extras syntax).


From david.lyon at preisshare.net  Thu Sep 17 04:13:47 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 16 Sep 2009 22:13:47 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090917020123.C342A3A4079@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
Message-ID: <ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>

On Wed, 16 Sep 2009 22:01:20 -0400, "P.J. Eby" <pje at telecommunity.com>
wrote:
> It's not the application's business what the installation directory 
> is; 

Yes, but it very much is.

An application needs to know what directory it has been installed
in and where it can find configuration files and so forth.

See the concurrent thread, about sphinx documentation generation.

It's a valid issue.

> certainly it's not an issue for the "static metadata" use case, 

Correct.

> nor is it something that should be specified in setup.py or 
> setup.cfg, as that is 100% the user's business to choose, and the 
> platform tools to supply a default for.

Well, it certainly doesn't work that way at the moment.

> I suspect there is some confusion here; I'm precisely suggesting that 
> we not invent a new, general wheel if we can address the real use 
> cases with a slight adjustment to something we already have (e.g. the 
> extras syntax).

Yes, there's much confusion. That's the problem, in addition to many
annoying limitations and shortcomings.

So if you want to go ahead and describe what needs to be done in\
nice simple easy to understand terms it would benefit everyone.

David






From pje at telecommunity.com  Thu Sep 17 05:34:07 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 16 Sep 2009 23:34:07 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
Message-ID: <20090917033411.8C25D3A4079@sparrow.telecommunity.com>

At 10:13 PM 9/16/2009 -0400, David Lyon wrote:
>On Wed, 16 Sep 2009 22:01:20 -0400, "P.J. Eby" <pje at telecommunity.com>
>wrote:
> > It's not the application's business what the installation directory
> > is;
>
>Yes, but it very much is.
>
>An application needs to know what directory it has been installed
>in and where it can find configuration files and so forth.

It appears I was unclear: it is not the application's business to 
*decide* what the installation directory is.


> > nor is it something that should be specified in setup.py or
> > setup.cfg, as that is 100% the user's business to choose, and the
> > platform tools to supply a default for.
>
>Well, it certainly doesn't work that way at the moment.

Eh?  It's *possible* to specify it in those places now, but 
well-behaved packages never do.


> > I suspect there is some confusion here; I'm precisely suggesting that
> > we not invent a new, general wheel if we can address the real use
> > cases with a slight adjustment to something we already have (e.g. the
> > extras syntax).
>
>Yes, there's much confusion. That's the problem, in addition to many
>annoying limitations and shortcomings.
>
>So if you want to go ahead and describe what needs to be done in\
>nice simple easy to understand terms it would benefit everyone.

If platform/pyver-specific dependencies are all that's required, 
there's a way to specify them using setuptools' existing dependency 
syntax, using "extras".   install_requires is allowed to have 
sections that express additional requirements (aka "extras") that can 
optionally be installed along with the base package.  Each "extra" 
links an option name (e.g. "pdf-support") to one or more additional 
dependencies (e.g. "reportlab>1.2").

In current versions of setuptools-based installers (such as pip, 
easy_install, buildout, etc.), these extras must be explicitly 
specified in a requirement, in order to install them.  For example, 
"easy_install foo[pdf-support,png-support]" to install foo along with 
whatever requirements are needed for PDF and PNG support.  However, 
if a syntax for extra names were devised, one could implicitly 
specify extras like 'python-lt-2.6' to be automatically installed 
when the conditions are met.

In other words, there's already a framework for actually 
*implementing* conditional dependencies, it just needs to have a 
convention for naming of "extras" to allow it to work.  And in the 
absence of tool support, it could even be implemented manually, by 
adding the necessary extra names on the command line of existing 
installation tools.


From danwalkeriv at gmail.com  Sat Sep 12 00:36:35 2009
From: danwalkeriv at gmail.com (dan)
Date: Fri, 11 Sep 2009 16:36:35 -0600
Subject: [Distutils] Problem installing setuptools under virtual python
	environment
Message-ID: <8d0bb7650909111536m10e3461p747aa0d74da2bebd@mail.gmail.com>

I am on a Cent OS shared system (i.e. I don't have root) with python
2.4 and am having trouble setting up setuptools in a virtual
environment.

I start by setting up the virtual environment:

$/usr/bin/python2.4 virtual-python.py --prefix=~/apps/python
Creating /fslhome/ddw28/apps/python/lib/python2.4
Creating /fslhome/ddw28/apps/python/lib/python2.4/site-packages
Creating /fslhome/ddw28/apps/python/include/python2.4
Creating /fslhome/ddw28/apps/python/bin
Copying /usr/bin/python2.4 to /fslhome/ddw28/apps/python/bin
You're now ready to download ez_setup.py, and run
/fslhome/ddw28/apps/python/bin/python ez_setup.py

then I add "~/apps/python/bin" to my PATH and run the setup script
with the following errors

$ sh setuptools-0.6c9-py2.4.egg
error: can't create or remove files in install directory

The following error occurred while trying to add or remove files in the
installation directory:

    [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/test-easy-install-5267.write-test'

The installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /usr/lib/python2.4/site-packages/
...

I get the right answer when I run which:
$ which python
~/apps/python/bin/python

I also created a symlink ~/apps/python/bin/python2.4 ->
~/apps/python/bin/python and get the same errors (this fixed a similar
problem I had before on a different machine).

Can anybody think of what might be going wrong?

Thanks,
dan

From ziade.tarek at gmail.com  Thu Sep 17 12:41:19 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 12:41:19 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916161435.26CB33A4079@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
Message-ID: <94bdd2610909170341t541b5949hc0295046b9272fc3@mail.gmail.com>

2009/9/16 P.J. Eby <pje at telecommunity.com>:
> At 12:16 PM 9/16/2009 +0200, Tarek Ziad? wrote:
>>
>> On Wed, Sep 16, 2009 at 2:42 AM, ?<exarkun at twistedmatrix.com> wrote:
>> >
>> > What use cases do we have? ?There's the one described above, which lots
>> > of
>> > people have been talking about. ?I think there's another one related to
>> > target Python version - eg, on Python 2.3, depend on simplejson, but on
>> > Python 2.6, don't. ?What else?
>>
>> So if I resume, so far the uses cases are:
>>
>> - the OS given by os.name and sys.platform (linux/mac/windows/riscos/ce/
>> etc..)
>> - the architecture, given by os.uname() (32/64 bits)
>> - the python version, given sys.version_info
>
> Do we have anything besides dependencies that change based on the above? ?If
> not, then we might be able to address this with the "extras" syntax
> mechanism already present in install_requires, and we might able to do it
> without even changing that syntax.
>

There will be several fields that will be usable in these sections
(see PEP 341 - which is being reworked
by Tres Seaver in a branch)

Also, if I understand clearly the idea, I find it rather cryptic to
add conditions to each dependency
like what Sridhar has shown. So one dependency is decoupled from the
environment conditions
we want to express.

Tarek


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

From ziade.tarek at gmail.com  Thu Sep 17 12:55:03 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 12:55:03 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <20090916154031.GA16640@kinakuta.local>
References: <20090915153857.GB17381@kinakuta.local>
	<20090916154031.GA16640@kinakuta.local>
Message-ID: <94bdd2610909170355tf27b3b0y25db2ca1f6d9b938@mail.gmail.com>

On Wed, Sep 16, 2009 at 5:40 PM, Wolodja Wentland
<wentland at cl.uni-heidelberg.de> wrote:
> On Tue, Sep 15, 2009 at 17:38 +0200, Wolodja Wentland wrote:
>> My question is: "How to reliably access data files from a module in
>> foo?"
>
>> Approach 2 - writing a build.py file at installation time
>> ---------------------------------------------------------
>>
>> The last question made me think, that Approach 1 works for the three
>> standard installation schemes, but fails miserably if the user decides
>> to do anything fancy.
>
> I implemented this approach like this:

Sorry for the late reply,

>
> Is this a good approach? Is there anything i can do better?

The idea of providing your own install command seems good, except that I find
writing all informations in a .py overkill.

In the same way the option --record works, you can memorize
all installation locations into a simple ConfigParser-like file you
add to the files that
are installed in Python in your package.

Your code can then read the .cfg file it at execution time using
__file__ to get your
paths.

Although with this approach you have to be careful if your package is
distributed in some environments (py2exe, setuptools eggs) where you might be
located in a zipped file.

What are your target platforms ?

Tarek

From reinout at vanrees.org  Thu Sep 17 14:46:23 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 17 Sep 2009 12:46:23 +0000 (UTC)
Subject: [Distutils] non-ascii characters in long description
Message-ID: <h8tb2v$a6p$1@ger.gmane.org>

I have non-ascii characters in my long description (as I just fixed a bug in
my package that had to do with non-ascii characters).  I did all the right
things like opening my changelog and readme with "codecs.open(...,
encoding='utf-8')" and so.  But I ran into the following setuptools problem:

When calling "python setup.py --long-description", setuptools effectively does
a "print long_description", which works with a utf8 string, but fails with a
unicode string.

When uploading to pypi, setuptools calls unicode() on my long description,
which fails with a utf8 string and works with a unicode string.

So if I do long_description=my_unicode_string, --long-description fails and if
I do long_description=my_unicode_string.encode('utf-8') the pypi upload
fails.

In the end I used the dirty UltraMagicString() hack from
http://stackoverflow.com/questions/1162338/whats-the-right-way-to-use-unicode-metadata-in-setup-py

Any suggestions?


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ziade.tarek at gmail.com  Thu Sep 17 15:00:33 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 15:00:33 +0200
Subject: [Distutils] non-ascii characters in long description
In-Reply-To: <h8tb2v$a6p$1@ger.gmane.org>
References: <h8tb2v$a6p$1@ger.gmane.org>
Message-ID: <94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>

On Thu, Sep 17, 2009 at 2:46 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> I have non-ascii characters in my long description (as I just fixed a bug in
> my package that had to do with non-ascii characters). ?I did all the right
> things like opening my changelog and readme with "codecs.open(...,
> encoding='utf-8')" and so. ?But I ran into the following setuptools problem:
>
> When calling "python setup.py --long-description", setuptools effectively does
> a "print long_description", which works with a utf8 string, but fails with a
> unicode string.
>
> When uploading to pypi, setuptools calls unicode() on my long description,
> which fails with a utf8 string and works with a unicode string.

Mmm, I've fixed that problem in Distutils code in 2.6+  IIRC

Are you sure this code is in setuptools and not in distutils ? can you
provide a traceback ?


Tarek

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

From reinout at vanrees.org  Thu Sep 17 15:31:06 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 17 Sep 2009 13:31:06 +0000 (UTC)
Subject: [Distutils] non-ascii characters in long description
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
Message-ID: <h8tdmq$kg5$1@ger.gmane.org>

On 2009-09-17, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Sep 17, 2009 at 2:46 PM, Reinout van Rees <reinout at vanrees.org> wrote:
>> I have non-ascii characters in my long description (as I just fixed a bug in
>> my package that had to do with non-ascii characters). ?I did all the right
>> things like opening my changelog and readme with "codecs.open(...,
>> encoding='utf-8')" and so. ?But I ran into the following setuptools problem:
>>
>> When calling "python setup.py --long-description", setuptools effectively does
>> a "print long_description", which works with a utf8 string, but fails with a
>> unicode string.
>>
>> When uploading to pypi, setuptools calls unicode() on my long description,
>> which fails with a utf8 string and works with a unicode string.
>
> Mmm, I've fixed that problem in Distutils code in 2.6+  IIRC

Ah, I'm still using 2.5 mostly.

> Are you sure this code is in setuptools and not in distutils ? can you
> provide a traceback ?

You're completely right: distutils (at least the upload to pypi bug).  Here's
the traceback:

Traceback (most recent call last):
  File "setup.py", line 47, in <module>
    'lasttagdiff = zest.releaser.lasttagdiff:main'],
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 986, in run_commands
    self.run_command(cmd)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 1006, in run_command
    cmd_obj.run()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/command/register.py", line 9, in run
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 48, in run
    self.send_metadata()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 162, in send_metadata
    auth)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 257, in post_to_server
    value = unicode(value).encode("utf-8")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 6030:
  ordinal not in range(128)



Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ziade.tarek at gmail.com  Thu Sep 17 15:46:27 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 15:46:27 +0200
Subject: [Distutils] non-ascii characters in long description
In-Reply-To: <h8tdmq$kg5$1@ger.gmane.org>
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
Message-ID: <94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>

On Thu, Sep 17, 2009 at 3:31 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> On 2009-09-17, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Thu, Sep 17, 2009 at 2:46 PM, Reinout van Rees <reinout at vanrees.org> wrote:
>>> I have non-ascii characters in my long description (as I just fixed a bug in
>>> my package that had to do with non-ascii characters). ?I did all the right
>>> things like opening my changelog and readme with "codecs.open(...,
>>> encoding='utf-8')" and so. ?But I ran into the following setuptools problem:
>>>
>>> When calling "python setup.py --long-description", setuptools effectively does
>>> a "print long_description", which works with a utf8 string, but fails with a
>>> unicode string.
>>>
>>> When uploading to pypi, setuptools calls unicode() on my long description,
>>> which fails with a utf8 string and works with a unicode string.
>>
>> Mmm, I've fixed that problem in Distutils code in 2.6+ ?IIRC
>
> Ah, I'm still using 2.5 mostly.
>
>> Are you sure this code is in setuptools and not in distutils ? can you
>> provide a traceback ?
>
> You're completely right: distutils (at least the upload to pypi bug). ?Here's
> the traceback:
>
> Traceback (most recent call last):
> ?File "setup.py", line 47, in <module>
> ? ?'lasttagdiff = zest.releaser.lasttagdiff:main'],
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 151, in setup
> ? ?dist.run_commands()
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 986, in run_commands
> ? ?self.run_command(cmd)
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 1006, in run_command
> ? ?cmd_obj.run()
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/command/register.py", line 9, in run
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 48, in run
> ? ?self.send_metadata()
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 162, in send_metadata
> ? ?auth)
> ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 257, in post_to_server
> ? ?value = unicode(value).encode("utf-8")
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 6030:
> ?ordinal not in range(128)

Yes that's the one I've fixed. You have to backport a fix in your
setup.py if python < 2.6

You can register.patch post_to_server to pre-process all values in the
"data" argument, so they are
all in unicode, then call the real one.

That's hackish, but at least unicode() won't break anymore when called
on already decoded strings eg unicode objects.

Tarek

>
>
>
> Reinout
>
> --
> Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
> Software developer at http://www.thehealthagency.com
> "Military engineers build missiles. Civil engineers build targets"
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From pje at telecommunity.com  Thu Sep 17 15:53:23 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 17 Sep 2009 09:53:23 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909170341t541b5949hc0295046b9272fc3@mail.gmail.co
 m>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<94bdd2610909170341t541b5949hc0295046b9272fc3@mail.gmail.com>
Message-ID: <20090917135332.9637C3A4069@sparrow.telecommunity.com>

At 12:41 PM 9/17/2009 +0200, Tarek Ziad? wrote:
>Also, if I understand clearly the idea, I find it rather cryptic to
>add conditions to each dependency
>like what Sridhar has shown.

That's actually not how it would work; you simply put section 
headings inside the extras_require field, rather than having multiple 
sections in setup.cfg.  Then, the "static metadata" is just the 
existing PKG-INFO format.

Setuptools already supports section headings in extras_require, it 
just doesn't (yet) automatically install the contents of those 
sections based on platform/python version; you'd have to explicitly 
request "easy_install somepackage[platform.win32,pyver-2.6]" at the 
moment.  But adding automatic defaulting of those flags would be 
pretty trivial, once their format was officially defined.

See 
http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies 
for more details.


From reinout at vanrees.org  Thu Sep 17 15:58:34 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 17 Sep 2009 13:58:34 +0000 (UTC)
Subject: [Distutils] non-ascii characters in long description
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
	<94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
Message-ID: <h8tfaa$p6r$2@ger.gmane.org>

On 2009-09-17, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>
> Yes that's the one I've fixed. You have to backport a fix in your
> setup.py if python < 2.6
>
> You can register.patch post_to_server to pre-process all values in the
> "data" argument, so they are
> all in unicode, then call the real one.

Thanks for the info.  I've added your hint to the stackoverflow page so that
it is findable right there.


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ziade.tarek at gmail.com  Thu Sep 17 16:05:46 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 16:05:46 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090917135332.9637C3A4069@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<94bdd2610909170341t541b5949hc0295046b9272fc3@mail.gmail.com>
	<20090917135332.9637C3A4069@sparrow.telecommunity.com>
Message-ID: <94bdd2610909170705g3ba26a40l9f8f4f8adabd7952@mail.gmail.com>

On Thu, Sep 17, 2009 at 3:53 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 12:41 PM 9/17/2009 +0200, Tarek Ziad? wrote:
>>
>> Also, if I understand clearly the idea, I find it rather cryptic to
>> add conditions to each dependency
>> like what Sridhar has shown.
>
> That's actually not how it would work; you simply put section headings
> inside the extras_require field, rather than having multiple sections in
> setup.cfg. ?Then, the "static metadata" is just the existing PKG-INFO
> format.
>

could you provide a full example, taking back theses thread examples ?

From ziade.tarek at gmail.com  Thu Sep 17 18:51:20 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Sep 2009 18:51:20 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <94bdd2610909170355tf27b3b0y25db2ca1f6d9b938@mail.gmail.com>
References: <20090915153857.GB17381@kinakuta.local>
	<20090916154031.GA16640@kinakuta.local>
	<94bdd2610909170355tf27b3b0y25db2ca1f6d9b938@mail.gmail.com>
Message-ID: <94bdd2610909170951j3bab982dg253bf3f930dc2c58@mail.gmail.com>

On Thu, Sep 17, 2009 at 12:55 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, Sep 16, 2009 at 5:40 PM, Wolodja Wentland
> <wentland at cl.uni-heidelberg.de> wrote:
>> On Tue, Sep 15, 2009 at 17:38 +0200, Wolodja Wentland wrote:
>>> My question is: "How to reliably access data files from a module in
>>> foo?"
>>
>>> Approach 2 - writing a build.py file at installation time
>>> ---------------------------------------------------------
>>>
>>> The last question made me think, that Approach 1 works for the three
>>> standard installation schemes, but fails miserably if the user decides
>>> to do anything fancy.
>>
>> I implemented this approach like this:
>
> Sorry for the late reply,
>
>>
>> Is this a good approach? Is there anything i can do better?
>
> The idea of providing your own install command seems good, except that I find
> writing all informations in a .py overkill.
>
> In the same way the option --record works, you can memorize
> all installation locations into a simple ConfigParser-like file you
> add to the files that
> are installed in Python in your package.
>
> Your code can then read the .cfg file it at execution time using
> __file__ to get your
> paths.
>
> Although with this approach you have to be careful if your package is
> distributed in some environments (py2exe, setuptools eggs) where you might be
> located in a zipped file.

On a second thaught,  if the file already exists in you package with
default values
it's simpler :

you might be able to alter it on-the-fly by overriding  the build_py command
instead of the install command

and AFAIR, you won't be bothered by setuptools' monkey patches.

From marius at pov.lt  Thu Sep 17 20:31:54 2009
From: marius at pov.lt (Marius Gedminas)
Date: Thu, 17 Sep 2009 21:31:54 +0300
Subject: [Distutils] non-ascii characters in long description
In-Reply-To: <94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
	<94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
Message-ID: <20090917183154.GA14158@fridge.pov.lt>

On Thu, Sep 17, 2009 at 03:46:27PM +0200, Tarek Ziad? wrote:
> On Thu, Sep 17, 2009 at 3:31 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> > On 2009-09-17, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> >> On Thu, Sep 17, 2009 at 2:46 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> >>> I have non-ascii characters in my long description (as I just fixed a bug in
> >>> my package that had to do with non-ascii characters). ?I did all the right
> >>> things like opening my changelog and readme with "codecs.open(...,
> >>> encoding='utf-8')" and so. ?But I ran into the following setuptools problem:
> >>>
> >>> When calling "python setup.py --long-description", setuptools effectively does
> >>> a "print long_description", which works with a utf8 string, but fails with a
> >>> unicode string.
> >>>
> >>> When uploading to pypi, setuptools calls unicode() on my long description,
> >>> which fails with a utf8 string and works with a unicode string.
> >>
> >> Mmm, I've fixed that problem in Distutils code in 2.6+ ?IIRC
...
> > Traceback (most recent call last):
...
> > ?File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 257, in post_to_server
> > ? ?value = unicode(value).encode("utf-8")
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 6030:
> > ?ordinal not in range(128)
> 
> Yes that's the one I've fixed. You have to backport a fix in your
> setup.py if python < 2.6

I think you mean <= 2.6; I was seeing this problem with 2.6.2.

It's good to know this is going to be fixed in 2.7.

> You can register.patch post_to_server to pre-process all values in the
> "data" argument, so they are
> all in unicode, then call the real one.

This sounds mysterious; I'll wait and look at Reinout's package in a
while (assuming he choses to do this).

> That's hackish, but at least unicode() won't break anymore when called
> on already decoded strings eg unicode objects.

Marius Gedminas
-- 
Westheimer's Discovery:
        A couple of months in the laboratory can
        frequently save a couple of hours in the library.
-------------- 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/20090917/004a6b43/attachment-0001.pgp>

From marius at pov.lt  Thu Sep 17 20:32:52 2009
From: marius at pov.lt (Marius Gedminas)
Date: Thu, 17 Sep 2009 21:32:52 +0300
Subject: [Distutils] non-ascii characters in long description
In-Reply-To: <h8tfaa$p6r$2@ger.gmane.org>
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
	<94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
	<h8tfaa$p6r$2@ger.gmane.org>
Message-ID: <20090917183252.GB14158@fridge.pov.lt>

On Thu, Sep 17, 2009 at 01:58:34PM +0000, Reinout van Rees wrote:
> On 2009-09-17, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> >
> > Yes that's the one I've fixed. You have to backport a fix in your
> > setup.py if python < 2.6
> >
> > You can register.patch post_to_server to pre-process all values in the
> > "data" argument, so they are
> > all in unicode, then call the real one.
> 
> Thanks for the info.  I've added your hint to the stackoverflow page so that
> it is findable right there.

Thanks!

Could you mention the name of your package so I could look at actual
code?  (That assumes you're going to replace UltraMagicString with
Tarek's suggested workaround.)

Marius Gedminas
-- 
To stay awake all night adds a day to your life.
		-- Stilgar (Frank Herbert _Children_of_Dune_)
-------------- 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/20090917/beef57b2/attachment.pgp>

From wentland at cl.uni-heidelberg.de  Thu Sep 17 21:05:16 2009
From: wentland at cl.uni-heidelberg.de (Wolodja Wentland)
Date: Thu, 17 Sep 2009 21:05:16 +0200
Subject: [Distutils] Get install prefix for module at runtime
In-Reply-To: <94bdd2610909170951j3bab982dg253bf3f930dc2c58@mail.gmail.com>
References: <20090915153857.GB17381@kinakuta.local>
	<20090916154031.GA16640@kinakuta.local>
	<94bdd2610909170355tf27b3b0y25db2ca1f6d9b938@mail.gmail.com>
	<94bdd2610909170951j3bab982dg253bf3f930dc2c58@mail.gmail.com>
Message-ID: <20090917190516.GC9682@kinakuta.local>

On Thu, Sep 17, 2009 at 18:51 +0200, Tarek Ziad? wrote:
> you might be able to alter it on-the-fly by overriding  the build_py command
> instead of the install command

That worked perfectly! Thanks again for the help and pointers you gave
me. I really appreciate that.

The solution i came up with is:

--- snip ---
class build_py(_build_py):
    """build_py command
    
    This specific build_py command will modify module 'foo.build_config' so that it
    contains information on installation prefixes afterwards.
    """
    def build_module (self, module, module_file, package):
        if type(package) is StringType:
            _package = string.split(package, '.')
        elif type(package) not in (ListType, TupleType):
            raise TypeError, \
                  "'package' must be a string (dot-separated), list, or tuple"

        if ( module == 'build_info' and len(_package) == 1 and
            package[0] == 'foo'):
            iobj = self.distribution.command_obj['install']

            with open(module_file, 'w') as module_fp:
                module_fp.write('# -*- coding: UTF-8 -*-\n\n')
                module_fp.write("DATA_DIR = '%s'\n"%(
                    os.path.join(iobj.install_data, 'share')))
                module_fp.write("LIB_DIR = '%s'\n"%(iobj.install_lib))
                module_fp.write("SCRIPT_DIR = '%s'\n"%(iobj.install_scripts))

        _build_py.build_module(self, module, module_file, package)
--- snip ---

I might change the 'detect my module' logic a little because i rely on
python short circuit evaluation a bit too much.

I have some final questions:

1. Is the distutils API i am using here likely to change?

2. Is there a better way to access install_{lib,scripts,data} than going
   through the install command object available from distribution?

3. Could you include something like this in distutils? My idea on how to
   handle this would be to define an additional argument 'foo_bar' for
   core.setup() which will take a user defined dotted module name in
   which information like this will be saved.

   So if a user defines:

    core.setup( ...
                foo_bar : 'foo.build_info',
                ...
                )

    A file lib_prefix/foo/build_info.py will be injected into the
    library or an already one would be altered according to user defined
    string templates. 

    Something like this would end module.__file__ hacks once and for all
    and is IMHO a much cleaner way to advertise this information to
    libraries/application than trying to take care of this externally.

so long

    Wolodja Wentland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090917/a28c5c5e/attachment.pgp>

From a.cavallo at cavallinux.eu  Thu Sep 17 23:07:17 2009
From: a.cavallo at cavallinux.eu (A. Cavallo)
Date: Thu, 17 Sep 2009 22:07:17 +0100
Subject: [Distutils] distutils bdist_rpm and %postun section of spec file
In-Reply-To: <696781e0909110955x1fde5c7dj8c0a64238932e1e9@mail.gmail.com>
References: <696781e0909110955x1fde5c7dj8c0a64238932e1e9@mail.gmail.com>
Message-ID: <200909172207.17796.a.cavallo@cavallinux.eu>

Hi,
as rule of thumb (followed now by all major distros) you should not put any 
script in %postun, %postinst etc sections.

Regards,
Antonio

> Hello,
> I am looking for some advise in creating rpm package using bdist_rpm.
> I have managed to create post_install part using information
> http://stackoverflow.com/questions/1321270/how-to-extend-distutils-with-a-s
>imple-post-install-script Now i would like to add some code to %postun part
> of spec file to revert changes done by my post_install command.
> Is there a way to add it in setup.py or do i have to manually edit spec
> file?

From chris at simplistix.co.uk  Thu Sep 17 23:11:37 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 17 Sep 2009 22:11:37 +0100
Subject: [Distutils] [buildout] recipes useful to setup a whole machine
Message-ID: <4AB2A609.9050606@simplistix.co.uk>

Hi All,

I have a hair-brained notion of using a buildout to set up an entire 
machine. Has anyone done this before? (Jim, didn't you say ZC do this a 
lot?)

 From where I'm sitting, I'm looking for a few recipes:

- what's the best download & cmmi recipe out there?

- what's the best recipe for running other buildouts?

- is there a recipe available anywhere for installing/removing packages 
using aptitude?

cheers,

Chris

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

From jim at zope.com  Thu Sep 17 23:59:30 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 17 Sep 2009 17:59:30 -0400
Subject: [Distutils] [buildout] recipes useful to setup a whole machine
In-Reply-To: <4AB2A609.9050606@simplistix.co.uk>
References: <4AB2A609.9050606@simplistix.co.uk>
Message-ID: <1099b90b0909171459h57bcc819h6130d0d70201330a@mail.gmail.com>

On Thu, Sep 17, 2009 at 5:11 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> I have a hair-brained notion of using a buildout to set up an entire
> machine. Has anyone done this before? (Jim, didn't you say ZC do this a
> lot?)

No, we use buildouts to build rpms.

Jim

-- 
Jim Fulton

From chris at simplistix.co.uk  Fri Sep 18 00:06:02 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 17 Sep 2009 23:06:02 +0100
Subject: [Distutils] [buildout] recipes useful to setup a whole machine
In-Reply-To: <1099b90b0909171459h57bcc819h6130d0d70201330a@mail.gmail.com>
References: <4AB2A609.9050606@simplistix.co.uk>
	<1099b90b0909171459h57bcc819h6130d0d70201330a@mail.gmail.com>
Message-ID: <4AB2B2CA.6020105@simplistix.co.uk>

Jim Fulton wrote:
> On Thu, Sep 17, 2009 at 5:11 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>> I have a hair-brained notion of using a buildout to set up an entire
>> machine. Has anyone done this before? (Jim, didn't you say ZC do this a
>> lot?)
> 
> No, we use buildouts to build rpms.

Ah, okay, do you have an automated machine setup process for the 
resulting rpms or do you just install them by hand?

cheers,

Chris

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

From sridharr at activestate.com  Fri Sep 18 00:46:06 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 17 Sep 2009 15:46:06 -0700
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909170705g3ba26a40l9f8f4f8adabd7952@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<94bdd2610909170341t541b5949hc0295046b9272fc3@mail.gmail.com>
	<20090917135332.9637C3A4069@sparrow.telecommunity.com>
	<94bdd2610909170705g3ba26a40l9f8f4f8adabd7952@mail.gmail.com>
Message-ID: <op.u0fau4qs1q4jlt@whymac.activestate.com>

On Thu, 17 Sep 2009 07:05:46 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> On Thu, Sep 17, 2009 at 3:53 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 12:41 PM 9/17/2009 +0200, Tarek Ziad? wrote:
>>>
>>> Also, if I understand clearly the idea, I find it rather cryptic to
>>> add conditions to each dependency
>>> like what Sridhar has shown.
>>
>> That's actually not how it would work; you simply put section headings
>> inside the extras_require field, rather than having multiple sections in
>> setup.cfg.  Then, the "static metadata" is just the existing PKG-INFO
>> format.
>>
>
> could you provide a full example, taking back theses thread examples ?

I think PJE was referring to something like this:

$ cat foo.egg-info/requires.txt
argparse
lxml

[tests]
nose

[python-lt-26]
multiprocessing

[platform-eq-win32]
pywin32

which is defined in setup.py like this:

$ cat setup.py
[...]
setup(
   [...]
   install_requires['argparse', 'lxml'],
   extras_require={'tests': ['nose'],
                   'python-lt-26': ['multiprocessing'],
                   'platform-eq-win32': ['pywin32']}
   [...]
)

Currently you have to manually specify, say, "easy_install  
foo[platform-eq-win32,python-lt-26]" if you are installing on Windows  
Python 2.5. But with a little modification, this can be made automatic.  
Zope packages makes use of this kind of 'extras' feature a lot .. eg:  
"easy_install foo[tests]" would also install nose.

Setuptools already has this feature. I suggest we make this a standard of  
doing things and extend the extras syntax to implement conditional  
dependencies.


-srid

From m.van.rees at zestsoftware.nl  Fri Sep 18 01:03:16 2009
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Thu, 17 Sep 2009 23:03:16 +0000 (UTC)
Subject: [Distutils] non-ascii characters in long description
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
	<94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
	<h8tfaa$p6r$2@ger.gmane.org> <20090917183252.GB14158@fridge.pov.lt>
Message-ID: <h8uf7k$5k6$2@ger.gmane.org>

Marius Gedminas, on 2009-09-17:
>
> On Thu, Sep 17, 2009 at 01:58:34PM +0000, Reinout van Rees wrote:
>> On 2009-09-17, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> >
>> > Yes that's the one I've fixed. You have to backport a fix in your
>> > setup.py if python < 2.6
>> >
>> > You can register.patch post_to_server to pre-process all values in the
>> > "data" argument, so they are
>> > all in unicode, then call the real one.
>> 
>> Thanks for the info.  I've added your hint to the stackoverflow page so that
>> it is findable right there.
>
> Thanks!
>
> Could you mention the name of your package so I could look at actual
> code?  (That assumes you're going to replace UltraMagicString with
> Tarek's suggested workaround.)

That is zest.releaser.  See
http://svn.plone.org/svn/collective/zest.releaser/trunk
http://pypi.python.org/pypi/zest.releaser

-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]


From jim at zope.com  Fri Sep 18 01:09:02 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 17 Sep 2009 19:09:02 -0400
Subject: [Distutils] [buildout] recipes useful to setup a whole machine
In-Reply-To: <4AB2B2CA.6020105@simplistix.co.uk>
References: <4AB2A609.9050606@simplistix.co.uk>
	<1099b90b0909171459h57bcc819h6130d0d70201330a@mail.gmail.com>
	<4AB2B2CA.6020105@simplistix.co.uk>
Message-ID: <1099b90b0909171609q67661ef0u61ab22b54fa517b3@mail.gmail.com>

On Thu, Sep 17, 2009 at 6:06 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Jim Fulton wrote:
>>
>> On Thu, Sep 17, 2009 at 5:11 PM, Chris Withers <chris at simplistix.co.uk>
>> wrote:
>>>
>>> I have a hair-brained notion of using a buildout to set up an entire
>>> machine. Has anyone done this before? (Jim, didn't you say ZC do this a
>>> lot?)
>>
>> No, we use buildouts to build rpms.
>
> Ah, okay, do you have an automated machine setup process for the resulting
> rpms or do you just install them by hand?

We use a combination of cobbler and yum.

Jim

-- 
Jim Fulton

From tseaver at palladion.com  Fri Sep 18 04:37:58 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 17 Sep 2009 22:37:58 -0400
Subject: [Distutils] Problem installing setuptools under virtual python
	environment
In-Reply-To: <8d0bb7650909111536m10e3461p747aa0d74da2bebd@mail.gmail.com>
References: <8d0bb7650909111536m10e3461p747aa0d74da2bebd@mail.gmail.com>
Message-ID: <4AB2F286.8030303@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dan wrote:
> I am on a Cent OS shared system (i.e. I don't have root) with python
> 2.4 and am having trouble setting up setuptools in a virtual
> environment.
> 
> I start by setting up the virtual environment:
> 
> $/usr/bin/python2.4 virtual-python.py --prefix=~/apps/python
> Creating /fslhome/ddw28/apps/python/lib/python2.4
> Creating /fslhome/ddw28/apps/python/lib/python2.4/site-packages
> Creating /fslhome/ddw28/apps/python/include/python2.4
> Creating /fslhome/ddw28/apps/python/bin
> Copying /usr/bin/python2.4 to /fslhome/ddw28/apps/python/bin
> You're now ready to download ez_setup.py, and run
> /fslhome/ddw28/apps/python/bin/python ez_setup.py

I'm pretty sure the right answer to your question is "Use virtualenv.py
instead of virtual-python.py".

AFAIK, virtual-python.py is unsupported any longer, and virtualenv.py
pre-installs setuptools for you.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKsvKG+gerLs4ltQ4RAicRAJ4gTqQtiJM5/UIvKOUEhsAZovpiqgCePcQQ
mTZbgS1zVzG15WFn08p5i+0=
=/nbS
-----END PGP SIGNATURE-----


From greno at verizon.net  Fri Sep 18 05:45:04 2009
From: greno at verizon.net (Gerry Reno)
Date: Thu, 17 Sep 2009 23:45:04 -0400
Subject: [Distutils] stdeb-0.3 error
Message-ID: <4AB30240.8020807@verizon.net>

sudo easy_install stdeb  # brought in stdeb 0.3

$ cd myappdir # where my setup.py is located

$# following http://github.com/astraw/stdeb/  quickstart 1

$ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \
 >   cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \
 >   dpkg-buildpackage -rfakeroot -uc -us && \
 >   cd ../.. &&
 >   echo ".deb created successfully in deb_dist/"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "setup.py", line 41, in <module>
    
sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)), 
"bin"))
NameError: name '__file__' is not defined


=========================================================

The error is coming from the setup.py line:

import imp
import sys
import os
import glob

from distutils.core import setup, Command
from distutils.command.install import install

if os.name == 'nt':
    import py2exe

sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)), 
"bin"))

===========================================================

I do not get this error when I run setup.py normally for other commands 
like 'sdist'.

How can I fix this?


Regards,
Gerry





From strawman at astraw.com  Fri Sep 18 07:08:30 2009
From: strawman at astraw.com (Andrew Straw)
Date: Thu, 17 Sep 2009 22:08:30 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB30240.8020807@verizon.net>
References: <4AB30240.8020807@verizon.net>
Message-ID: <4AB315CE.6060104@astraw.com>

Gerry Reno wrote:
> sudo easy_install stdeb  # brought in stdeb 0.3
>
> $ cd myappdir # where my setup.py is located
>
> $# following http://github.com/astraw/stdeb/  quickstart 1
>
> $ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \
> >   cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \
> >   dpkg-buildpackage -rfakeroot -uc -us && \
> >   cd ../.. &&
> >   echo ".deb created successfully in deb_dist/"
> Traceback (most recent call last):
>  File "<string>", line 1, in <module>
>  File "setup.py", line 41, in <module>
>   
> sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),
> "bin"))
> NameError: name '__file__' is not defined

You can use something more elaborate like

python -c "import
stdeb,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
sdist_dsc

for the first line.


From regebro at gmail.com  Fri Sep 18 08:24:16 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Sep 2009 08:24:16 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
Message-ID: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>

Hiya all!

Tarek alerted me to that Martin v L?wis has checked in the great job
done during the DZUG-sprint of adding Python 3 support to the 0.6
maintenance branch. I tested it yesterday, and I have two comments.

1. First a little heads up!!

When I tested this yesterday, I first ran the tests for various Python
versions, and then I tried to install it on Python 3.1. Unfortunately
I got a syntax error. Something was not properly converted to Python
3. Looking at the source code of the file in question showed that it
WAS converted. I thought it was the PYC-file, but then I realized you
can't get syntax-error in pyc-files. I deleted all in site-packages,
and ran the install again: Same result.

Finally I fixed it by deleting all in site-packages, and rm -rf dist
build in the distribute checkout and also deleting all pyc-files in
the distribute checkout and trying again. Since then, I have not been
able to repeat the problem. (Deleting just build and dist or just the
pyc-files or just everything in site-setup did not work. Only when I
deleted *all* of these did the problem go away).

I suspect that the existence of my setuptools port in the Python 3.1
install before running the new one made something very strange. But it
made the strangeness in either build/ or dist/. So a heads up to
everyone here: If you have used my setuptools port, make sure you
delete all traces of it from your Python 3 install *before* attempting
to install Distribute on Python 3.


2. There is now a build_py that will run 2to3 on the code. That's
cool, but there doesn't seem to be a way to enable it. It looks for a
setuptools.use_2to3 attribute to check if it should be used, but I
couldn't see a way of setting that. Passing it in as a parameter to
setup() gives you a warning, that the parameter is unknown.

How should it be done?

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

From chris at simplistix.co.uk  Fri Sep 18 12:06:27 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 11:06:27 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610909110723t2fbc394cn2f915f36d8706adc@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	
	<4A9BBA2B.6010903@simplistix.co.uk>	
	<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>	
	<4AA4F94C.9080702@simplistix.co.uk>	
	<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>	
	<4AA6136A.7080904@simplistix.co.uk>	
	<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>	
	<4AA61606.6060002@simplistix.co.uk>	
	<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>	
	<4AAA5896.9000807@simplistix.co.uk>
	<94bdd2610909110723t2fbc394cn2f915f36d8706adc@mail.gmail.com>
Message-ID: <4AB35BA3.3060304@simplistix.co.uk>

Tarek Ziad? wrote:
>> [setup.cfg]
>>
>> long_description_path: README.txt
>>
>>
>>> long_description_path can't be added in the final PKG-INFO because
>>> we want a self-contained metadata static file that doesn't require an
>>> extra resource (like an external file)
>> Why this requirement?
> 
> Where this external file would it be located ?
> There's just *one* metadata file that contains everything.

Fine, so when you generate setup.cfg from setup.cfg.in, process the 
long_description_path at that point and only insert the resulting 
long_description in setup.cfg .

cheers,

Chris

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

From chris at simplistix.co.uk  Fri Sep 18 12:15:04 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 11:15:04 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <op.u0bfy60w1q4jlt@whymac>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>
	<op.u0bfy60w1q4jlt@whymac>
Message-ID: <4AB35DA8.9090004@simplistix.co.uk>

Sridhar Ratnakumar wrote:
>> I may be missing some context, but I did about an hour of googling around
>> before responding here, and for the life of me I can't find a simple 
>> answer
>> to the question: how do I currently programatically get the metadata 
>> out of
>> a distribution?
> 
> http://pypi.python.org/pypi/pkginfo/

Yeah, but you have to remember to sacrifice the right goats to end up 
with the right things in whatever files pkginfo uses :-(

Chris

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

From chris at simplistix.co.uk  Fri Sep 18 12:17:40 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Sep 2009 11:17:40 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090912145036.GB13831@laurie.devork>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<20090911163232.GB2903@laurie.devork>	<94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
	<20090912145036.GB13831@laurie.devork>
Message-ID: <4AB35E44.9070707@simplistix.co.uk>

Floris Bruynooghe wrote:
> On Fri, Sep 11, 2009 at 07:02:53PM +0200, Tarek Ziad? wrote:
>> On Fri, Sep 11, 2009 at 6:32 PM, Floris Bruynooghe
>> <floris.bruynooghe at gmail.com> wrote:
>>> On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
>>> [...]
>>>> That can be dropped since we have '==' and it's all strings.
>>> '2.6' < '2.10'?
>>>
>>> Although not close you must be wary of this.  Bring on PEP 386 ;-)
>> Right. Maybe we can drop < >, >= and >=, completely.
>>
>> In real world use cases, we can use "or" to make a section work for
>> 2.6, 3.1, etc.. for python versions.
>>
>> I can't think of a use case where "in" and "==" is not enough.
> 
> Version comparison would be nice though.  Taking your example from
> your blog post: if I where to try to install that on Python 2.4 I'd
> have to edit the condition of the [py25] section to "in ('2.4',
> '2.5')".  Maybe this is what you want though, in case you explicitly
> don't support for 2.4.  OTOH it's nice if things would just work in
> case of developers simply not having tried earlier versions.
> 
> This also shows how "in" implies a tuple or a list as data type, your
> mini-language was trying to avoid that.  Or did I miss something?

A lot of these problems would go away if we could just treat "Python" as 
a package like every other package when it comes to dependencies.

Why is that so hard to do?

Chris

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

From reinout at vanrees.org  Fri Sep 18 14:51:00 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 18 Sep 2009 12:51:00 +0000 (UTC)
Subject: [Distutils] non-ascii characters in long description
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
	<94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
	<20090917183154.GA14158@fridge.pov.lt>
Message-ID: <h8vvnk$j0s$1@ger.gmane.org>

On 2009-09-17, Marius Gedminas <marius at pov.lt> wrote:
>
>> You can register.patch post_to_server to pre-process all values in the
>> "data" argument, so they are
>> all in unicode, then call the real one.
>
> This sounds mysterious; I'll wait and look at Reinout's package in a
> while (assuming he choses to do this).

"register.patch distutils" doesn't give me a useful google result on the first
two pages, so I'm just going to stick with the SuperMagicString.

One hack or the other: this one works :-)

Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"


From ziade.tarek at gmail.com  Fri Sep 18 15:09:57 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 18 Sep 2009 15:09:57 +0200
Subject: [Distutils] non-ascii characters in long description
In-Reply-To: <h8vvnk$j0s$1@ger.gmane.org>
References: <h8tb2v$a6p$1@ger.gmane.org>
	<94bdd2610909170600o5e618a94r78b69d665a13b60b@mail.gmail.com>
	<h8tdmq$kg5$1@ger.gmane.org>
	<94bdd2610909170646w148243b5k4b6007952ab09c26@mail.gmail.com>
	<20090917183154.GA14158@fridge.pov.lt> <h8vvnk$j0s$1@ger.gmane.org>
Message-ID: <94bdd2610909180609v15e5c7f7hee0cf934de258d73@mail.gmail.com>

Oups typo : post_to_server in the register class

On Sep 18, 2009 2:51 PM, "Reinout van Rees" <reinout at vanrees.org> wrote:

On 2009-09-17, Marius Gedminas <marius at pov.lt> wrote: > >> You can
register.patch post_to_server to ...
"register.patch distutils" doesn't give me a useful google result on the
first
two pages, so I'm just going to stick with the SuperMagicString.

One hack or the other: this one works :-)

Reinout

--

Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org Software
developer at http://www...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090918/fead2a95/attachment.htm>

From eric at trueblade.com  Fri Sep 18 15:13:54 2009
From: eric at trueblade.com (Eric Smith)
Date: Fri, 18 Sep 2009 09:13:54 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4AB35BA3.3060304@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>		<4A9BBA2B.6010903@simplistix.co.uk>		<94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>		<4AA4F94C.9080702@simplistix.co.uk>		<23CAC1AA-9399-405A-A7E6-64F4C052BEC1@mac.com>		<4AA6136A.7080904@simplistix.co.uk>		<94bdd2610909080126j57b18e04ve5b996d1fcf6722e@mail.gmail.com>		<4AA61606.6060002@simplistix.co.uk>		<94bdd2610909080520p5c33f0e6g90ade400e33779bc@mail.gmail.com>		<4AAA5896.9000807@simplistix.co.uk>	<94bdd2610909110723t2fbc394cn2f915f36d8706adc@mail.gmail.com>
	<4AB35BA3.3060304@simplistix.co.uk>
Message-ID: <4AB38792.2080807@trueblade.com>

Chris Withers wrote:
> Tarek Ziad? wrote:
>>> [setup.cfg]
>>>
>>> long_description_path: README.txt
>>>
>>>
>>>> long_description_path can't be added in the final PKG-INFO because
>>>> we want a self-contained metadata static file that doesn't require an
>>>> extra resource (like an external file)
>>> Why this requirement?
>>
>> Where this external file would it be located ?
>> There's just *one* metadata file that contains everything.
> 
> Fine, so when you generate setup.cfg from setup.cfg.in, process the 
> long_description_path at that point and only insert the resulting 
> long_description in setup.cfg .

Exactly.

And I'll probably not use a setup.cfg.in, I'll have some other mechanism 
for creating setup.cfg (from a variety of company-specific config files) 
for my own internal packages. But it won't make a difference, as long as 
a correct setup.cfg gets generated.

Which is why I think that while setup.cfg.in might be useful for many 
people, it's not the important part. It's setup.cfg that needs to be 
nailed down.

Eric.

From regebro at gmail.com  Fri Sep 18 15:32:46 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Sep 2009 15:32:46 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
Message-ID: <319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>

2009/9/18 Lennart Regebro <regebro at gmail.com>:
> 2. There is now a build_py that will run 2to3 on the code. That's
> cool, but there doesn't seem to be a way to enable it. It looks for a
> setuptools.use_2to3 attribute to check if it should be used, but I
> couldn't see a way of setting that. Passing it in as a parameter to
> setup() gives you a warning, that the parameter is unknown.
>
> How should it be done?

OK, seems i can do this with
    import setuptools
    setuptools.run_2to3 = True

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

From alex.gronholm at nextday.fi  Fri Sep 18 15:42:17 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Fri, 18 Sep 2009 16:42:17 +0300
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
Message-ID: <4AB38E39.2040805@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/9/18 Lennart Regebro <regebro at gmail.com>:
>   
>> 2. There is now a build_py that will run 2to3 on the code. That's
>> cool, but there doesn't seem to be a way to enable it. It looks for a
>> setuptools.use_2to3 attribute to check if it should be used, but I
>> couldn't see a way of setting that. Passing it in as a parameter to
>> setup() gives you a warning, that the parameter is unknown.
>>
>> How should it be done?
>>     
>
> OK, seems i can do this with
>     import setuptools
>     setuptools.run_2to3 = True
>   
This should not be necessary. The run_2to3 keyword argument to setup() 
is the way to go. I haven't had a good chance to check out Martin's 
work, but if that option is missing, I'll add it.

From regebro at gmail.com  Fri Sep 18 15:46:15 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Sep 2009 15:46:15 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <4AB38E39.2040805@nextday.fi>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
Message-ID: <319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>

2009/9/18 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> This should not be necessary. The run_2to3 keyword argument to setup() is
> the way to go.

Yeah, but that's not added. But if all others agree that a keyword is
better then we should go with that.

> I haven't had a good chance to check out Martin's work, but
> if that option is missing, I'll add it.

Nah, I'll already added it, but not pushed it yet. :) I want
confirmation from the list, and some more testing.
(I'm using zope.interface as a testing platform at the moment).

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

From ziade.tarek at gmail.com  Fri Sep 18 15:51:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 18 Sep 2009 15:51:08 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
Message-ID: <94bdd2610909180651y6d431ec9i4330c4ef318a399f@mail.gmail.com>

2009/9/18 Lennart Regebro <regebro at gmail.com>:
> 2009/9/18 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>> This should not be necessary. The run_2to3 keyword argument to setup() is
>> the way to go.
>
> Yeah, but that's not added. But if all others agree that a keyword is
> better then we should go with that.

+1

>
>> I haven't had a good chance to check out Martin's work, but
>> if that option is missing, I'll add it.
>
> Nah, I'll already added it, but not pushed it yet. :) I want
> confirmation from the list, and some more testing.
> (I'm using zope.interface as a testing platform at the moment).

Also, a full example on "how to use distribute with python 3" in the docs/
would be nice to have.

btw, I propose to release 0.6.2 as soon as py3 support has been tested
by a few more people.

Tarek

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

From regebro at gmail.com  Fri Sep 18 16:15:39 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Sep 2009 16:15:39 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <94bdd2610909180651y6d431ec9i4330c4ef318a399f@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<94bdd2610909180651y6d431ec9i4330c4ef318a399f@mail.gmail.com>
Message-ID: <319e029f0909180715v4236751es5c21251bea2d01da@mail.gmail.com>

2009/9/18 Tarek Ziad? <ziade.tarek at gmail.com>:
> Also, a full example on "how to use distribute with python 3" in the docs/
> would be nice to have.

Absolutely.

> btw, I propose to release 0.6.2 as soon as py3 support has been tested
> by a few more people.

Right. I'm working on also reimplementing the rest of the 2to3 options
into keywords, and I'll make a quick documentation of this, and notify
people here. Should be done today or tomorrow.


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

From regebro at gmail.com  Fri Sep 18 18:02:39 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 18 Sep 2009 18:02:39 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909180715v4236751es5c21251bea2d01da@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<94bdd2610909180651y6d431ec9i4330c4ef318a399f@mail.gmail.com>
	<319e029f0909180715v4236751es5c21251bea2d01da@mail.gmail.com>
Message-ID: <319e029f0909180902p27a32f9bp18f65d7bbb370bb6@mail.gmail.com>

2009/9/18 Lennart Regebro <regebro at gmail.com>:
> Right. I'm working on also reimplementing the rest of the 2to3 options
> into keywords, and I'll make a quick documentation of this, and notify
> people here. Should be done today or tomorrow.

Checked in. Also made the test command run 2to3 if necessary. It now
works on my zope.interfaces Python3-branch.

Will try to document this during the weekend.

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

From sridharr at activestate.com  Fri Sep 18 20:13:44 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 18 Sep 2009 11:13:44 -0700
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
Message-ID: <op.u0gsw6p21q4jlt@whymac>

On Tue, 15 Sep 2009 17:42:24 -0700, <exarkun at twistedmatrix.com> wrote:

> What use cases do we have?  There's the one described above, which lots  
> of people have been talking about.  I think there's another one related  
> to target Python version - eg, on Python 2.3, depend on simplejson, but  
> on Python 2.6, don't.  What else?

Today I stumbled on a project called PyGUI that depends on packages based  
on the platform.

   http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

"""
MacOSX - requires PyObjC (tested with PyObjC-1.2)
Linux - requires pygtk (tested with pygtk-2.14.0 and Gtk+-2.14.7)
Windows - requires pywin32 (tested with pywin32-213) and ctypes (included  
with Python 2.5 and later)
"""

If we use setuptools' extras like syntax, this would be:

   extras_require={'platform=macosx': ['pyobjc'],
                   'platform=win32': ['pywin32', 'ctypes']
                   'platform=unix': ['pygtk']}

-srid


From michal at michalklich.com  Fri Sep 18 21:55:27 2009
From: michal at michalklich.com (=?utf-8?q?Micha=C5=82_Klich?=)
Date: Fri, 18 Sep 2009 21:55:27 +0200
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section of
	spec file
Message-ID: <200909182155.27544.klich.michal@gmail.com>



Dnia czwartek 17 wrze?nia 2009 o 23:07:17 A. Cavallo napisa?(a):
> Hi,
> as rule of thumb (followed now by all major distros) you should not put any
> script in %postun, %postinst etc sections.
> 
> Regards,
> Antonio
> 
> > Hello,
> > I am looking for some advise in creating rpm package using bdist_rpm.
> > I have managed to create post_install part using information
> > http://stackoverflow.com/questions/1321270/how-to-extend-distutils-with-a
> >-s imple-post-install-script Now i would like to add some code to %postun
> > part of spec file to revert changes done by my post_install command.
> > Is there a way to add it in setup.py or do i have to manually edit spec
> > file?
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 

It is not mentioned in Fedora guidelines
http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelines

Ok, how would you handle creating symlink in setup.py? and removing it of 
course when uninstalling rpm. That is my goal. 
I managed to create symlink with setup.py but can not find any option for 
removing, which is i think correct as there is no uninstall option for 
setup.py.


-- 
Micha? Klich

klich.michal at gmail.com
michal at michalklich.com
http://www.michalklich.com

From tseaver at palladion.com  Fri Sep 18 22:01:01 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 18 Sep 2009 16:01:01 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AB35DA8.9090004@simplistix.co.uk>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>	<op.u0bfy60w1q4jlt@whymac>
	<4AB35DA8.9090004@simplistix.co.uk>
Message-ID: <h90otv$act$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Withers wrote:
> Sridhar Ratnakumar wrote:
>>> I may be missing some context, but I did about an hour of googling around
>>> before responding here, and for the life of me I can't find a simple 
>>> answer
>>> to the question: how do I currently programatically get the metadata 
>>> out of
>>> a distribution?
>> http://pypi.python.org/pypi/pkginfo/
> 
> Yeah, but you have to remember to sacrifice the right goats to end up 
> with the right things in whatever files pkginfo uses :-(

You bothering the goats again, Chris? ;)

pkginfo uses the standard information generated by the 'sdist',
'develop' and 'bdist_egg' commenads, and can even introspect installed
packages on Python 2.6.x.  It is documented here:

  http://packages.python.org/pkginfo/


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKs+b9+gerLs4ltQ4RApBrAKCvmK97Xd1rdrrDVgPkiDWhHA1bzACfTlHh
I9kbSb19HRCfXyaQJ4RaSSE=
=HNfh
-----END PGP SIGNATURE-----


From michal at michalklich.com  Fri Sep 18 22:22:32 2009
From: michal at michalklich.com (=?utf-8?q?Micha=C5=82_Klich?=)
Date: Fri, 18 Sep 2009 22:22:32 +0200
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section of
	spec file
In-Reply-To: <1253304017.3186.45.camel@radiator.bos.redhat.com>
References: <200909182155.27544.klich.michal@gmail.com>
	<1253304017.3186.45.camel@radiator.bos.redhat.com>
Message-ID: <200909182222.32147.klich.michal@gmail.com>

Dnia pi?tek 18 wrze?nia 2009 o 22:00:17 David Malcolm napisa?(a):
> On Fri, 2009-09-18 at 21:55 +0200, Micha? Klich wrote:
> > Dnia czwartek 17 wrze?nia 2009 o 23:07:17 A. Cavallo napisa?(a):
> > > Hi,
> > > as rule of thumb (followed now by all major distros) you should not put
> > > any script in %postun, %postinst etc sections.
> > >
> > > Regards,
> > > Antonio
> > >
> > > > Hello,
> > > > I am looking for some advise in creating rpm package using bdist_rpm.
> > > > I have managed to create post_install part using information
> > > > http://stackoverflow.com/questions/1321270/how-to-extend-distutils-wi
> > > >th-a -s imple-post-install-script Now i would like to add some code to
> > > > %postun part of spec file to revert changes done by my post_install
> > > > command. Is there a way to add it in setup.py or do i have to
> > > > manually edit spec file?
> > >
> > > _______________________________________________
> > > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > > http://mail.python.org/mailman/listinfo/distutils-sig
> >
> > It is not mentioned in Fedora guidelines
> > http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelines
> >
> > Ok, how would you handle creating symlink in setup.py? and removing it of
> > course when uninstalling rpm. That is my goal.
> > I managed to create symlink with setup.py but can not find any option for
> > removing, which is i think correct as there is no uninstall option for
> > setup.py.
> 
> Why is the symlink not simply a part of the rpm payload?  That way it
> would be created on installation and removed on removal.
> 
> 
> Dave
> 

Symlink is pointing to x86_64 arch file, i would like to have noarch rpm.
It is pointing to /usr/bin/consolehelper as application needs to be run with 
root rights.
I might be doing something wrong here but this is my first package.


-- 
Micha? Klich

klich.michal at gmail.com
michal at michalklich.com
http://www.michalklich.com

From dmalcolm at redhat.com  Fri Sep 18 22:00:17 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Fri, 18 Sep 2009 16:00:17 -0400
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section	of
	spec file
In-Reply-To: <200909182155.27544.klich.michal@gmail.com>
References: <200909182155.27544.klich.michal@gmail.com>
Message-ID: <1253304017.3186.45.camel@radiator.bos.redhat.com>

On Fri, 2009-09-18 at 21:55 +0200, Micha? Klich wrote:
> 
> Dnia czwartek 17 wrze?nia 2009 o 23:07:17 A. Cavallo napisa?(a):
> > Hi,
> > as rule of thumb (followed now by all major distros) you should not put any
> > script in %postun, %postinst etc sections.
> > 
> > Regards,
> > Antonio
> > 
> > > Hello,
> > > I am looking for some advise in creating rpm package using bdist_rpm.
> > > I have managed to create post_install part using information
> > > http://stackoverflow.com/questions/1321270/how-to-extend-distutils-with-a
> > >-s imple-post-install-script Now i would like to add some code to %postun
> > > part of spec file to revert changes done by my post_install command.
> > > Is there a way to add it in setup.py or do i have to manually edit spec
> > > file?
> > 
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> > 
> 
> It is not mentioned in Fedora guidelines
> http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelines
> 
> Ok, how would you handle creating symlink in setup.py? and removing it of 
> course when uninstalling rpm. That is my goal. 
> I managed to create symlink with setup.py but can not find any option for 
> removing, which is i think correct as there is no uninstall option for 
> setup.py.

Why is the symlink not simply a part of the rpm payload?  That way it
would be created on installation and removed on removal.


Dave


From dmalcolm at redhat.com  Fri Sep 18 23:43:08 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Fri, 18 Sep 2009 17:43:08 -0400
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section	of
	spec file
In-Reply-To: <200909182222.32147.klich.michal@gmail.com>
References: <200909182155.27544.klich.michal@gmail.com>
	<1253304017.3186.45.camel@radiator.bos.redhat.com>
	<200909182222.32147.klich.michal@gmail.com>
Message-ID: <1253310188.3186.53.camel@radiator.bos.redhat.com>

On Fri, 2009-09-18 at 22:22 +0200, Micha? Klich wrote:
> Dnia pi?tek 18 wrze?nia 2009 o 22:00:17 David Malcolm napisa?(a):
> > On Fri, 2009-09-18 at 21:55 +0200, Micha? Klich wrote:
> > > Dnia czwartek 17 wrze?nia 2009 o 23:07:17 A. Cavallo napisa?(a):
> > > > Hi,
> > > > as rule of thumb (followed now by all major distros) you should not put
> > > > any script in %postun, %postinst etc sections.
> > > >
> > > > Regards,
> > > > Antonio
> > > >
> > > > > Hello,
> > > > > I am looking for some advise in creating rpm package using bdist_rpm.
> > > > > I have managed to create post_install part using information
> > > > > http://stackoverflow.com/questions/1321270/how-to-extend-distutils-wi
> > > > >th-a -s imple-post-install-script Now i would like to add some code to
> > > > > %postun part of spec file to revert changes done by my post_install
> > > > > command. Is there a way to add it in setup.py or do i have to
> > > > > manually edit spec file?
> > > >
> > > > _______________________________________________
> > > > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > > > http://mail.python.org/mailman/listinfo/distutils-sig
> > >
> > > It is not mentioned in Fedora guidelines
> > > http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelines
> > >
> > > Ok, how would you handle creating symlink in setup.py? and removing it of
> > > course when uninstalling rpm. That is my goal.
> > > I managed to create symlink with setup.py but can not find any option for
> > > removing, which is i think correct as there is no uninstall option for
> > > setup.py.
> > 
> > Why is the symlink not simply a part of the rpm payload?  That way it
> > would be created on installation and removed on removal.
> > 
> > 
> > Dave
> > 
> 
> Symlink is pointing to x86_64 arch file, i would like to have noarch rpm.
> It is pointing to /usr/bin/consolehelper as application needs to be run with 
> root rights.
> I might be doing something wrong here but this is my first package.

Although the target (/usr/bin/consolehelper) of the symlink is a
compiled binary and thus architecture-specific, the symlink's path and
thus the symlink itself is architecture-independent, so it ought to be
possible to create a noarch rpm.

I can think of a couple of approaches:
(i) You can write a generic setup.py script and invoke the "bdist_rpm"
command, as you're doing, and have this generate a specfile for your RPM
and build it.  The specfile is autogenerated.

If I'm reading the distutils code correctly this will internally call
the "install" command, and scrape the installed payload into a file
named "INSTALLED_FILES", which will get referenced in the autogenerated
specfile.

I believe one can create a symlink from your script to consolehelper
using:
  # caution; untested code!
  # not sure if I got src/dst the right way around
  distutils.file_util.copy_file('/usr/bin/consolehelper',
                                '/usr/bin/your_script',
                                link='sym')

However, reading the consolehelper manpage, it looks like you may also
need to set up files under /etc/pam.d/ (not my area of expertise)

(ii) You can write a generic setup.py script, and also write a .spec
file.  You then create the symlink in the specfile, and add it to the %
files section.  In Fedora we have a script "rpmdev-newspec" that makes
it easy to create new boilerplate .spec files for a setup.py file.  The
downside to this approach is that you now have a .spec file separate
from your setup.py, and have to maintain both.  It makes sense in our
world where Python is only one of many technologies, and rpm is the
native packaging format (for good or ill).

Hope this is helpful
Dave


From wosc at wosc.de  Sat Sep 19 07:27:55 2009
From: wosc at wosc.de (Wolfgang Schnerring)
Date: Sat, 19 Sep 2009 07:27:55 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
Message-ID: <878wgbcxlw.fsf@elzar.ws.whq.gocept.com>

* Lennart Regebro <regebro at gmail.com> [2009-09-18 15:46]:
> 2009/9/18 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>> This should not be necessary. The run_2to3 keyword argument to setup() is
>> the way to go.
>> I haven't had a good chance to check out Martin's work, but
>> if that option is missing, I'll add it.
>
> Nah, I'll already added it, but not pushed it yet. :) I want
> confirmation from the list, and some more testing.
> (I'm using zope.interface as a testing platform at the moment).

The idea of this *not* being a setup() argument was to keep
compatibility with setuptools (since it will complain about arguments it
doesn't understand). This would enable a package to use setuptools or
distribute (or whatever ;) for python2, and only require distribute for
the python3/2to3 goodness.

Wolfgang


From regebro at gmail.com  Sat Sep 19 08:16:25 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 19 Sep 2009 08:16:25 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
Message-ID: <319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>

2009/9/19 Wolfgang Schnerring <wosc at wosc.de>:
> The idea of this *not* being a setup() argument was to keep
> compatibility with setuptools (since it will complain about arguments it
> doesn't understand). This would enable a package to use setuptools or
> distribute (or whatever ;) for python2, and only require distribute for
> the python3/2to3 goodness.

Ah, OK. Well, I added the extra parameters in via an **extras dict in
zope.interfaces, so I didn't think of that. Still, I probably prefer
that we keep one API, and not two. :) The warning that you'll get
under setuptools is not an actual problem is it?

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

From strawman at astraw.com  Sat Sep 19 09:38:15 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sat, 19 Sep 2009 00:38:15 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB48146.8090606@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net>
Message-ID: <4AB48A67.1010808@astraw.com>

Gerry Reno wrote:
> Ok, I got the __file__ problem solved but now I want to do this whole
> deb pkg create as just a single command in my own setup.py.  How can I
> do this?
>
> I'm thinking something like:
>
> # my setup.py
> import stdeb
>
> Command(mycmd):
>    initialize_option...
>    finalize_option...
>    run
>       sub_commands=[('sdist_dsc', None),]
>       system('dpgk-source ...)
>       print ".deb is here..."
>
> Would this work and is this how to do it?
Do you really need to run it directly from setup.py? Can't you run it
from a shell script or write a python script making lots of use of
subprocess? The reason I ask is that distutils isn't fun to extend, and
as you're already going to be running on a Debian-based system, I can't
see what's to be gained.

What you want to do is probably possible, but I don't have the
motivation to do it myself. I guess it could allow a bdist_deb option,
but IMO that's not particularly desirable -- the Debian source package
emitted by stdeb can be compiled for any Debian derivative for any
version (provided the dependencies are met) -- whereas the .deb will
only have defined behavior on the Debian/Ubuntu release on which it was
built.

-Andrew

From greno at verizon.net  Sat Sep 19 08:59:18 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 19 Sep 2009 02:59:18 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB315CE.6060104@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
Message-ID: <4AB48146.8090606@verizon.net>

Ok, I got the __file__ problem solved but now I want to do this whole 
deb pkg create as just a single command in my own setup.py.  How can I 
do this?

I'm thinking something like:

# my setup.py
import stdeb

Command(mycmd):
    initialize_option...
    finalize_option...
    run
       sub_commands=[('sdist_dsc', None),]
       system('dpgk-source ...)
       print ".deb is here..."

Would this work and is this how to do it?

Regards,
Gerry


Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> sudo easy_install stdeb  # brought in stdeb 0.3
>>
>> $ cd myappdir # where my setup.py is located
>>
>> $# following http://github.com/astraw/stdeb/  quickstart 1
>>
>> $ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \
>>     
>>>   cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \
>>>   dpkg-buildpackage -rfakeroot -uc -us && \
>>>   cd ../.. &&
>>>   echo ".deb created successfully in deb_dist/"
>>>       
>> Traceback (most recent call last):
>>  File "<string>", line 1, in <module>
>>  File "setup.py", line 41, in <module>
>>   
>> sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),
>> "bin"))
>> NameError: name '__file__' is not defined
>>     
>
> You can use something more elaborate like
>
> python -c "import
> stdeb,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> sdist_dsc
>
> for the first line.
>
>
>   


From ziade.tarek at gmail.com  Sat Sep 19 10:29:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 19 Sep 2009 10:29:00 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <op.u0gsw6p21q4jlt@whymac>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<op.u0gsw6p21q4jlt@whymac>
Message-ID: <94bdd2610909190129k41104c30wea9b4d27738d6e04@mail.gmail.com>

On Fri, Sep 18, 2009 at 8:13 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
> On Tue, 15 Sep 2009 17:42:24 -0700, <exarkun at twistedmatrix.com> wrote:
>
>> What use cases do we have? ?There's the one described above, which lots of
>> people have been talking about. ?I think there's another one related to
>> target Python version - eg, on Python 2.3, depend on simplejson, but on
>> Python 2.6, don't. ?What else?
>
> Today I stumbled on a project called PyGUI that depends on packages based on
> the platform.
>
> ?http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
> """
> MacOSX - requires PyObjC (tested with PyObjC-1.2)
> Linux - requires pygtk (tested with pygtk-2.14.0 and Gtk+-2.14.7)
> Windows - requires pywin32 (tested with pywin32-213) and ctypes (included
> with Python 2.5 and later)
> """
>
> If we use setuptools' extras like syntax, this would be:
>
> ?extras_require={'platform=macosx': ['pyobjc'],
> ? ? ? ? ? ? ? ? ?'platform=win32': ['pywin32', 'ctypes']
> ? ? ? ? ? ? ? ? ?'platform=unix': ['pygtk']}
>

I think you miss the "included with Python 2.5 and later" part

Anyway, I find it rather verbose compared to what we have proposed so
far in setup.cfg

I think the latest proposal, where the condition is located in the section name
is good.

So I'll just BDFL a bit here to move things forward.  I am adding it in
Distutils, with a notification mail in python-dev, and a blog entry
describing the result.

Thanks all for the feedback !

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

From kiorky at cryptelium.net  Sat Sep 19 13:29:31 2009
From: kiorky at cryptelium.net (kiorky)
Date: Sat, 19 Sep 2009 13:29:31 +0200
Subject: [Distutils] [buildout] recipes useful to setup a whole machine
In-Reply-To: <4AB2A609.9050606@simplistix.co.uk>
References: <4AB2A609.9050606@simplistix.co.uk>
Message-ID: <4AB4C09B.1020608@cryptelium.net>

Hi Chris,

You can have a look to minitage (http://minitage.org/).
Minitage have 3 main parts:
* package and dependencies management and isolation (minitage.core)
	- construct and manage softwares in total isolation from the host and
	  thus, platform independant (unix) (libxml, postgres, python & so on.)
* paster templates (minitage.paste & minitage.paste.extras)
	- Projects templates (plone3, django, etc.)
	- Instances intialization (postgresql, mysql, openldap, varnish, CAS (tomcat)...)
* The buildout recipes:
	- minitage.recipe
		- assembler package
	- minitage.recipe.common
		- abstract recipe for the other recipes
	- minitage.recipe.cmmi
		- compile & assemble stuff using the CMMI dance
	- minitage.recipe.du
		- install python sotwaren using python setup.py install
	- minitage.recipe.egg
		- install python eggs (similar to zc.recipe.egg)
	- minitage.recipe.fetch:
		- Fetch something somewhere using urllib2, bzr, git, hg or svn
	- minitage.recipe.printer
		similar to the buildout.dumppickedversion buildout extension.
	- minitage.recipe.scripts
		- install python eggs and their associated scripts (similar to
zc.recipe.egg:scripts)
	- minitage.recipe.wsgi
		- Construct a mod_wsgi compatible template to serve a Paste configuration

Useless to say that the eggs and cmmi recipes will get in their environment the
dependencies they declared in their 'minibuild'.

From exemple, you have made your project 'p3' depends on libxml2.
During the lxml installation with the minitage.recipe.egg, it would be compiled
and linked with the libxml2 installed via minitage under it's 'dependencies'
subdirectory.

Chris Withers a ?crit :
> Hi All,
> 
> I have a hair-brained notion of using a buildout to set up an entire
> machine. Has anyone done this before? (Jim, didn't you say ZC do this a
> lot?)
> 
> From where I'm sitting, I'm looking for a few recipes:
> 
> - what's the best download & cmmi recipe out there?
> 
> - what's the best recipe for running other buildouts?
> 
> - is there a recipe available anywhere for installing/removing packages
> using aptitude?
> 
> cheers,
> 
> Chris
> 

-- 
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090919/7ae50035/attachment.pgp>

From kylemacfarlane at gmail.com  Sat Sep 19 14:48:37 2009
From: kylemacfarlane at gmail.com (Kyle MacFarlane)
Date: Sat, 19 Sep 2009 13:48:37 +0100
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
Message-ID: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>

The way setuptools (and thus buildout) does namespace packages doesn't work
with how Django looks for management commands. Django only looks in the
first package in the namespace on the system path and ignores the rest.

Pip deals with namespace packages differently (with those .pth files I
think), so I gave gp.recipe.pip a go but it raises an ImportError that pip
isn't installed when it tries to install pip. Nice. But even if it did work
pip doesn't support eggs which I imagine will lead to many dependencies not
being installed.

Then I tried collective.recipe.omelette but it doesn't support zipped eggs
and so also fails with many dependencies. I can get round this by also using
the regular zc.recipe.egg but then I get loads of warnings about packages
being imported twice (but it all seems to kind of work).

So what is the proper way to do this? Django people are saying don't use
setuptools but everything seems to rely on setuptools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090919/40a55894/attachment.htm>

From hanno at hannosch.eu  Sat Sep 19 15:14:46 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 19 Sep 2009 15:14:46 +0200
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
Message-ID: <5cae42b20909190614p6091be26w1f6ed62c9de2f319@mail.gmail.com>

On Sat, Sep 19, 2009 at 2:48 PM, Kyle MacFarlane
<kylemacfarlane at gmail.com> wrote:
> The way setuptools (and thus buildout) does namespace packages doesn't work
> with how Django looks for management commands. Django only looks in the
> first package in the namespace on the system path and ignores the rest.

[...]

> So what is the proper way to do this? Django people are saying don't use
> setuptools but everything seems to rely on setuptools.

Namespace packages are a feature of setuptools [1]. If you don't want
to use setuptools, you cannot use namespace packages. You have to
choose either or.

I'd try to convince the Django folks to make their "management console
lookup" pluggable in some way, so you could implement a
setuptools-aware lookup and use it instead.

Hanno

[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages

From pje at telecommunity.com  Sat Sep 19 16:45:21 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 19 Sep 2009 10:45:21 -0400
Subject: [Distutils] Buildout + namespace packages + Django management
 commands?
In-Reply-To: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.co
 m>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
Message-ID: <20090919144517.4D9D73A4079@sparrow.telecommunity.com>

At 01:48 PM 9/19/2009 +0100, Kyle MacFarlane wrote:
>The way setuptools (and thus buildout) does namespace packages 
>doesn't work with how Django looks for management commands. Django 
>only looks in the first package in the namespace on the system path 
>and ignores the rest.

If they use the package's __path__ attribute, they'll find its 
contents, whether someone is using pkgutil.extend_path, .pth files, 
or setuptools.  They don't have to support setuptools to support 
namespace packages, just pay attention to the __path__ variable 
that's part of standard Python.


From strawman at astraw.com  Sat Sep 19 18:07:54 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sat, 19 Sep 2009 09:07:54 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB4F50B.2090704@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB48A67.1010808@astraw.com>
	<4AB4F50B.2090704@verizon.net>
Message-ID: <4AB501DA.70601@astraw.com>

Gerry Reno wrote:
>> What you want to do is probably possible, but I don't have the
>> motivation to do it myself. I guess it could allow a bdist_deb option,
>> but IMO that's not particularly desirable -- the Debian source package
>> emitted by stdeb can be compiled for any Debian derivative for any
>> version (provided the dependencies are met)
> Having a single command for .deb doesn't preclude stdeb from emitting
> source package .dsc.

OK, if you're sure... :)

I'd suggest attempting to add a "bdist_deb" command to stdeb's
stdeb/command/ directory for use with distutils. Then register it with
entry_points in the setup.py file.

Note that you wouldn't want bdist_deb to inherit the binary generation
stuff from bdist_dumb or friends -- you'd specifically want to call out
the the appropriate debian command (dpkg-buildpackage).

I'd be happy to include such a thing with stdeb, though I'd probably not
use it much myself -- I like having a single source package that I just
recompile for the different distributions.

-Andrew

From greno at verizon.net  Sat Sep 19 17:13:15 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 19 Sep 2009 11:13:15 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB48A67.1010808@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB48A67.1010808@astraw.com>
Message-ID: <4AB4F50B.2090704@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Ok, I got the __file__ problem solved but now I want to do this whole
>> deb pkg create as just a single command in my own setup.py.  How can I
>> do this?
>>
>> I'm thinking something like:
>>
>> # my setup.py
>> import stdeb
>>
>> Command(mycmd):
>>    initialize_option...
>>    finalize_option...
>>    run
>>       sub_commands=[('sdist_dsc', None),]
>>       system('dpgk-source ...)
>>       print ".deb is here..."
>>
>> Would this work and is this how to do it?
>>     
> Do you really need to run it directly from setup.py? 
Yes.
> Can't you run it
> from a shell script or write a python script making lots of use of
> subprocess? The reason I ask is that distutils isn't fun to extend, and
> as you're already going to be running on a Debian-based system, I can't
> see what's to be gained.
>
> What you want to do is probably possible, but I don't have the
> motivation to do it myself. I guess it could allow a bdist_deb option,
> but IMO that's not particularly desirable -- the Debian source package
> emitted by stdeb can be compiled for any Debian derivative for any
> version (provided the dependencies are met)
Having a single command for .deb doesn't preclude stdeb from emitting 
source package .dsc.
>  -- whereas the .deb will
> only have defined behavior on the Debian/Ubuntu release on which it was
> built.
>   
Well of course, just like any other binary package target.
I don't see where there is any conflict.

Regards,
Gerry



From greno at verizon.net  Sat Sep 19 18:23:41 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 19 Sep 2009 12:23:41 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB501DA.70601@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB48A67.1010808@astraw.com>
	<4AB4F50B.2090704@verizon.net> <4AB501DA.70601@astraw.com>
Message-ID: <4AB5058D.5010902@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>>> What you want to do is probably possible, but I don't have the
>>> motivation to do it myself. I guess it could allow a bdist_deb option,
>>> but IMO that's not particularly desirable -- the Debian source package
>>> emitted by stdeb can be compiled for any Debian derivative for any
>>> version (provided the dependencies are met)
>>>       
>> Having a single command for .deb doesn't preclude stdeb from emitting
>> source package .dsc.
>>     
>
> OK, if you're sure... :)
>
> I'd suggest attempting to add a "bdist_deb" command to stdeb's
> stdeb/command/ directory for use with distutils. Then register it with
> entry_points in the setup.py file.
>
> Note that you wouldn't want bdist_deb to inherit the binary generation
> stuff from bdist_dumb or friends -- you'd specifically want to call out
> the the appropriate debian command (dpkg-buildpackage).
>
> I'd be happy to include such a thing with stdeb, though I'd probably not
> use it much myself -- I like having a single source package that I just
> recompile for the different distributions.
>   
Well, I think it would be better if it were part of stdeb. 
And I like calling it 'bdist_deb'.  That makes sense.  And it should 
emit the .dsc as well as the .deb.
My use case is providing consumers of my apps with a way to gen their 
own source and binary packages without them needing to know anything 
about the "mechanics" of the process.  I've already got good feedback on 
this with 'bdist_rpm' and if we had 'bdist_deb' then that would add a 
good deal more capability.  For bdist_rpm we drive it from setup.cfg and 
would be good if bdist_deb configuration behavior would be the same.

Regards,
Gerry




From greno at verizon.net  Sun Sep 20 05:24:09 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 19 Sep 2009 23:24:09 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB48146.8090606@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net>
Message-ID: <4AB5A059.9060701@verizon.net>

Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb' command.
The entire thing is working except for the last subcommand for 
dpkg-buildpackage is trying to build for python2.4 and failing.

dpkg-buildpackage fails in the fakeroot...
...
debian/rules build
python2.4 -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
build
Traceback (most recent call last):
File "<string>", line 1, in ?
File "setup.py", line 35, in ?
import stdeb
ImportError: No module named stdeb
make: *** [build-python2.4] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

Is this something to do with python versions?
So how do I limit the python versions for dpkg-buildpackage?

stdeb is 0.3
$ python -V
Python 2.5.2


Regards,
Gerry





Gerry Reno wrote:
> Ok, I got the __file__ problem solved but now I want to do this whole 
> deb pkg create as just a single command in my own setup.py. How can I 
> do this?
>
> I'm thinking something like:
>
> # my setup.py
> import stdeb
>
> Command(mycmd):
> initialize_option...
> finalize_option...
> run
> sub_commands=[('sdist_dsc', None),]
> system('dpgk-source ...)
> print ".deb is here..."
>


From strawman at astraw.com  Sun Sep 20 06:36:18 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sat, 19 Sep 2009 21:36:18 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB5A059.9060701@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
Message-ID: <4AB5B142.7030402@astraw.com>

Gerry Reno wrote:
> Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb'
> command.

Great.

> The entire thing is working except for the last subcommand for
> dpkg-buildpackage is trying to build for python2.4 and failing.
>
> dpkg-buildpackage fails in the fakeroot...
> ...
> debian/rules build
> python2.4 -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> build
> Traceback (most recent call last):
> File "<string>", line 1, in ?
> File "setup.py", line 35, in ?
> import stdeb
> ImportError: No module named stdeb
> make: *** [build-python2.4] Error 1
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
>
> Is this something to do with python versions?
> So how do I limit the python versions for dpkg-buildpackage?
To answer your question directly[*]:

create an stdeb.cfg file like the following and put in the
distribution_name.egg-info directory. (See "Customizing the produced
Debian source package" at http://github.com/astraw/stdeb ).

[default]
XS-Python-Version: 2.5

[*] Note: I think if you switch to stdeb 0.4 you won't need stdeb
installed for all Python versions to run debian/rules. There is a much
cleaner infrastructure making use of debhelper 7. At this point, I
suggest downloading the 0.4 branch and working from there. I don't think
any of your changes so far will be hard to port, but working on
modifying debian/rules in the 0.3 branch doesn't have much of a future.
If you're not a git person, you can simply download the latest version
of the master branch by clicking the "download" button at
http://github.com/astraw/stdeb (not the "Downloads" tab). I hope with
stdeb 0.4 this won't be necessary.

-Andrew

From greno at verizon.net  Sun Sep 20 07:09:59 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 01:09:59 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB5A059.9060701@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
Message-ID: <4AB5B927.2050905@verizon.net>

Ok, I found how to control the python version: XS-Python-Version

So now it is using python2.5 but dpkg-buildpackage hits an error:
error: option --single-version-externally-managed not recognized

What is this option?
I've been searching but I don't find how to solve this.
Is there a way to fix this?

Regards,
Gerry


Gerry Reno wrote:
> Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb' 
> command.
> The entire thing is working except for the last subcommand for 
> dpkg-buildpackage is trying to build for python2.4 and failing.
>
> dpkg-buildpackage fails in the fakeroot...
> ...
> debian/rules build
> python2.4 -c "import 
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
> build
> Traceback (most recent call last):
> File "<string>", line 1, in ?
> File "setup.py", line 35, in ?
> import stdeb
> ImportError: No module named stdeb
> make: *** [build-python2.4] Error 1
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
>
> Is this something to do with python versions?
> So how do I limit the python versions for dpkg-buildpackage?
>
> stdeb is 0.3
> $ python -V
> Python 2.5.2
>
>
> Regards,
> Gerry
>
>
>
>
>
> Gerry Reno wrote:
>> Ok, I got the __file__ problem solved but now I want to do this whole 
>> deb pkg create as just a single command in my own setup.py. How can I 
>> do this?
>>
>> I'm thinking something like:
>>
>> # my setup.py
>> import stdeb
>>
>> Command(mycmd):
>> initialize_option...
>> finalize_option...
>> run
>> sub_commands=[('sdist_dsc', None),]
>> system('dpgk-source ...)
>> print ".deb is here..."
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>


From kylemacfarlane at gmail.com  Sun Sep 20 10:17:23 2009
From: kylemacfarlane at gmail.com (Kyle MacFarlane)
Date: Sun, 20 Sep 2009 09:17:23 +0100
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <20090919144517.4D9D73A4079@sparrow.telecommunity.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
Message-ID: <bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>

2009/9/19 P.J. Eby <pje at telecommunity.com>
> If they use the package's __path__ attribute, they'll find its contents, whether someone is using pkgutil.extend_path, .pth files, or setuptools. ?They don't have to support setuptools to support namespace packages, just pay attention to the __path__ variable that's part of standard Python.

I was hoping more if anybody knew a recipe to get round my problem but
I had a look inside Django to see how it looks through packages.

The problem is caused by line 58 at this link raising an ImportError:
http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py

It doesn't matter what order find_module is called on various paths,
it still relies entirely on the order in sys.path. Calling find_module
on second_app before first_app will still fail if first_app is the
first app on sys.path (which suggests that something has been done
wrong even before line 58 or find_module itself doesn't support
namespaces?).

Unfortunately I've never dealt with the imp module before. What would
I need to do? Import the package (which is actually "path" in this
code), get __path__ from it and then do find_module again but with
__path__ instead?

From regebro at gmail.com  Sun Sep 20 10:56:34 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 20 Sep 2009 10:56:34 +0200
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
	<bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
Message-ID: <319e029f0909200156n30d5ba7em532a8e21d78e459@mail.gmail.com>

2009/9/20 Kyle MacFarlane <kylemacfarlane at gmail.com>:
> I was hoping more if anybody knew a recipe to get round my problem but
> I had a look inside Django to see how it looks through packages.
>
> The problem is caused by line 58 at this link raising an ImportError:
> http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py

Yeah, sorry. You can either use Django, or not use namespaces, or fix Django. :)
Django simply doesn't support namespaces in this case. Yet another
case of Django being the new Zope, although Zope has fixed that
problem since a couple of years, and Zope Products can be namespace
packages nowadays (and the special Products directory is now a
namespace).

This all is a part Djangos biggest problem: It doesn't play well with
non-Django stuff. They are however aware of this problem, and I'm sure
they would appreciate help with fixing this particular issue. In open
source it's all a matter of available programmer time. :)

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

From a.cavallo at cavallinux.eu  Sun Sep 20 12:13:17 2009
From: a.cavallo at cavallinux.eu (A. Cavallo)
Date: Sun, 20 Sep 2009 11:13:17 +0100
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section of
	spec file
In-Reply-To: <200909182155.27544.klich.michal@gmail.com>
References: <200909182155.27544.klich.michal@gmail.com>
Message-ID: <200909201113.18164.a.cavallo@cavallinux.eu>

> It is not mentioned in Fedora guidelines
> http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelines

Neither is explicitly said on any other linux distro: it is experience coming 
from building rpms that span across distros and releases.

If you type rpm -qa --scripts on a running (failrly recent) rpm based distro 
you'll notice how little scripting is going on: mostly on core packages where 
the target is well defined.


> Ok, how would you handle creating symlink in setup.py? and removing it of
> course when uninstalling rpm. That is my goal.
> I managed to create symlink with setup.py but can not find any option for
> removing, which is i think correct as there is no uninstall option for
> setup.py.

That's the scope foe the %file description, unless you're not creating an 
sdk/library in which case other rules apply. And yes none of these "rules" are 
documented (as far I know): it is just experience.

Regards,
Antonio

From a.cavallo at cavallinux.eu  Sun Sep 20 12:30:15 2009
From: a.cavallo at cavallinux.eu (A. Cavallo)
Date: Sun, 20 Sep 2009 11:30:15 +0100
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section	of
	spec file
In-Reply-To: <1253310188.3186.53.camel@radiator.bos.redhat.com>
References: <200909182155.27544.klich.michal@gmail.com>
	<200909182222.32147.klich.michal@gmail.com>
	<1253310188.3186.53.camel@radiator.bos.redhat.com>
Message-ID: <200909201130.15395.a.cavallo@cavallinux.eu>

> > Symlink is pointing to x86_64 arch file, i would like to have noarch rpm.
> > It is pointing to /usr/bin/consolehelper as application needs to be run
> > with root rights.
> > I might be doing something wrong here but this is my first package.
>
> Although the target (/usr/bin/consolehelper) of the symlink is a
> compiled binary and thus architecture-specific, the symlink's path and
> thus the symlink itself is architecture-independent, so it ought to be
> possible to create a noarch rpm.

Is it this relevant? In a typical system there're quite few packages: why 
bother to this level of detail? 

> I can think of a couple of approaches:
> (i) You can write a generic setup.py script and invoke the "bdist_rpm"
> command, as you're doing, and have this generate a specfile for your RPM
> and build it.  The specfile is autogenerated.
>
> If I'm reading the distutils code correctly this will internally call
> the "install" command, and scrape the installed payload into a file
> named "INSTALLED_FILES", which will get referenced in the autogenerated
> specfile.

This solution never really worked for me: if I remember it didn't handle the 
directories properly (at rpm uninstall it tries to rmdir /usr/bin =: ).

> However, reading the consolehelper manpage, it looks like you may also
> need to set up files under /etc/pam.d/ (not my area of expertise)
>
> (ii) You can write a generic setup.py script, and also write a .spec
> file.  You then create the symlink in the specfile, and add it to the %
> files section.  In Fedora we have a script "rpmdev-newspec" that makes

Cool I wish know this before: is available to the public?

> it easy to create new boilerplate .spec files for a setup.py file. 

Agree, it looks the old way of bdist_rpm hasn't quite catched up with rpm 
packaging recently. 

> The
> downside to this approach is that you now have a .spec file separate
> from your setup.py, and have to maintain both.  It makes sense in our
> world where Python is only one of many technologies, and rpm is the
> native packaging format (for good or ill).

It is not a big burden: I can easily manages several packages at once on my 
python distro (http://pyvm.sourceforge.net).

If I can recommend I'd go for the SuSE build service: this will make easier to 
experiment the "hands off" build a real rpm.

Regards,
Antonio





From michal at michalklich.com  Sun Sep 20 13:46:39 2009
From: michal at michalklich.com (=?utf-8?q?Micha=C5=82_Klich?=)
Date: Sun, 20 Sep 2009 13:46:39 +0200
Subject: [Distutils] Fwd: Re: distutils bdist_rpm and %postun section of
	spec file
In-Reply-To: <1253310188.3186.53.camel@radiator.bos.redhat.com>
References: <200909182155.27544.klich.michal@gmail.com>
	<200909182222.32147.klich.michal@gmail.com>
	<1253310188.3186.53.camel@radiator.bos.redhat.com>
Message-ID: <200909201346.39558.klich.michal@gmail.com>

Dnia pi?tek 18 wrze?nia 2009 o 23:43:08 David Malcolm napisa?(a):
> On Fri, 2009-09-18 at 22:22 +0200, Micha? Klich wrote:
> > Dnia pi?tek 18 wrze?nia 2009 o 22:00:17 David Malcolm napisa?(a):
> > > On Fri, 2009-09-18 at 21:55 +0200, Micha? Klich wrote:
> > > > Dnia czwartek 17 wrze?nia 2009 o 23:07:17 A. Cavallo napisa?(a):
> > > > > Hi,
> > > > > as rule of thumb (followed now by all major distros) you should not
> > > > > put any script in %postun, %postinst etc sections.
> > > > >
> > > > > Regards,
> > > > > Antonio
> > > > >
> > > > > > Hello,
> > > > > > I am looking for some advise in creating rpm package using
> > > > > > bdist_rpm. I have managed to create post_install part using
> > > > > > information
> > > > > > http://stackoverflow.com/questions/1321270/how-to-extend-distutil
> > > > > >s-wi th-a -s imple-post-install-script Now i would like to add
> > > > > > some code to %postun part of spec file to revert changes done by
> > > > > > my post_install command. Is there a way to add it in setup.py or
> > > > > > do i have to manually edit spec file?
> > > > >
> > > > > _______________________________________________
> > > > > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > > > > http://mail.python.org/mailman/listinfo/distutils-sig
> > > >
> > > > It is not mentioned in Fedora guidelines
> > > > http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelin
> > > >es
> > > >
> > > > Ok, how would you handle creating symlink in setup.py? and removing
> > > > it of course when uninstalling rpm. That is my goal.
> > > > I managed to create symlink with setup.py but can not find any option
> > > > for removing, which is i think correct as there is no uninstall
> > > > option for setup.py.
> > >
> > > Why is the symlink not simply a part of the rpm payload?  That way it
> > > would be created on installation and removed on removal.
> > >
> > >
> > > Dave
> >
> > Symlink is pointing to x86_64 arch file, i would like to have noarch rpm.
> > It is pointing to /usr/bin/consolehelper as application needs to be run
> > with root rights.
> > I might be doing something wrong here but this is my first package.
> 
> Although the target (/usr/bin/consolehelper) of the symlink is a
> compiled binary and thus architecture-specific, the symlink's path and
> thus the symlink itself is architecture-independent, so it ought to be
> possible to create a noarch rpm.
> 
> I can think of a couple of approaches:
> (i) You can write a generic setup.py script and invoke the "bdist_rpm"
> command, as you're doing, and have this generate a specfile for your RPM
> and build it.  The specfile is autogenerated.
> 
> If I'm reading the distutils code correctly this will internally call
> the "install" command, and scrape the installed payload into a file
> named "INSTALLED_FILES", which will get referenced in the autogenerated
> specfile.
> 
> I believe one can create a symlink from your script to consolehelper
> using:
>   # caution; untested code!
>   # not sure if I got src/dst the right way around
>   distutils.file_util.copy_file('/usr/bin/consolehelper',
>                                 '/usr/bin/your_script',
>                                 link='sym')
> 
> However, reading the consolehelper manpage, it looks like you may also
> need to set up files under /etc/pam.d/ (not my area of expertise)
> 
> (ii) You can write a generic setup.py script, and also write a .spec
> file.  You then create the symlink in the specfile, and add it to the %
> files section.  In Fedora we have a script "rpmdev-newspec" that makes
> it easy to create new boilerplate .spec files for a setup.py file.  The
> downside to this approach is that you now have a .spec file separate
> from your setup.py, and have to maintain both.  It makes sense in our
> world where Python is only one of many technologies, and rpm is the
> native packaging format (for good or ill).
> 
> Hope this is helpful
> Dave
> 
Thank you much, yes it is helpful i managed to write copy_file and write_file, 
which i also need to create files necessery for consolehelper. Thank you again.
I have not tried second solution you provided.
But, there is always but. For some reason write_file put chars in seperate 
lines and i have no idea how to make him create file as i want to. Which is ok 
for now as files are included in data_files argument of setup().
Second but is a major one.
I admit i am newbie and please forgive my incompetence. I put copy_file and 
write_file instructions into setup.py but not into setup(). I guess that is my 
problem. At this point when i run python setup.py install it creates necessery 
link but bdist_rpm does not include it. As far as i can understand its because 
copy_file and write_file are not arguments of setup(). 
How should i include them in setup.py?
I appreciate all your help.


-- 
Micha? Klich

klich.michal at gmail.com
michal at michalklich.com
http://www.michalklich.com

From michal at michalklich.com  Sun Sep 20 13:59:18 2009
From: michal at michalklich.com (=?utf-8?q?Micha=C5=82_Klich?=)
Date: Sun, 20 Sep 2009 13:59:18 +0200
Subject: [Distutils]
 =?utf-8?q?Fwd=3A_Re=3A_distutils_bdist=5Frpm_and_=25p?=
 =?utf-8?q?ostun_section=09of_spec_file?=
In-Reply-To: <200909201130.15395.a.cavallo@cavallinux.eu>
References: <200909182155.27544.klich.michal@gmail.com>
	<1253310188.3186.53.camel@radiator.bos.redhat.com>
	<200909201130.15395.a.cavallo@cavallinux.eu>
Message-ID: <200909201359.18266.klich.michal@gmail.com>

Dnia niedziela 20 wrze?nia 2009 o 12:30:15 A. Cavallo napisa?(a):
> > > Symlink is pointing to x86_64 arch file, i would like to have noarch
> > > rpm. It is pointing to /usr/bin/consolehelper as application needs to
> > > be run with root rights.
> > > I might be doing something wrong here but this is my first package.
> >
> > Although the target (/usr/bin/consolehelper) of the symlink is a
> > compiled binary and thus architecture-specific, the symlink's path and
> > thus the symlink itself is architecture-independent, so it ought to be
> > possible to create a noarch rpm.
> 
> Is it this relevant? In a typical system there're quite few packages: why
> bother to this level of detail?

For sake of space and having two packages i prefer to have it noarch.


> 
> > However, reading the consolehelper manpage, it looks like you may also
> > need to set up files under /etc/pam.d/ (not my area of expertise)
> >
> > (ii) You can write a generic setup.py script, and also write a .spec
> > file.  You then create the symlink in the specfile, and add it to the %
> > files section.  In Fedora we have a script "rpmdev-newspec" that makes
> 
> Cool I wish know this before: is available to the public?

Pakcege is called rpmdevtools, but this is in Fedora it may be different in 
other distro.

> 
> > it easy to create new boilerplate .spec files for a setup.py file.
> 
> Agree, it looks the old way of bdist_rpm hasn't quite catched up with rpm
> packaging recently.
> 
> > The
> > downside to this approach is that you now have a .spec file separate
> > from your setup.py, and have to maintain both.  It makes sense in our
> > world where Python is only one of many technologies, and rpm is the
> > native packaging format (for good or ill).
> 
> It is not a big burden: I can easily manages several packages at once on my
> python distro (http://pyvm.sourceforge.net).
> 
> If I can recommend I'd go for the SuSE build service: this will make easier
>  to experiment the "hands off" build a real rpm.
Looks promising, i will try that.
Thanks

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

-- 
Micha? Klich

klich.michal at gmail.com
michal at michalklich.com
http://www.michalklich.com

From regebro at gmail.com  Sun Sep 20 14:19:06 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 20 Sep 2009 14:19:06 +0200
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <1099b90b0909200508j790092fbt6cb36572c4e63750@mail.gmail.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
	<bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
	<319e029f0909200156n30d5ba7em532a8e21d78e459@mail.gmail.com>
	<1099b90b0909200508j790092fbt6cb36572c4e63750@mail.gmail.com>
Message-ID: <319e029f0909200519p4f210232gb5d6298c29bb4301@mail.gmail.com>

2009/9/20 Jim Fulton <jim at zope.com>:
> That's BS. ?This discussion is is happening because Django is using
> buildout, which I think qualifies as "non-Django stuff".

OK, maybe that was not the right wording.

> Even if this argument had a shred of reason, it is totally
> inappropriate to use a response to a technical query as a platform for
> advocacy, especially negative advocacy.
>
> Finally, I am ashamed when I see members of the Zope community
> bad-mouth other frameworks.

I don't think I did. Pointing out a well known problem is not
bad-mouthing. Unless you consider calling Django "the new Zope" bad
mouthing. I don't. :)

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

From jim at zope.com  Sun Sep 20 14:08:59 2009
From: jim at zope.com (Jim Fulton)
Date: Sun, 20 Sep 2009 08:08:59 -0400
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <319e029f0909200156n30d5ba7em532a8e21d78e459@mail.gmail.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
	<bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
	<319e029f0909200156n30d5ba7em532a8e21d78e459@mail.gmail.com>
Message-ID: <1099b90b0909200508j790092fbt6cb36572c4e63750@mail.gmail.com>

On Sun, Sep 20, 2009 at 4:56 AM, Lennart Regebro <regebro at gmail.com> wrote:
> 2009/9/20 Kyle MacFarlane <kylemacfarlane at gmail.com>:
>> I was hoping more if anybody knew a recipe to get round my problem but
>> I had a look inside Django to see how it looks through packages.
>>
>> The problem is caused by line 58 at this link raising an ImportError:
>> http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py
>
> Yeah, sorry. You can either use Django, or not use namespaces, or fix Django. :)
> Django simply doesn't support namespaces in this case. Yet another
> case of Django being the new Zope, although Zope has fixed that
> problem since a couple of years, and Zope Products can be namespace
> packages nowadays (and the special Products directory is now a
> namespace).
>
> This all is a part Djangos biggest problem: It doesn't play well with
> non-Django stuff. They are however aware of this problem, and I'm sure
> they would appreciate help with fixing this particular issue. In open
> source it's all a matter of available programmer time. :)

That's BS.  This discussion is is happening because Django is using
buildout, which I think qualifies as "non-Django stuff".  Now, when
someone is asking about a technical problem using a non-Django tool,
they get grief that they're problem is that they don't use non-Django
tools.

Even if this argument had a shred of reason, it is totally
inappropriate to use a response to a technical query as a platform for
advocacy, especially negative advocacy.

Finally, I am ashamed when I see members of the Zope community
bad-mouth other frameworks,

Jim

-- 
Jim Fulton

From ziade.tarek at gmail.com  Sun Sep 20 15:03:30 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 20 Sep 2009 15:03:30 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help needed!
Message-ID: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>

Hello,

The next Distribute version will be released soon, with python 3
support (thanks to Martin, Lennart, and Alex !)
and more bug fixed. (you can follow that in the issue tracker)

If you want to give a hand on testing the next Distribute version,
I've uploaded a dev version of the trunk of Distribute at
nightly.ziade.org, meaning that you can try the upcoming release
(at your own risks ;) )

- the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
- a modified distribute_setup.py script that will install the dev
version : http://nightly.ziade.org/distribute_setup_dev.py
- a modified bootstrap.py file that will let you bootstrap a
zc.buildout environment with this version

Any feedback would be greatly appreciated,

Regards,
Tarek

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

From ziade.tarek at gmail.com  Sun Sep 20 16:06:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 20 Sep 2009 16:06:59 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <94bdd2610909200706v7f41c545h70787f981d97ec53@mail.gmail.com>

On Sun, Sep 20, 2009 at 3:03 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>

link: http://nightly.ziade.org/bootstrap.py

From kylemacfarlane at gmail.com  Sun Sep 20 16:45:36 2009
From: kylemacfarlane at gmail.com (Kyle MacFarlane)
Date: Sun, 20 Sep 2009 15:45:36 +0100
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
	<bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
Message-ID: <bf63202c0909200745y772f1417td7ebbfc7c578d3a9@mail.gmail.com>

2009/9/20 Kyle MacFarlane <kylemacfarlane at gmail.com>

> 2009/9/19 P.J. Eby <pje at telecommunity.com>
> > If they use the package's __path__ attribute, they'll find its contents,
> whether someone is using pkgutil.extend_path, .pth files, or setuptools.
>  They don't have to support setuptools to support namespace packages, just
> pay attention to the __path__ variable that's part of standard Python.
>
> I was hoping more if anybody knew a recipe to get round my problem but
> I had a look inside Django to see how it looks through packages.
>
> The problem is caused by line 58 at this link raising an ImportError:
>
> http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py
>
> It doesn't matter what order find_module is called on various paths,
> it still relies entirely on the order in sys.path. Calling find_module
> on second_app before first_app will still fail if first_app is the
> first app on sys.path (which suggests that something has been done
> wrong even before line 58 or find_module itself doesn't support
> namespaces?).
>
> Unfortunately I've never dealt with the imp module before. What would
> I need to do? Import the package (which is actually "path" in this
> code), get __path__ from it and then do find_module again but with
> __path__ instead?
>

I've almost got to the bottom of this by using collective.recipe.omelette
and by putting the following in buildout.cfg:

[easy_install]
zip_ok = 0

But I have one (I hope) remaining problem. When buildout is run the first
thing it does is install zc.buildout and setuptools and totally ignores any
custom settings when doing so. How can I have setuptools install without
being zipped? I've tried "unzip = true" in buildout.cfg but that is ignored
too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090920/0d718530/attachment.htm>

From pje at telecommunity.com  Sun Sep 20 17:00:44 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 20 Sep 2009 11:00:44 -0400
Subject: [Distutils] Buildout + namespace packages + Django management
 commands?
In-Reply-To: <bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com
 >
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
	<bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
Message-ID: <20090920150041.63E7E3A403D@sparrow.telecommunity.com>

At 09:17 AM 9/20/2009 +0100, Kyle MacFarlane wrote:
>2009/9/19 P.J. Eby <pje at telecommunity.com>
> > If they use the package's __path__ attribute, they'll find its 
> contents, whether someone is using pkgutil.extend_path, .pth files, 
> or setuptools. ? They don't have to support setuptools to support 
> namespace packages, just pay attention to the __path__ variable 
> that's part of standard Python.
>
>I was hoping more if anybody knew a recipe to get round my problem but
>I had a look inside Django to see how it looks through packages.
>
>The problem is caused by line 58 at this link raising an ImportError:
>http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py
>
>It doesn't matter what order find_module is called on various paths,
>it still relies entirely on the order in sys.path. Calling find_module
>on second_app before first_app will still fail if first_app is the
>first app on sys.path (which suggests that something has been done
>wrong even before line 58 or find_module itself doesn't support
>namespaces?).
>
>Unfortunately I've never dealt with the imp module before. What would
>I need to do? Import the package (which is actually "path" in this
>code), get __path__ from it and then do find_module again but with
>__path__ instead?

Basically, yeah, only it has to happen inside the "while parts" 
loop.  The downside, of course, is that you'll be importing every 
application and its management package.  It's too bad, really, they 
could've saved a ton of code and complexity there (as well as being 
able to support namespace packages, zipfiles, etc.) if they'd just 
used pkg_resources and entry points.  Projects could just declare 
their commands without needing a management.commands subpackage, or 
separate modules for each command.


From strawman at astraw.com  Sun Sep 20 19:02:24 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 10:02:24 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB659C6.4070203@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
Message-ID: <4AB66020.10408@astraw.com>

Gerry Reno wrote:
> In my setup.py I have my own "install":
>
> from distutils.command.install import install
> ...
> class myinstall(install):
> ...
>
> and when we call dpkg-buildpackage this local "install" seems to maybe
> be causing the problem with the error: option
> --single-version-externally-managed not recognized.
>
> How can we make this option be recognized? Do we need to inherit
> something from setuptools?
I think there are 2 options:

1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the
--single-version-externally-managed argument.

2) inherit from setuptools' install command.

I would suggest option 1. If you need me to make a release, I'm happy to
do so -- but maybe that will be better after it has bdist_deb? :)

-Andrew

From greno at verizon.net  Sun Sep 20 19:20:33 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 13:20:33 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB66020.10408@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com>
Message-ID: <4AB66461.1020007@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> In my setup.py I have my own "install":
>>
>> from distutils.command.install import install
>> ...
>> class myinstall(install):
>> ...
>>
>> and when we call dpkg-buildpackage this local "install" seems to maybe
>> be causing the problem with the error: option
>> --single-version-externally-managed not recognized.
>>
>> How can we make this option be recognized? Do we need to inherit
>> something from setuptools?
>>     
> I think there are 2 options:
>
> 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the
> --single-version-externally-managed argument.
>   
I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in 
stdeb 0.3.  I always use the distro packagers to install software so how 
can I use apt-get to install stdeb 0.4?


> 2) inherit from setuptools' install command.
>   
I don't like that idea.  That may mean a lot of rework as it took a 
while to get our "install" all debugged and working.

> I would suggest option 1. If you need me to make a release, I'm happy to
> do so -- but maybe that will be better after it has bdist_deb? :)
>   
My only concern now with stdeb adding the bdist_deb command is that it 
may not work like other 'bdist' commands.  And having 'bdist_deb' work 
similar to 'bdist_rpm' is important.  It would have to use setup.cfg for 
config and allow for pre/postinstall scripts to run.


Regards,
Gerry


From greno at verizon.net  Sun Sep 20 18:35:18 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 12:35:18 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB5B927.2050905@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net>
Message-ID: <4AB659C6.4070203@verizon.net>

In my setup.py I have my own "install":

from distutils.command.install import install
...
class myinstall(install):
...

and when we call dpkg-buildpackage this local "install" seems to maybe 
be causing the problem with the error: option 
--single-version-externally-managed not recognized.

How can we make this option be recognized? Do we need to inherit 
something from setuptools?

Regards,
Gerry



Gerry Reno wrote:
> Ok, I found how to control the python version: XS-Python-Version
>
> So now it is using python2.5 but dpkg-buildpackage hits an error:
> error: option --single-version-externally-managed not recognized
>
> What is this option?
> I've been searching but I don't find how to solve this.
> Is there a way to fix this?
>
> Regards,
> Gerry
>
>
> Gerry Reno wrote:
>> Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb' 
>> command.
>> The entire thing is working except for the last subcommand for 
>> dpkg-buildpackage is trying to build for python2.4 and failing.
>>
>> dpkg-buildpackage fails in the fakeroot...
>> ...
>> debian/rules build
>> python2.4 -c "import 
>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
>> build
>> Traceback (most recent call last):
>> File "<string>", line 1, in ?
>> File "setup.py", line 35, in ?
>> import stdeb
>> ImportError: No module named stdeb
>> make: *** [build-python2.4] Error 1
>> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
>>
>> Is this something to do with python versions?
>> So how do I limit the python versions for dpkg-buildpackage?
>>
>> stdeb is 0.3
>> $ python -V
>> Python 2.5.2
>>
>>
>> Regards,
>> Gerry
>>

From strawman at astraw.com  Sun Sep 20 20:16:09 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 11:16:09 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB66461.1020007@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
Message-ID: <4AB67169.9080006@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> In my setup.py I have my own "install":
>>>
>>> from distutils.command.install import install
>>> ...
>>> class myinstall(install):
>>> ...
>>>
>>> and when we call dpkg-buildpackage this local "install" seems to maybe
>>> be causing the problem with the error: option
>>> --single-version-externally-managed not recognized.
>>>
>>> How can we make this option be recognized? Do we need to inherit
>>> something from setuptools?
>>>     
>> I think there are 2 options:
>>
>> 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the
>> --single-version-externally-managed argument.
>>   
> I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in
> stdeb 0.3.  I always use the distro packagers to install software so
> how can I use apt-get to install stdeb 0.4?

stdeb isn't in the Ubuntu (or Debian) repository. And I thought you said
you used easy_install on it. Are you sure you can't just upgrade by
hand? I can't see how else you got it.

>
>> I would suggest option 1. If you need me to make a release, I'm happy to
>> do so -- but maybe that will be better after it has bdist_deb? :)
>>   
> My only concern now with stdeb adding the bdist_deb command is that it
> may not work like other 'bdist' commands.  And having 'bdist_deb' work
> similar to 'bdist_rpm' is important.  It would have to use setup.cfg
> for config and allow for pre/postinstall scripts to run.

Well, to produce the final .deb file, stdeb produces a source package
and then, in another process, calls the debian machinery may be called
to produce the .deb file (I guess you're now quite familiar with that).
I feel this approach benefits from using the standard Debian
infrastructure. Specifically, python-support and debhelper 7 called by
stdeb 0.4 do things like: install a single copy of the .py files and
symlink them into the per-version directories, compile .pyc files
per-version at install time, compile extension modules per-version at
build time, and so on. Reproducing that would be hard, error prone, and
a pointless duplication of effort. And .debs that don't do all that
stuff that will be sub-standard and won't behave like those downloaded
from the Debian/Ubuntu repos. Thus, I really think calling the real
Debian machinery is the way to go.

As I understand it (which is not well), bdist_rpm calls out to an "rpm"
command from the original "python setup.py bdist_rpm" process, but at
that point the binary is already made at this is just a packaging step.

With stdeb, the initial output will be the source package which would be
compiled to a binary by another process -- a subprocess of
dpkg-buildpackage. You can control this binary generation by modifying
debian/rules, which is a Makefile that is run to build the binary. So
you can make sure that building the binary as done by the debian/rules
file handles the options in setup.cfg. It should do that automatically,
since what happens is a glorified "python setup.py install".

As far as pre/postinstall scripts -- what do you need them to do? It
would be possible to add support for stdeb to run these scripts at
debian .deb install time. (stdeb already runs a preinstall script to
ease the python-central -> python-support transition. See commit
9faaf049.) But if they're limited in scope and merely modify the files
you want installed, they're probably already run as part of the .deb
build process if you've hooked into the "install" command.

I can't see how an infrastructure based only on extending the distutils
install command could be used to distinguish between A)
"pre/post-install" scripts that merely modify the files to be installed
and could thus be run at package build time versus B) pre/post-install
scripts that actually need to be run once the .deb package is being
installed on the target system that might do something like start a web
server. It seems there has to be a specification of the difference.

-Andrew

From attilaolah at gmail.com  Sun Sep 20 20:38:57 2009
From: attilaolah at gmail.com (=?UTF-8?B?QXR0aWxhIE9sw6Fo?=)
Date: Sun, 20 Sep 2009 20:38:57 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
Message-ID: <1da06520909201138j3450e699g2180629e63bba134@mail.gmail.com>

Hi Tarek,

When do you plan to make a 'final' release of this version (0.6.2)?

Attila

From greno at verizon.net  Sun Sep 20 20:47:57 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 14:47:57 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB67169.9080006@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com>
Message-ID: <4AB678DD.4060807@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> Gerry Reno wrote:
>>>  
>>>       
>>>> In my setup.py I have my own "install":
>>>>
>>>> from distutils.command.install import install
>>>> ...
>>>> class myinstall(install):
>>>> ...
>>>>
>>>> and when we call dpkg-buildpackage this local "install" seems to maybe
>>>> be causing the problem with the error: option
>>>> --single-version-externally-managed not recognized.
>>>>
>>>> How can we make this option be recognized? Do we need to inherit
>>>> something from setuptools?
>>>>     
>>>>         
>>> I think there are 2 options:
>>>
>>> 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the
>>> --single-version-externally-managed argument.
>>>   
>>>       
>> I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in
>> stdeb 0.3.  I always use the distro packagers to install software so
>> how can I use apt-get to install stdeb 0.4?
>>     
>
> stdeb isn't in the Ubuntu (or Debian) repository. And I thought you said
> you used easy_install on it. Are you sure you can't just upgrade by
> hand? I can't see how else you got it.
>   
Yes, looking back you are right.  I didn't find it with apt-get and had 
to use easy_install to get it (which I don't normally do).
$ sudo easy_install --upgrade stdeb
says stdeb 0.3 is best match and already installed.  How do I get stdeb 0.4?


>   
>>> I would suggest option 1. If you need me to make a release, I'm happy to
>>> do so -- but maybe that will be better after it has bdist_deb? :)
>>>   
>>>       
>> My only concern now with stdeb adding the bdist_deb command is that it
>> may not work like other 'bdist' commands.  And having 'bdist_deb' work
>> similar to 'bdist_rpm' is important.  It would have to use setup.cfg
>> for config and allow for pre/postinstall scripts to run.
>>     
>
> Well, to produce the final .deb file, stdeb produces a source package
> and then, in another process, calls the debian machinery may be called
> to produce the .deb file (I guess you're now quite familiar with that).
> I feel this approach benefits from using the standard Debian
> infrastructure. Specifically, python-support and debhelper 7 called by
> stdeb 0.4 do things like: install a single copy of the .py files and
> symlink them into the per-version directories, compile .pyc files
> per-version at install time, compile extension modules per-version at
> build time, and so on. Reproducing that would be hard, error prone, and
> a pointless duplication of effort. And .debs that don't do all that
> stuff that will be sub-standard and won't behave like those downloaded
> from the Debian/Ubuntu repos. Thus, I really think calling the real
> Debian machinery is the way to go.
>
> As I understand it (which is not well), bdist_rpm calls out to an "rpm"
> command from the original "python setup.py bdist_rpm" process, but at
> that point the binary is already made at this is just a packaging step.
>
> With stdeb, the initial output will be the source package which would be
> compiled to a binary by another process -- a subprocess of
> dpkg-buildpackage. You can control this binary generation by modifying
> debian/rules, which is a Makefile that is run to build the binary. So
> you can make sure that building the binary as done by the debian/rules
> file handles the options in setup.cfg. It should do that automatically,
> since what happens is a glorified "python setup.py install".
>
> As far as pre/postinstall scripts -- what do you need them to do? It
> would be possible to add support for stdeb to run these scripts at
> debian .deb install time. (stdeb already runs a preinstall script to
> ease the python-central -> python-support transition. See commit
> 9faaf049.) But if they're limited in scope and merely modify the files
> you want installed, they're probably already run as part of the .deb
> build process if you've hooked into the "install" command.
>
> I can't see how an infrastructure based only on extending the distutils
> install command could be used to distinguish between A)
> "pre/post-install" scripts that merely modify the files to be installed
> and could thus be run at package build time versus B) pre/post-install
> scripts that actually need to be run once the .deb package is being
> installed on the target system that might do something like start a web
> server. It seems there has to be a specification of the difference.
>
>   
For bdist_rpm the way that you get pre and postpackage install scripts 
to run during package install is by using
the following in the setup.cfg:
[bdist_rpm]
install_script = rpm_install_sh.txt

then rpm_install_sh.txt gets inserted into the rpm .spec file at the 
%install marker.  Now you can also add other sections into 
rpm_install_sh.txt like %pre and %post which are sections of shell 
scripts that run prepackage and postpackage install.  As far as 'python 
setup.py install' build type pre/postinstall, you can subclass install 
class and just run some scripts either side of parent "install" class.


Regards,
Gerry


From strawman at astraw.com  Sun Sep 20 21:54:44 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 12:54:44 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB678DD.4060807@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
Message-ID: <4AB68884.1090905@astraw.com>

Gerry Reno wrote:
> How do I get stdeb 0.4?

The easiest way:

git clone git://github.com/astraw/stdeb.git
cd stdeb
sudo python setup.py install

If you want a tarball, please look at my email 09/19/2009 09:36 PM -0700.

> For bdist_rpm the way that you get pre and postpackage install scripts
> to run during package install is by using
> the following in the setup.cfg:
> [bdist_rpm]
> install_script = rpm_install_sh.txt
>
> then rpm_install_sh.txt gets inserted into the rpm .spec file at the
> %install marker.  Now you can also add other sections into
> rpm_install_sh.txt like %pre and %post which are sections of shell
> scripts that run prepackage and postpackage install.  As far as
> 'python setup.py install' build type pre/postinstall, you can subclass
> install class and just run some scripts either side of parent
> "install" class.
I think it would be straightforward to integrate something similar into
stdeb.

I'm not too much in favor of piggybacking distutils' infrastructure to
parse the setup.cfg file, though. Perhaps we could parse setup.cfg on
our own (i.e. replace looking for stdeb.cfg with looking for setup.cfg
and changing the section name appropriately). In the near term the
easiest thing is to stick with the stdeb.cfg file for now and and a new
field for each of pre/post install and pre/post remove.

-Andrew

From greno at verizon.net  Sun Sep 20 22:55:19 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 16:55:19 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB68884.1090905@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com>
Message-ID: <4AB696B7.9040705@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> How do I get stdeb 0.4?
>>     
>
> The easiest way:
>
> git clone git://github.com/astraw/stdeb.git
> cd stdeb
> sudo python setup.py install
>
> If you want a tarball, please look at my email 09/19/2009 09:36 PM -0700.
>   

Ok, I'll install 0.4 using one of these methods.  
What should I do about the easy_installed stdeb 0.3?
Should I try to "remove" 0.3 (I use that term loosely wrt 
easy_install)   using -m?


>   
>> For bdist_rpm the way that you get pre and postpackage install scripts
>> to run during package install is by using
>> the following in the setup.cfg:
>> [bdist_rpm]
>> install_script = rpm_install_sh.txt
>>
>> then rpm_install_sh.txt gets inserted into the rpm .spec file at the
>> %install marker.  Now you can also add other sections into
>> rpm_install_sh.txt like %pre and %post which are sections of shell
>> scripts that run prepackage and postpackage install.  As far as
>> 'python setup.py install' build type pre/postinstall, you can subclass
>> install class and just run some scripts either side of parent
>> "install" class.
>>     
> I think it would be straightforward to integrate something similar into
> stdeb.
>
> I'm not too much in favor of piggybacking distutils' infrastructure to
> parse the setup.cfg file, though. Perhaps we could parse setup.cfg on
> our own (i.e. replace looking for stdeb.cfg with looking for setup.cfg
> and changing the section name appropriately). In the near term the
> easiest thing is to stick with the stdeb.cfg file for now and and a new
> field for each of pre/post install and pre/post remove.
>
>   
My preference would be to see something like this maybe in setup.cfg:
[bdist_deb]
pre_install_script = deb_pre_install.sh
post_install_script = deb_post_install.sh
pre_uninstall_script = deb_pre_uninstall.sh
post_uninstall_script = deb_post_uninstall.sh

This is what I was intending to do using the 'bdist_deb' command 
extension to distutils.

And that way our users have only one config file they need to be 
concerned about.


Regards,
Gerry

P.S.:  Things that totally frustrate me wrt python:  
distutils/setuptools and apt-get(or rpm)/easy_install 
battles/incompatibilities/duplications.

From greno at verizon.net  Mon Sep 21 00:35:02 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 18:35:02 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB696B7.9040705@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
Message-ID: <4AB6AE16.9030505@verizon.net>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>> How do I get stdeb 0.4?
>>
>> The easiest way:
>>
>> git clone git://github.com/astraw/stdeb.git
>> cd stdeb
>> sudo python setup.py install
>>
>> If you want a tarball, please look at my email 09/19/2009 09:36 PM 
>> -0700.
>
> Ok, I'll install 0.4 using one of these methods. What should I do 
> about the easy_installed stdeb 0.3?
> Should I try to "remove" 0.3 (I use that term loosely wrt 
> easy_install) using -m?
>
Ok, I d/l the tarball which installed 0.3-dh7. But this created new 
problems:
Unmet dependencies: debhelper >= 7 python-support >= 0.8.7
Installed: debhelper6.0.4 python-support0.7.5

It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS.

Regards,
Gerry


So I ran apt-get upgrade

From strawman at astraw.com  Mon Sep 21 00:55:08 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 15:55:08 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB6AE16.9030505@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net>
Message-ID: <4AB6B2CC.1090400@astraw.com>

Gerry Reno wrote:
>
> It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS.
Well, I'd qualify that with stdeb version 0.4 may be more tough to get
running. It is the bleeding edge, after all. :) 0.3 works as well as it
ever did, but new features are going into 0.4.

But now that you mention it, I have backported debhelper and
python-support to Hardy. See http://debs.astraw.com/hardy you can
download the binaries or source packages from there. (You can also add
my repo to your /etc/apt/sources.list)

-Andrew

From greno at verizon.net  Mon Sep 21 01:08:49 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 19:08:49 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB6B2CC.1090400@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
Message-ID: <4AB6B601.8050404@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS.
>>     
> Well, I'd qualify that with stdeb version 0.4 may be more tough to get
> running. It is the bleeding edge, after all. :) 0.3 works as well as it
> ever did, but new features are going into 0.4.
>
> But now that you mention it, I have backported debhelper and
> python-support to Hardy. See http://debs.astraw.com/hardy you can
> download the binaries or source packages from there. (You can also add
> my repo to your /etc/apt/sources.list)
>   
Wow, there's quite a few packages there.  Is debhelper and 
python-support all that are needed or do I need any others because of 
dependencies?

Regards,
Gerry


From strawman at astraw.com  Mon Sep 21 02:15:27 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 17:15:27 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB6B601.8050404@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net>
Message-ID: <4AB6C59F.209@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS.
>>>     
>> Well, I'd qualify that with stdeb version 0.4 may be more tough to get
>> running. It is the bleeding edge, after all. :) 0.3 works as well as it
>> ever did, but new features are going into 0.4.
>>
>> But now that you mention it, I have backported debhelper and
>> python-support to Hardy. See http://debs.astraw.com/hardy you can
>> download the binaries or source packages from there. (You can also add
>> my repo to your /etc/apt/sources.list)
>>   
> Wow, there's quite a few packages there.  Is debhelper and
> python-support all that are needed or do I need any others because of
> dependencies?
I can't remember -- you'll have to attempt installation to find out. I
think there are some but not too many dependencies that need to be
upgraded (I guess on the order of 5 packages or so).

-Andrew

From greno at verizon.net  Mon Sep 21 03:20:38 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 20 Sep 2009 21:20:38 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB6C59F.209@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
Message-ID: <4AB6D4E6.5030402@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> Gerry Reno wrote:
>>>  
>>>       
>>>> It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS.
>>>>     
>>>>         
>>> Well, I'd qualify that with stdeb version 0.4 may be more tough to get
>>> running. It is the bleeding edge, after all. :) 0.3 works as well as it
>>> ever did, but new features are going into 0.4.
>>>
>>> But now that you mention it, I have backported debhelper and
>>> python-support to Hardy. See http://debs.astraw.com/hardy you can
>>> download the binaries or source packages from there. (You can also add
>>> my repo to your /etc/apt/sources.list)
>>>   
>>>       
>> Wow, there's quite a few packages there.  Is debhelper and
>> python-support all that are needed or do I need any others because of
>> dependencies?
>>     
> I can't remember -- you'll have to attempt installation to find out. I
> think there are some but not too many dependencies that need to be
> upgraded (I guess on the order of 5 packages or so).
>
>
>   
Ok, here is the simplest way that I got stdeb working on Hardy:
$ easy_install stdeb  # installs 0.3
copied stdeb egg to workarea and edited util.py and removed all 
"--single-version-externally-managed" options
repackaged egg
copied egg back to site-packages

Now dpkg-buildpackage is happy and no more complaints about unrecognized 
option or missing dependencies.

So my question is this: can you make a special version of the current 
stdeb 0.3 without the --single-version-externally-managed options and 
put it into your hardy repo?
This would be much easier and less worrisome to hardy users than trying 
to get them to upgrade a lot of different packages.

Regards,
Gerry



From david.lyon at preisshare.net  Mon Sep 21 03:43:44 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sun, 20 Sep 2009 21:43:44 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AB35E44.9070707@simplistix.co.uk>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<20090911163232.GB2903@laurie.devork>	<94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
	<20090912145036.GB13831@laurie.devork>
	<4AB35E44.9070707@simplistix.co.uk>
Message-ID: <7b63c276c622d3fe6f7512bdb324825c@preisshare.net>

On Fri, 18 Sep 2009 11:17:40 +0100, Chris Withers <chris at simplistix.co.uk>
wrote:
> A lot of these problems would go away if we could just treat "Python" as 
> a package like every other package when it comes to dependencies.
> 
> Why is that so hard to do?

It's not hard at all.

But somebody needs to show how easy it is to do first, and then
once that happens, it can be 'forked'. Perphaps implemented
differently (white-boxed) from the original. So that somebody 
else can put their name on the idea.

Forking in distutils is perphaps the new way of having 
innovation and progress.

Don't worry Chris, if your idea is good enough, it is going
to get forked...

David


From david.lyon at preisshare.net  Mon Sep 21 04:26:14 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sun, 20 Sep 2009 22:26:14 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090917033411.8C25D3A4079@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
Message-ID: <f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>

On Wed, 16 Sep 2009 23:34:07 -0400, "P.J. Eby" <pje at telecommunity.com>
wrote:
>>An application needs to know what directory it has been installed
>>in and where it can find configuration files and so forth.
> 
> It appears I was unclear: it is not the application's business to 
> *decide* what the installation directory is.

I never said it was...

>> > nor is it something that should be specified in setup.py or
>> > setup.cfg, as that is 100% the user's business to choose, and the
>> > platform tools to supply a default for.
>>
>>Well, it certainly doesn't work that way at the moment.
> 
> Eh?  It's *possible* to specify it in those places now, but 
> well-behaved packages never do.

Not on windows, outside of the c:\pythonXY directory. 

Define well behaved..

If you are saying that Python observes all microsofts
recommendations under windows and is "well-behaved" I think
I'd have some comments about that.

"Well behaved" is installing a python program to "Program Files"
but distutils doesn't allow this to my knowledge.
 
> If platform/pyver-specific dependencies are all that's required, 
> there's a way to specify them using setuptools' existing dependency 
> syntax, using "extras".   

But you have told everybody that setuptools is dead... and
you don't have any plans to work on it any more..

> In other words, there's already a framework for actually 
> *implementing* conditional dependencies, it just needs to have a 
> convention for naming of "extras" to allow it to work.  And in the 
> absence of tool support, it could even be implemented manually, by 
> adding the necessary extra names on the command line of existing 
> installation tools.

Sure. That's what's being discussed.

David

From strawman at astraw.com  Mon Sep 21 04:49:04 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 19:49:04 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB6D4E6.5030402@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net>
Message-ID: <4AB6E9A0.80708@astraw.com>

Gerry Reno wrote:
> Ok, here is the simplest way that I got stdeb working on Hardy:
> $ easy_install stdeb  # installs 0.3
> copied stdeb egg to workarea and edited util.py and removed all
> "--single-version-externally-managed" options
> repackaged egg
> copied egg back to site-packages
OK, but now your packages built with stdeb going to be (even more)
different from standard Debian/Ubuntu Python packages -- they're going
to install their files as an .egg (directory or zip file). For example,
do "dpkg --contents python-my-package_1.0-1.deb" and compare that to
standard python packages.

> Now dpkg-buildpackage is happy and no more complaints about
> unrecognized option or missing dependencies.
>
> So my question is this: can you make a special version of the current
> stdeb 0.3 without the --single-version-externally-managed options and
> put it into your hardy repo?
No -- I already have debhelper 7 and friends in my hardy repo. If I put
stdeb in at all, it would be 0.4. I won't go back to stdeb 0.3,
especially a broken version of 0.3.

> This would be much easier and less worrisome to hardy users than
> trying to get them to upgrade a lot of different packages.
I don't have enough time to work on stdeb as-is, and my development
efforts going forward will continue to use debhelper 7 and
python-support, not to work on backporting stuff. I can say my packages
are installed on lots of hardy machines (over 20 at last count) and
haven't caused troubles that I know of. I'm careful to put the source
online, too, in case you want to look at my changes or compile yourself.

If you want to work off the "old-stable" branch in my github account,
that's where the 0.3 branch still lives.

Anyhow, if you come up with a bdist_deb type patch, I'd be interested to
take a look and could probably merge it from the old-stable branch onto
the master branch.

-Andrew

From pje at telecommunity.com  Mon Sep 21 05:58:06 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 20 Sep 2009 23:58:06 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
	<f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
Message-ID: <20090921035804.A731B3A403D@sparrow.telecommunity.com>

At 10:26 PM 9/20/2009 -0400, David Lyon wrote:
> > Eh?  It's *possible* to specify it in those places now, but
> > well-behaved packages never do.
>
>Not on windows, outside of the c:\pythonXY directory.

Create a setup.cfg with an [install] section and you can make it 
install wherever you tell it to...  when installing using 
setup.py.  (bdist_wininst and bdist_msi are something else altogether.)


>Define well behaved..
>
>If you are saying that Python observes all microsofts
>recommendations under windows and is "well-behaved" I think
>I'd have some comments about that.
>
>"Well behaved" is installing a python program to "Program Files"
>but distutils doesn't allow this to my knowledge.

It most certainly does; but not in a bdist_wininst or bdist_msi 
(AFAIK), and definitely not by default.  You'd need to specify the 
location on the command line.



> > If platform/pyver-specific dependencies are all that's required,
> > there's a way to specify them using setuptools' existing dependency
> > syntax, using "extras".
>
>But you have told everybody that setuptools is dead... and
>you don't have any plans to work on it any more..

You are misrepresenting my statements.  I have neither called it dead 
nor have I said I don't have plans to work on it any more.  (In fact, 
I've said the opposite, noting that the existence of Distribute makes 
the possibility of doing some advanced work on setuptools *more* 
likely, because I needn't worry so much about the maintenance backlog.)


From david.lyon at preisshare.net  Mon Sep 21 07:11:16 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 21 Sep 2009 01:11:16 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <20090921035804.A731B3A403D@sparrow.telecommunity.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
	<f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
	<20090921035804.A731B3A403D@sparrow.telecommunity.com>
Message-ID: <62ef464f511ca6e2a682c5e33a51018d@preisshare.net>

On Sun, 20 Sep 2009 23:58:06 -0400, "P.J. Eby" <pje at telecommunity.com>
wrote:
>>If you are saying that Python observes all microsofts
>>recommendations under windows and is "well-behaved" I think
>>I'd have some comments about that.
>>
>>"Well behaved" is installing a python program to "Program Files"
>>but distutils doesn't allow this to my knowledge.
> 
> It most certainly does; but not in a bdist_wininst or bdist_msi 
> (AFAIK), and definitely not by default.  You'd need to specify the 
> location on the command line.

I don't know if you have checked lately but not many windows users
these days even know what a command line even is.

It's just plain unreasonable to expect windows users to resort to a 
command line in this day and age.

> You are misrepresenting my statements.  I have neither called it dead 
> nor ..

Ok. Fine.

But expecting windows users to remember commandlines *is* dead.

And everything you wrote has confirmed that python package installation
under windows *is* "not well behaved". Be it command-line installation,
or bdist_wininst/bdist_msi not working properly.

Anyway, windows is just an 'edge-use-case'. So lets not worry.

David







From strawman at astraw.com  Mon Sep 21 07:50:21 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 20 Sep 2009 22:50:21 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB70C58.5010206@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net>
Message-ID: <4AB7141D.9040702@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> Ok, here is the simplest way that I got stdeb working on Hardy:
>>> $ easy_install stdeb  # installs 0.3
>>> copied stdeb egg to workarea and edited util.py and removed all
>>> "--single-version-externally-managed" options
>>> repackaged egg
>>> copied egg back to site-packages
>>>     
>> OK, but now your packages built with stdeb going to be (even more)
>> different from standard Debian/Ubuntu Python packages -- they're going
>> to install their files as an .egg (directory or zip file). For example,
>> do "dpkg --contents python-my-package_1.0-1.deb" and compare that to
>> standard python packages.
>>   
> Ok, I just built a .deb using modified stdeb 0.3 on hardy and looked
> at the contents and it's like this:
> ./usr/share/pyshared/myapp/dir1/...(list of files)
> ./usr/share/pyshared/myapp/dir2/...
> ./usr/share/pyshared/myapp/dir3/...
>
> I don't see anything about egg.  And it looks very similar to other
> .deb in /var/cache that I checked.

That's good. And surprising to me...

> How much difference would I see if it was egg?
Hmm, good question. Now that you find this, I'm really not sure.

Scratches head and wonders if he's been basing his ideas off old
versions of software,
-Andrew

From greno at verizon.net  Mon Sep 21 07:17:12 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 21 Sep 2009 01:17:12 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB6E9A0.80708@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
Message-ID: <4AB70C58.5010206@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Ok, here is the simplest way that I got stdeb working on Hardy:
>> $ easy_install stdeb  # installs 0.3
>> copied stdeb egg to workarea and edited util.py and removed all
>> "--single-version-externally-managed" options
>> repackaged egg
>> copied egg back to site-packages
>>     
> OK, but now your packages built with stdeb going to be (even more)
> different from standard Debian/Ubuntu Python packages -- they're going
> to install their files as an .egg (directory or zip file). For example,
> do "dpkg --contents python-my-package_1.0-1.deb" and compare that to
> standard python packages.
>   
Ok, I just built a .deb using modified stdeb 0.3 on hardy and looked at 
the contents and it's like this:
./usr/share/pyshared/myapp/dir1/...(list of files)
./usr/share/pyshared/myapp/dir2/...
./usr/share/pyshared/myapp/dir3/...

I don't see anything about egg.  And it looks very similar to other .deb 
in /var/cache that I checked.
How much difference would I see if it was egg?

Regards,
Gerry


From ben+python at benfinney.id.au  Mon Sep 21 08:52:22 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 21 Sep 2009 16:52:22 +1000
Subject: [Distutils] setup.cfg new format proposal
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
	<f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
	<20090921035804.A731B3A403D@sparrow.telecommunity.com>
	<62ef464f511ca6e2a682c5e33a51018d@preisshare.net>
Message-ID: <87d45kvlg9.fsf@benfinney.id.au>

David Lyon <david.lyon at preisshare.net> writes:

> I don't know if you have checked lately but not many windows users
> these days even know what a command line even is.
>
> It's just plain unreasonable to expect windows users to resort to a
> command line in this day and age.

No, I think the attitude of these statements is unreasonable. I also
find it staggeringly condescending. Windows users are no less capable of
learning how to use the systems they're interested in, nor are they less
capable of using cross-platform tools than users of other platforms.

> Anyway, windows is just an 'edge-use-case'. So lets not worry.

You can't have it both ways; earlier in the same message you argued
exactly that Windows *is* somehow special, in that its users are
incapable of operating equivalent tools tha the rest of us use.

I happen to think that's wrong: that, instead, Windows is a major
platform, and its users run the same range of human capability as users
of other platforms.

No need to special-case Windows users; make available tools that operate
in a similar way as the rest of us have. If they want the operating
system to work better with others, they can take the same responsibility
as the rest of us: pressure their OS vendors to fix the problems, or get
involved to work on it themselves. Either way, they don't deserve
special treatment just for being Windows users.

-- 
 \     ?I cannot conceive that anybody will require multiplications at |
  `\   the rate of 40,000 or even 4,000 per hour ?? ?F. H. Wales, 1936 |
_o__)                                                                  |
Ben Finney


From david.lyon at preisshare.net  Mon Sep 21 09:20:22 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 21 Sep 2009 03:20:22 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <87d45kvlg9.fsf@benfinney.id.au>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
	<f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
	<20090921035804.A731B3A403D@sparrow.telecommunity.com>
	<62ef464f511ca6e2a682c5e33a51018d@preisshare.net>
	<87d45kvlg9.fsf@benfinney.id.au>
Message-ID: <1156ecaf38815762a4eb1a67a2620447@preisshare.net>

On Mon, 21 Sep 2009 16:52:22 +1000, Ben Finney <ben+python at benfinney.id.au>
wrote:
>> It's just plain unreasonable to expect windows users to resort to a
>> command line in this day and age.
> 
> No, I think the attitude of these statements is unreasonable. I also
> find it staggeringly condescending. 

What? to say windows users don't like command lines...

It's perfectly true. Not condescending.

> Windows users are no less capable of
> learning how to use the systems they're interested in, nor are they less
> capable of using cross-platform tools than users of other platforms.

That's your opinion..


> You can't have it both ways; earlier in the same message you argued
> exactly that Windows *is* somehow special, in that its users are
> incapable of operating equivalent tools tha the rest of us use.

"Special" is your word not mine. I never said that.

All I said was that use of the command line has disappeared from popular
use in windows. To the point where not many people these days even know of
its existence.

Since the late 1990's, every windows programming language except python has
had a gui package management tool included. I'm talking Visual Basic,
Delphi and the microsoft products.

> I happen to think that's wrong: that, instead, Windows is a major
> platform..

Most of us know that..

> No need to special-case Windows users; make available tools that operate
> in a similar way as the rest of us have. If they want the operating
> system to work better with others, they can take the same responsibility
> as the rest of us: pressure their OS vendors to fix the problems, or get
> involved to work on it themselves. Either way, they don't deserve
> special treatment just for being Windows users.

What "special" treatment are you saying windows users enjoy?

David


From ben+python at benfinney.id.au  Mon Sep 21 10:14:23 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 21 Sep 2009 18:14:23 +1000
Subject: [Distutils] setup.cfg new format proposal
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
	<f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
	<20090921035804.A731B3A403D@sparrow.telecommunity.com>
	<62ef464f511ca6e2a682c5e33a51018d@preisshare.net>
	<87d45kvlg9.fsf@benfinney.id.au>
	<1156ecaf38815762a4eb1a67a2620447@preisshare.net>
Message-ID: <874oqwvhnk.fsf@benfinney.id.au>

David Lyon <david.lyon at preisshare.net> writes:

> On Mon, 21 Sep 2009 16:52:22 +1000, Ben Finney <ben+python at benfinney.id.au>
> wrote:
> >> It's just plain unreasonable to expect windows users to resort to a
> >> command line in this day and age.
> > 
> > No, I think the attitude of these statements is unreasonable. I also
> > find it staggeringly condescending.
>
> What? to say windows users don't like command lines...
>
> It's perfectly true. Not condescending.

I know many users of systems who ?don't like? command lines. You're
going beyond that, though, and saying that it's unreasonable to expect
users of a particular platform to use tools similar to those that users
of other platforms use.

That you expect Windows users to be treated specially is what I find
unreasonable and condescending.

> "Special" is your word not mine. I never said that.

Yet you are using special pleading: you are saying that users of one
platform are to be treated differently in terms of what we can expect
them to learn how to use, simply because they use that specific
platform.

-- 
 \     ?I must say that I find television very educational. The minute |
  `\       somebody turns it on, I go to the library and read a book.? |
_o__)                                                    ?Groucho Marx |
Ben Finney


From ziade.tarek at gmail.com  Mon Sep 21 11:40:58 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 Sep 2009 11:40:58 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <1da06520909201138j3450e699g2180629e63bba134@mail.gmail.com>
References: <1da06520909201138j3450e699g2180629e63bba134@mail.gmail.com>
Message-ID: <94bdd2610909210240k2db02b28yd08f1ca713866de7@mail.gmail.com>

On Sun, Sep 20, 2009 at 8:38 PM, Attila Ol?h <attilaolah at gmail.com> wrote:
> Hi Tarek,
>
> When do you plan to make a 'final' release of this version (0.6.2)?
>
> Attila

Hi Attila,


I am waiting for some feedback on the bootstrap process from various people that
should be done this week, so the target is to release it by the end of the week.

Regards
Tarek

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

From regebro at gmail.com  Mon Sep 21 12:04:27 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 21 Sep 2009 12:04:27 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <20090921071931.GD9685@elzar.ws.whq.gocept.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
Message-ID: <319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>

2009/9/21 Wolfgang Schnerring <ws at gocept.com>:
> Very much agreed, let's use setup() arguments.


Great. I've checked in some docs too, I expanded the section on Python
3 support and ended up creating a new document, python3.txt. Feedback
on that is appreciated.

Also, feedback on the naming of the keywords is appreciated. Yes, I
know it's bikeshedding, but I find the current parameter names clunky,
but have no better ideas.

``run_2to3``
    Convert the source code from Python 2 to Python 3 with 2to3 during the
    build process.

``convert_doctests_2to3``
    List of doctest source files that need to be converted with 2to3.
    See :doc:`python3` for more details.

``additional_2to3_fixers``
    A list of modules to serach for additional fixers to be used during
    the 2to3 conversion. See :doc:`python3` for more details.

If better names for these can be invented before the first release
that would probably be beneficial.
(run_2to3 I find OK, though, it's basically the other ones).

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

From chris at simplistix.co.uk  Mon Sep 21 12:42:43 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 21 Sep 2009 11:42:43 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <7b63c276c622d3fe6f7512bdb324825c@preisshare.net>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<20090911163232.GB2903@laurie.devork>	<94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
	<20090912145036.GB13831@laurie.devork>
	<4AB35E44.9070707@simplistix.co.uk>
	<7b63c276c622d3fe6f7512bdb324825c@preisshare.net>
Message-ID: <4AB758A3.8000302@simplistix.co.uk>

David Lyon wrote:
> Don't worry Chris, if your idea is good enough, it is going
> to get forked...

Sorry, I misheard that last word, in which case I agree ;-)

Chris

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

From klich.michal at gmail.com  Fri Sep 18 21:54:21 2009
From: klich.michal at gmail.com (=?utf-8?q?Micha=C5=82_Klich?=)
Date: Fri, 18 Sep 2009 21:54:21 +0200
Subject: [Distutils] distutils bdist_rpm and %postun section of spec file
In-Reply-To: <200909172207.17796.a.cavallo@cavallinux.eu>
References: <696781e0909110955x1fde5c7dj8c0a64238932e1e9@mail.gmail.com>
	<200909172207.17796.a.cavallo@cavallinux.eu>
Message-ID: <200909182154.21494.klich.michal@gmail.com>

Dnia czwartek 17 wrze?nia 2009 o 23:07:17 A. Cavallo napisa?(a):
> Hi,
> as rule of thumb (followed now by all major distros) you should not put any
> script in %postun, %postinst etc sections.
> 
> Regards,
> Antonio
> 
> > Hello,
> > I am looking for some advise in creating rpm package using bdist_rpm.
> > I have managed to create post_install part using information
> > http://stackoverflow.com/questions/1321270/how-to-extend-distutils-with-a
> >-s imple-post-install-script Now i would like to add some code to %postun
> > part of spec file to revert changes done by my post_install command.
> > Is there a way to add it in setup.py or do i have to manually edit spec
> > file?
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 

It is not mentioned in Fedora guidelines
http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Guidelines

Ok, how would you handle creating symlink in setup.py? and removing it of 
course when uninstalling rpm. That is my goal. 
I managed to create symlink with setup.py but can not find any option for 
removing, which is i think correct as there is no uninstall option for 
setup.py.


-- 
Micha? Klich

klich.michal at gmail.com
michal at michalklich.com
http://www.michalklich.com

From ws at gocept.com  Mon Sep 21 09:19:31 2009
From: ws at gocept.com (Wolfgang Schnerring)
Date: Mon, 21 Sep 2009 09:19:31 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
Message-ID: <20090921071931.GD9685@elzar.ws.whq.gocept.com>

* Lennart Regebro <regebro at gmail.com> [2009-09-19 08:16]:
> 2009/9/19 Wolfgang Schnerring <wosc at wosc.de>:
> > The idea of this *not* being a setup() argument was to keep
> > compatibility with setuptools (since it will complain about arguments it
> > doesn't understand). This would enable a package to use setuptools or
> > distribute (or whatever ;) for python2, and only require distribute for
> > the python3/2to3 goodness.
> 
> The warning that you'll get under setuptools is not an actual
> problem is it?

Ah, Martin and I thought that it would produce an *error*, but we
didn't actually check that AFAIR. I just did, and you're right, it's
just a warning -- and that's not a problem, I think.

> Still, I probably prefer that we keep one API, and not two. :)

Very much agreed, let's use setup() arguments.

Wolfgang

From ws at gocept.com  Mon Sep 21 14:37:15 2009
From: ws at gocept.com (Wolfgang Schnerring)
Date: Mon, 21 Sep 2009 14:37:15 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
Message-ID: <20090921123715.GF9685@elzar.ws.whq.gocept.com>

* Lennart Regebro <regebro at gmail.com> [2009-09-21 12:04]:
> Great. I've checked in some docs too, I expanded the section on Python
> 3 support and ended up creating a new document, python3.txt. Feedback
> on that is appreciated.

Excellent! I think that covers it pretty well.
 
> Also, feedback on the naming of the keywords is appreciated. Yes, I
> know it's bikeshedding, but I find the current parameter names clunky,
> but have no better ideas.

My favourite colour: use 2to3 as the prefix (consistency helps, I
think), like so:
  2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...

Wolfgang

From jim at zope.com  Mon Sep 21 19:40:18 2009
From: jim at zope.com (Jim Fulton)
Date: Mon, 21 Sep 2009 13:40:18 -0400
Subject: [Distutils] Buildout + namespace packages + Django management
	commands?
In-Reply-To: <bf63202c0909200745y772f1417td7ebbfc7c578d3a9@mail.gmail.com>
References: <bf63202c0909190548n1b4d1731we8b9297824db8885@mail.gmail.com>
	<20090919144517.4D9D73A4079@sparrow.telecommunity.com>
	<bf63202c0909200117u9f95f5aibdb3f69d85d2d7b2@mail.gmail.com>
	<bf63202c0909200745y772f1417td7ebbfc7c578d3a9@mail.gmail.com>
Message-ID: <1099b90b0909211040x3b1126e1l482c9c9b4dd7acde@mail.gmail.com>

On Sun, Sep 20, 2009 at 10:45 AM, Kyle MacFarlane
<kylemacfarlane at gmail.com> wrote:
> 2009/9/20 Kyle MacFarlane <kylemacfarlane at gmail.com>
...
> But I have one (I hope) remaining problem. When buildout is run

I assume you mean when bootstrapping.

> the first
> thing it does is install zc.buildout and setuptools and totally ignores any
> custom settings when doing so. How can I have setuptools install without
> being zipped? I've tried "unzip = true" in buildout.cfg but that is ignored
> too.

This is a bug. :) I *think* the fix is straightforward.  I'll try to
get a fix out soon.

Jim

-- 
Jim Fulton

From greno at verizon.net  Mon Sep 21 21:16:06 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 21 Sep 2009 15:16:06 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB7141D.9040702@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
Message-ID: <4AB7D0F6.60502@verizon.net>

Andrew,  Ok, .deb is building fine using modified stdeb 0.3 on hardy.  
I've installed the .deb and it works.

I can see that stdeb is using debhelper which I really don't know much 
about.  So it looks like debhelper or dh_make is generating the control 
files. 
What I need is someway that in myapp maybe under a debian/ directory, I 
can create postinst and prerm files and then stdeb would look for those 
in the orig tarball and use them if found.  Is this possible?

Regards,
Gerry


From strawman at astraw.com  Mon Sep 21 21:27:52 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 21 Sep 2009 12:27:52 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB7D0F6.60502@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net>
Message-ID: <4AB7D3B8.7010109@astraw.com>

Gerry Reno wrote:
> Andrew,  Ok, .deb is building fine using modified stdeb 0.3 on hardy. 
> I've installed the .deb and it works.
>
> I can see that stdeb is using debhelper which I really don't know much
> about.  So it looks like debhelper or dh_make is generating the
> control files. What I need is someway that in myapp maybe under a
> debian/ directory, I can create postinst and prerm files and then
> stdeb would look for those in the orig tarball and use them if found. 
> Is this possible?
The debian packaging machinery invoked by dpkg-buildpackage will pick up
any scripts named my-package-name.preinst, my-package-name.postinst,
my-package-name.prerm, my-package-name.postrm that happen to be in the
debian/ directory. See
http://sdn.vlsm.org/share/Debian-Doc/manuals/maint-guide/ch-dother.en.html
for more info. So you have to modify stdeb to drop the appropriate files
in there if they're given as a config argument to stdeb. The stdeb
master branch already creates such a file for housekeeping reasons (see
commit
http://github.com/astraw/stdeb/commit/9faaf049a1a7fbd8f5e1fb658248013f208f398c
where I added this).

-Andrew

From regebro at gmail.com  Mon Sep 21 22:15:31 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 21 Sep 2009 22:15:31 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <20090921123715.GF9685@elzar.ws.whq.gocept.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
	<20090921123715.GF9685@elzar.ws.whq.gocept.com>
Message-ID: <319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>

2009/9/21 Wolfgang Schnerring <ws at gocept.com>:
> My favourite colour: use 2to3 as the prefix (consistency helps, I
> think), like so:
> ?2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...

That works. Maybe just 2to3_doctests?

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

From greno at verizon.net  Mon Sep 21 22:08:25 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 21 Sep 2009 16:08:25 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB7D3B8.7010109@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
Message-ID: <4AB7DD39.1060506@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew,  Ok, .deb is building fine using modified stdeb 0.3 on hardy. 
>> I've installed the .deb and it works.
>>
>> I can see that stdeb is using debhelper which I really don't know much
>> about.  So it looks like debhelper or dh_make is generating the
>> control files. What I need is someway that in myapp maybe under a
>> debian/ directory, I can create postinst and prerm files and then
>> stdeb would look for those in the orig tarball and use them if found. 
>> Is this possible?
>>     
> The debian packaging machinery invoked by dpkg-buildpackage will pick up
> any scripts named my-package-name.preinst, my-package-name.postinst,
> my-package-name.prerm, my-package-name.postrm that happen to be in the
> debian/ directory. See
> http://sdn.vlsm.org/share/Debian-Doc/manuals/maint-guide/ch-dother.en.html
> for more info. So you have to modify stdeb to drop the appropriate files
> in there if they're given as a config argument to stdeb. The stdeb
> master branch already creates such a file for housekeeping reasons (see
> commit
> http://github.com/astraw/stdeb/commit/9faaf049a1a7fbd8f5e1fb658248013f208f398c
> where I added this).
>   

I really didn't have to use any stdeb config args or anything.  I just 
created a dir  myapp/debian and put a python-myapp.postinst script file 
in there, ran my bdist_deb command and then installed the .deb and the 
python-myapp.postinst script ran perfectly.  So do I need to be 
concerned with config args to stdeb?  I do see some 
python-myapp.postinst.debhelper etc. scripts in there but I don't know 
if those ran.

Regards,
Gerry


From pje at telecommunity.com  Mon Sep 21 23:25:08 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 21 Sep 2009 17:25:08 -0400
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.co
 m>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909180632h41329ccbh48b4aca4fe150e2a@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
	<20090921123715.GF9685@elzar.ws.whq.gocept.com>
	<319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>
Message-ID: <20090921212507.2F0A03A407A@sparrow.telecommunity.com>

At 10:15 PM 9/21/2009 +0200, Lennart Regebro wrote:
>2009/9/21 Wolfgang Schnerring <ws at gocept.com>:
> > My favourite colour: use 2to3 as the prefix (consistency helps, I
> > think), like so:
> >  2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...
>
>That works. Maybe just 2to3_doctests?

Really?  I would think 2to3_anything is not a valid keyword argument name.


From greno at verizon.net  Mon Sep 21 23:53:27 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 21 Sep 2009 17:53:27 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB7DD39.1060506@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net>
Message-ID: <4AB7F5D7.9020002@verizon.net>

Gerry Reno wrote:
>
> I really didn't have to use any stdeb config args or anything. I just 
> created a dir myapp/debian and put a python-myapp.postinst script file 
> in there, ran my bdist_deb command and then installed the .deb and the 
> python-myapp.postinst script ran perfectly. So do I need to be 
> concerned with config args to stdeb? I do see some 
> python-myapp.postinst.debhelper etc. scripts in there but I don't know 
> if those ran.
>

So now everything is working on hardy except for the fact that stdeb 0.3 
has to be modified to remove the --single-version-externally-managed 
option. So can you just create a 0.3a version with this small change and 
that could go out to the repositories and be available by default to 
everyone. There does not seem to be any impact that I can see in making 
this change and since so many people create their own install classes 
this would actually prevent conflicts.

Regards,
Gerry


From david.lyon at preisshare.net  Tue Sep 22 00:54:37 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 21 Sep 2009 18:54:37 -0400
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <874oqwvhnk.fsf@benfinney.id.au>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090915154659.GB21452@laurie.devork>
	<cf1334183604772ec70ae49d9d19ea61@preisshare.net>
	<2AB2FCC4-FA1C-4E14-8B6B-7F1399570451@gmail.com>
	<20090916004224.12215.148262663.divmod.xquotient.28@localhost.localdomain>
	<94bdd2610909160316o7834108bh9407e78a848d82ec@mail.gmail.com>
	<20090916161435.26CB33A4079@sparrow.telecommunity.com>
	<ef11936ece77de2c0f5c1d30d7ae2f9f@preisshare.net>
	<20090917020123.C342A3A4079@sparrow.telecommunity.com>
	<ab31b4686253fd8b22f96ff87d78eb3f@preisshare.net>
	<20090917033411.8C25D3A4079@sparrow.telecommunity.com>
	<f072e62f736d65ef4df8e4bc88eaa6e0@preisshare.net>
	<20090921035804.A731B3A403D@sparrow.telecommunity.com>
	<62ef464f511ca6e2a682c5e33a51018d@preisshare.net>
	<87d45kvlg9.fsf@benfinney.id.au>
	<1156ecaf38815762a4eb1a67a2620447@preisshare.net>
	<874oqwvhnk.fsf@benfinney.id.au>
Message-ID: <1483a1f40d09e400241ec083c6c6af74@preisshare.net>

On Mon, 21 Sep 2009 18:14:23 +1000, Ben Finney <ben+python at benfinney.id.au>
wrote:
>> What? to say windows users don't like command lines...
>>
>> It's perfectly true. Not condescending.
> 
> I know many users of systems who ?don't like? command lines. You're
> going beyond that, though, and saying that it's unreasonable to expect
> users of a particular platform to use tools similar to those that users
> of other platforms use.

Whatever.. 

This is sounding too much like an o/s debate to me.

To which I'm no longer commenting...

Have a nice day

David

From regebro at gmail.com  Tue Sep 22 05:03:19 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 22 Sep 2009 05:03:19 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <20090921212507.2F0A03A407A@sparrow.telecommunity.com>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
	<20090921123715.GF9685@elzar.ws.whq.gocept.com>
	<319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>
	<20090921212507.2F0A03A407A@sparrow.telecommunity.com>
Message-ID: <319e029f0909212003k3d5b8599uca91f104da160d49@mail.gmail.com>

2009/9/21 P.J. Eby <pje at telecommunity.com>:
> At 10:15 PM 9/21/2009 +0200, Lennart Regebro wrote:
>>
>> 2009/9/21 Wolfgang Schnerring <ws at gocept.com>:
>> > My favourite colour: use 2to3 as the prefix (consistency helps, I
>> > think), like so:
>> > ?2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...
>>
>> That works. Maybe just 2to3_doctests?
>
> Really? ?I would think 2to3_anything is not a valid keyword argument name.

D'oh!

You are right. OK, other ideas?

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

From thomas at thomas-lotze.de  Tue Sep 22 07:45:29 2009
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Tue, 22 Sep 2009 07:45:29 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>	<4AB38E39.2040805@nextday.fi>	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>	<20090921071931.GD9685@elzar.ws.whq.gocept.com>	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>	<20090921123715.GF9685@elzar.ws.whq.gocept.com>	<319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>	<20090921212507.2F0A03A407A@sparrow.telecommunity.com>	<319e029f0909212003k3d5b8599uca91f104da160d49@mail.gmail.com>
Message-ID: <pan.2009.09.22.05.10.47.23080@ID-174572.user.uni-berlin.de>

Lennart Regebro wrote:

> 2009/9/21 P.J. Eby <pje at telecommunity.com>:
>> Really? ?I would think 2to3_anything is not a valid keyword argument
>> name.
> 
> D'oh!
> 
> You are right. OK, other ideas?

The trivial one would be to use 2to3 as a postfix rather than as a prefix.

-- 
Thomas




From alex.gronholm at nextday.fi  Tue Sep 22 16:31:01 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Tue, 22 Sep 2009 17:31:01 +0300
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <pan.2009.09.22.05.10.47.23080@ID-174572.user.uni-berlin.de>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>	<4AB38E39.2040805@nextday.fi>	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>	<20090921071931.GD9685@elzar.ws.whq.gocept.com>	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>	<20090921123715.GF9685@elzar.ws.whq.gocept.com>	<319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>	<20090921212507.2F0A03A407A@sparrow.telecommunity.com>	<319e029f0909212003k3d5b8599uca91f104da160d49@mail.gmail.com>
	<pan.2009.09.22.05.10.47.23080@ID-174572.user.uni-berlin.de>
Message-ID: <4AB8DFA5.7040704@nextday.fi>

Thomas Lotze kirjoitti:
> Lennart Regebro wrote:
>
>   
>> 2009/9/21 P.J. Eby <pje at telecommunity.com>:
>>     
>>> Really?  I would think 2to3_anything is not a valid keyword argument
>>> name.
>>>       
>> D'oh!
>>
>> You are right. OK, other ideas?
>>     
>
> The trivial one would be to use 2to3 as a postfix rather than as a prefix.
>
>   
use_2to3, convert_2to3_doctests, use_2to3_fixers?

From regebro at gmail.com  Tue Sep 22 17:00:45 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 22 Sep 2009 17:00:45 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <4AB8DFA5.7040704@nextday.fi>
References: <319e029f0909172324qcbad29ck7857f937c476f0f2@mail.gmail.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
	<20090921123715.GF9685@elzar.ws.whq.gocept.com>
	<319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>
	<20090921212507.2F0A03A407A@sparrow.telecommunity.com>
	<319e029f0909212003k3d5b8599uca91f104da160d49@mail.gmail.com>
	<pan.2009.09.22.05.10.47.23080@ID-174572.user.uni-berlin.de>
	<4AB8DFA5.7040704@nextday.fi>
Message-ID: <319e029f0909220800p4a1d840ek8f5ef52901af3026@mail.gmail.com>

2009/9/22 Alex Gr?nholm <alex.gronholm at nextday.fi>
> Thomas Lotze kirjoitti:
>> The trivial one would be to use 2to3 as a postfix rather than as a prefix.

> use_2to3, convert_2to3_doctests, use_2to3_fixers?

OK, I'll go for this. Good enough. Discussion over. :)

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

From ws at gocept.com  Tue Sep 22 18:28:19 2009
From: ws at gocept.com (Wolfgang Schnerring)
Date: Tue, 22 Sep 2009 18:28:19 +0200
Subject: [Distutils] Comments on Python 3 support for Distribute.
In-Reply-To: <319e029f0909212003k3d5b8599uca91f104da160d49@mail.gmail.com>
References: <4AB38E39.2040805@nextday.fi>
	<319e029f0909180646s35394ba6odd3d26e87e988231@mail.gmail.com>
	<878wgbcxlw.fsf@elzar.ws.whq.gocept.com>
	<319e029f0909182316n7349d183i5e907a24f07571d2@mail.gmail.com>
	<20090921071931.GD9685@elzar.ws.whq.gocept.com>
	<319e029f0909210304u2bbfd93cnd36db5dec631c9@mail.gmail.com>
	<20090921123715.GF9685@elzar.ws.whq.gocept.com>
	<319e029f0909211315g227acf53p21c862ccdf4140e0@mail.gmail.com>
	<20090921212507.2F0A03A407A@sparrow.telecommunity.com>
	<319e029f0909212003k3d5b8599uca91f104da160d49@mail.gmail.com>
Message-ID: <20090922162819.GE9506@elzar.ws.whq.gocept.com>

* Lennart Regebro <regebro at gmail.com> [2009-09-22 05:03]:
> >> > 2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ...
> >> That works. Maybe just 2to3_doctests?
> > Really? I would think 2to3_anything is not a valid keyword argument name.
> You are right. OK, other ideas?

Damn. It'll be downhill from there. ;-)
How about py2to3_*?

Wolfgang

From strawman at astraw.com  Tue Sep 22 19:38:30 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 22 Sep 2009 10:38:30 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB7F5D7.9020002@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
Message-ID: <4AB90B96.8090802@astraw.com>

Gerry Reno wrote:
> Gerry Reno wrote:
>>
>> I really didn't have to use any stdeb config args or anything. I just
>> created a dir myapp/debian and put a python-myapp.postinst script file
>> in there, ran my bdist_deb command and then installed the .deb and the
>> python-myapp.postinst script ran perfectly. So do I need to be
>> concerned with config args to stdeb? I do see some
>> python-myapp.postinst.debhelper etc. scripts in there but I don't know
>> if those ran.
>>
> 
> So now everything is working on hardy except for the fact that stdeb 0.3
> has to be modified to remove the --single-version-externally-managed
> option. So can you just create a 0.3a version with this small change and
> that could go out to the repositories and be available by default to
> everyone. There does not seem to be any impact that I can see in making
> this change and since so many people create their own install classes
> this would actually prevent conflicts.

I figured out what the reason for --single-version-externally-managed is
-- it is required for namespace packages to function properly. Thus, I
can't remove it, as doing so would be a regression.

However, if you create a patch I can apply against the old-stable branch
that makes this optional, (e.g. set in a similar way as the
--ignore-install-requires option), I can add that and make release
0.3.1. Note also that I'm very close to releasing 0.4, as the 0.3 line
has major problems with Jaunty and later.

Are you planning to submit a patch for the bdist_deb command? I could
include that, too.

-Andrew


From greno at verizon.net  Tue Sep 22 19:57:23 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 22 Sep 2009 13:57:23 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB90B96.8090802@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com>
Message-ID: <4AB91003.5090507@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> So now everything is working on hardy except for the fact that stdeb 0.3
>> has to be modified to remove the --single-version-externally-managed
>> option. So can you just create a 0.3a version with this small change and
>> that could go out to the repositories and be available by default to
>> everyone. There does not seem to be any impact that I can see in making
>> this change and since so many people create their own install classes
>> this would actually prevent conflicts.
>>     
>
> I figured out what the reason for --single-version-externally-managed is
> -- it is required for namespace packages to function properly. Thus, I
> can't remove it, as doing so would be a regression.
>
> However, if you create a patch I can apply against the old-stable branch
> that makes this optional, (e.g. set in a similar way as the
> --ignore-install-requires option), I can add that and make release
> 0.3.1. 
Ok, I'll look at getting you a patch that removes the option.

> Note also that I'm very close to releasing 0.4, as the 0.3 line
> has major problems with Jaunty and later.
>
> Are you planning to submit a patch for the bdist_deb command? I could
> include that, too.
>   
Yes, I have something ready but I think the 'bdist_deb' command belongs 
as a distutils patch.  I created the command by subclassing the 
distutils Command class.  Maybe Tarek could comment on what might be 
best here. 

Here is my working 'bdist_deb' code verbatim from inside my setup.py:
(it could be more pythonic of course with less os.system commands but 
it's working real well this way at least)

=================================================
# Copyright 2009 Gerry Reno. 

# stdeb note:
# stdeb 0.3 needs its util.py modified to remove the install
# option "--single-version-externally-managed" otherwise
# if you have subclassed the distutils install class to
# create your own "install" class (rather common) you will
# get an "unrecognized option" error when using 'bdist_deb'.
# I had to make this change to stdeb in order to get stdeb to work
# on Ubuntu Hardy with a setup.py that defined its own install.

from distutils.core import Command

if sys.hexversion >= 0x020500F0:
        import stdeb
elif sys.argv[1] == 'bdist_deb':
        print sys.argv[1], "requires python >= 2.5"
        raise SystemExit(1)


class bdist_deb(Command):
    # creates .deb pkg from a .dsc file that is generated using stdeb module
    # requires stdeb, dpkg-dev, build-essential, python-all-dev, 
debhelper, python-support, fakeroot
    #
    # to add 'postinst' and friends just create a debian/ control 
directory in the home directory of your
    # application and add a file 'python-myapp.postinst' and it will be 
run post package installation.

    description = 'Create debian-style source (.dsc using stdeb module) 
and binary (.deb) packages'

    user_options = [    ('install-dir=', 'd', "directory to install the 
files to"),
                ]

    def initialize_options (self):
        self.install_dir = None
        self.outfiles = []

    def finalize_options (self):
        pass

    def run(self):
        import setuptools
        import commands

        # run a sub_command  (gen .dsc source pkg using stdeb)
        self.run_command('sdist_dsc')

        # save current directory
        setup_dir = os.getcwd()

        # define system command to execute  (find source pkg work tree)
        syscmd = ['find', 'deb_dist', '-mindepth', '1', '-maxdepth', 
'1', '-type', 'd',]

        # execute system command and read output  (execute and read 
output of find cmd)
        dsc_tree = strip(subprocess.Popen(syscmd, 
stdout=subprocess.PIPE).communicate()[0])  # strip needed to remove CR

        # use system command output  (change directory to work tree)
        os.chdir(dsc_tree)

        # define system command to execute  (gen .deb binary pkg)
        syscmd = 'dpkg-buildpackage -rfakeroot -uc -us'

        # execute system command
        if os.system(syscmd) == 0:
                print '.deb successfully created in deb_dist/'
        else:
                print 'problem creating .deb'

        # (change directory back to setup dir)
        os.chdir(setup_dir)



setup(name             = name,
        ...

      # add new bdist_deb command here
      cmdclass         = {
        ...
            'bdist_deb' : bdist_deb,
        ...
      },

        ...
      )
=================================================


Regards,
Gerry


From ronaldoussoren at mac.com  Tue Sep 22 20:56:27 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 22 Sep 2009 20:56:27 +0200
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <94bdd2610909110814s3e09735duedd37e8a984fb7d3@mail.gmail.com>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814s3e09735duedd37e8a984fb7d3@mail.gmail.com>
Message-ID: <573E7FDA-E1C5-40BE-891F-63F59FC0A00F@mac.com>


On 11 Sep, 2009, at 17:14, Tarek Ziad? wrote:
>
>
> - os_sysname
> - os_nodename
> - os_release
> - os_version
> - os_machine

Os.uname() does have a usability issue: the various values don't have  
a clear meaning, nor even a clear mapping to "marketing" numbers.

Examples:
* os_sysname is "darwin" on a macosx machine, not something that would  
be clear to a novice OSX developer
* os_release is not necessarily the same as the version of the OS but  
returns the version of the kernel. Examples of operating systems where  
the kernel version number and OS version number aren't the same:  
Solaris, MacOSX, and of course Linux

os_nodename shouldn't be used in setup.cfg at all, I don't see a good  
reason to include the hostname in check conditions in setup.cfg.  
There's always the full setup.py if you want complicated conditions.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090922/fd11508b/attachment-0001.bin>

From greno at verizon.net  Tue Sep 22 21:21:11 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 22 Sep 2009 15:21:11 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB91003.5090507@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
Message-ID: <4AB923A7.7060006@verizon.net>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>> So now everything is working on hardy except for the fact that stdeb 
>>> 0.3
>>> has to be modified to remove the --single-version-externally-managed
>>> option. So can you just create a 0.3a version with this small change 
>>> and
>>> that could go out to the repositories and be available by default to
>>> everyone. There does not seem to be any impact that I can see in making
>>> this change and since so many people create their own install classes
>>> this would actually prevent conflicts.
>>
>> I figured out what the reason for --single-version-externally-managed is
>> -- it is required for namespace packages to function properly. Thus, I
>> can't remove it, as doing so would be a regression.
>>
>> However, if you create a patch I can apply against the old-stable branch
>> that makes this optional, (e.g. set in a similar way as the
>> --ignore-install-requires option), I can add that and make release
>> 0.3.1. 
> Ok, I'll look at getting you a patch that removes the option.


Patch to utils.py in old-stable branch attached.


>
>> Note also that I'm very close to releasing 0.4, as the 0.3 line
>> has major problems with Jaunty and later.
>>
>> Are you planning to submit a patch for the bdist_deb command? I could
>> include that, too.
> Yes, I have something ready but I think the 'bdist_deb' command 
> belongs as a distutils patch. I created the command by subclassing the 
> distutils Command class. Maybe Tarek could comment on what might be 
> best here.
> Here is my working 'bdist_deb' code verbatim from inside my setup.py:
> (it could be more pythonic of course with less os.system commands but 
> it's working real well this way at least)
>
> =================================================
> # Copyright 2009 Gerry Reno.
> # stdeb note:
> # stdeb 0.3 needs its util.py modified to remove the install
> # option "--single-version-externally-managed" otherwise
> # if you have subclassed the distutils install class to
> # create your own "install" class (rather common) you will
> # get an "unrecognized option" error when using 'bdist_deb'.
> # I had to make this change to stdeb in order to get stdeb to work
> # on Ubuntu Hardy with a setup.py that defined its own install.
>
> from distutils.core import Command
>
> if sys.hexversion >= 0x020500F0:
> import stdeb
> elif sys.argv[1] == 'bdist_deb':
> print sys.argv[1], "requires python >= 2.5"
> raise SystemExit(1)
>
>
> class bdist_deb(Command):
> # creates .deb pkg from a .dsc file that is generated using stdeb module
> # requires stdeb, dpkg-dev, build-essential, python-all-dev, 
> debhelper, python-support, fakeroot
> #
> # to add 'postinst' and friends just create a debian/ control 
> directory in the home directory of your
> # application and add a file 'python-myapp.postinst' and it will be 
> run post package installation.
>
> description = 'Create debian-style source (.dsc using stdeb module) 
> and binary (.deb) packages'
>
> user_options = [ ('install-dir=', 'd', "directory to install the files 
> to"),
> ]
>
> def initialize_options (self):
> self.install_dir = None
> self.outfiles = []
>
> def finalize_options (self):
> pass
>
> def run(self):
> import setuptools
> import commands
>
> # run a sub_command (gen .dsc source pkg using stdeb)
> self.run_command('sdist_dsc')
>
> # save current directory
> setup_dir = os.getcwd()
>
> # define system command to execute (find source pkg work tree)
> syscmd = ['find', 'deb_dist', '-mindepth', '1', '-maxdepth', '1', 
> '-type', 'd',]
>
> # execute system command and read output (execute and read output of 
> find cmd)
> dsc_tree = strip(subprocess.Popen(syscmd, 
> stdout=subprocess.PIPE).communicate()[0]) # strip needed to remove CR
>
> # use system command output (change directory to work tree)
> os.chdir(dsc_tree)
>
> # define system command to execute (gen .deb binary pkg)
> syscmd = 'dpkg-buildpackage -rfakeroot -uc -us'
>
> # execute system command
> if os.system(syscmd) == 0:
> print '.deb successfully created in deb_dist/'
> else:
> print 'problem creating .deb'
>
> # (change directory back to setup dir)
> os.chdir(setup_dir)
>
>
>
> setup(name = name,
> ...
>
> # add new bdist_deb command here
> cmdclass = {
> ...
> 'bdist_deb' : bdist_deb,
> ...
> },
>
> ...
> )
> =================================================
>
>
> Regards,
> Gerry
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: util.py.diff
Type: text/x-patch
Size: 258 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090922/a8a5f9d9/attachment.bin>

From alex.gronholm at nextday.fi  Wed Sep 23 00:20:37 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 23 Sep 2009 01:20:37 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <4AB94DB5.3000105@nextday.fi>

Tarek Ziad? kirjoitti:
> Hello,
>
> The next Distribute version will be released soon, with python 3
> support (thanks to Martin, Lennart, and Alex !)
> and more bug fixed. (you can follow that in the issue tracker)
>
> If you want to give a hand on testing the next Distribute version,
> I've uploaded a dev version of the trunk of Distribute at
> nightly.ziade.org, meaning that you can try the upcoming release
> (at your own risks ;) )
>
> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
> - a modified distribute_setup.py script that will install the dev
> version : http://nightly.ziade.org/distribute_setup_dev.py
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>
> Any feedback would be greatly appreciated,
>
> Regards,
> Tarek
>
>   
Tried it against Jython 2.5.1rc2, failed -- both with and without a 
virtualenv (with setuptools already installed).

Extracting in /tmp/tmpEY4kVg

Now working in /tmp/tmpEY4kVg/distribute-0.6.2dev

Installing Distribute

IOError: [Errno 2] File not found - /tmp/tmpEY4kVg/distribute-0.6.2dev/setup.py install (No such file or directory)

Traceback (most recent call last):

  File "/home/demigod/downloads/distribute_setup_dev.py", line 413, in <module>

    main(sys.argv[1:])

  File "/home/demigod/downloads/distribute_setup_dev.py", line 410, in main

    _install(tarball)

  File "/home/demigod/downloads/distribute_setup_dev.py", line 64, in _install

    assert python_cmd('setup.py install')

AssertionError



From alex.gronholm at nextday.fi  Wed Sep 23 00:28:21 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 23 Sep 2009 01:28:21 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <4AB94F85.1070707@nextday.fi>

Tarek Ziad? kirjoitti:
> Hello,
>
> The next Distribute version will be released soon, with python 3
> support (thanks to Martin, Lennart, and Alex !)
> and more bug fixed. (you can follow that in the issue tracker)
>
> If you want to give a hand on testing the next Distribute version,
> I've uploaded a dev version of the trunk of Distribute at
> nightly.ziade.org, meaning that you can try the upcoming release
> (at your own risks ;) )
>
> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
> - a modified distribute_setup.py script that will install the dev
> version : http://nightly.ziade.org/distribute_setup_dev.py
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>
> Any feedback would be greatly appreciated,
>
> Regards,
> Tarek
>
>   
Installation as a regular user on python 2.6.2 failed too, tries to 
install to the system dist-packages directory. Is there a switch that I 
need to use? Tried --user, no change.
Tried a 2to3'd version on py3k, didn't work either (for a regular user).


From alex.gronholm at nextday.fi  Wed Sep 23 03:00:48 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 23 Sep 2009 04:00:48 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <4AB97340.101@nextday.fi>

Tarek Ziad? kirjoitti:
> Hello,
>
> The next Distribute version will be released soon, with python 3
> support (thanks to Martin, Lennart, and Alex !)
> and more bug fixed. (you can follow that in the issue tracker)
>
> If you want to give a hand on testing the next Distribute version,
> I've uploaded a dev version of the trunk of Distribute at
> nightly.ziade.org, meaning that you can try the upcoming release
> (at your own risks ;) )
>
> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
> - a modified distribute_setup.py script that will install the dev
> version : http://nightly.ziade.org/distribute_setup_dev.py
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>
> Any feedback would be greatly appreciated,
>
> Regards,
> Tarek
>
>   
I just committed some fixes to distribute_setup.py. Now it installed 
nicely on Jython 2.5.1rc2 and Python 3.1.1 on Windows.

However, easy_install did NOT work on Windows (Win7 64-bit, 64-bit 
Python). I get the UAE dialog every time I launch easy_install as 
non-admin, and even when running with administrator privileges, it 
always exits with this message: "Cannot find Python executable 
C:\Python31\python.exe", even though that file does exist at said location.
On Linux it gets a bit farther: it seemed to install the package, but on 
closer inspection I noticed that the 2to3 converted code is not used at 
all -- not in the zip_safe analysis nor the actual installation!

I suppose we need Lennart's patches to test user mode installation (--user).


From alex.gronholm at nextday.fi  Wed Sep 23 06:25:25 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 23 Sep 2009 07:25:25 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release -
	help	needed!
In-Reply-To: <4AB97340.101@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB97340.101@nextday.fi>
Message-ID: <4AB9A335.8060202@nextday.fi>

Alex Gr?nholm kirjoitti:
> Tarek Ziad? kirjoitti:
>> Hello,
>>
>> The next Distribute version will be released soon, with python 3
>> support (thanks to Martin, Lennart, and Alex !)
>> and more bug fixed. (you can follow that in the issue tracker)
>>
>> If you want to give a hand on testing the next Distribute version,
>> I've uploaded a dev version of the trunk of Distribute at
>> nightly.ziade.org, meaning that you can try the upcoming release
>> (at your own risks ;) )
>>
>> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
>> - a modified distribute_setup.py script that will install the dev
>> version : http://nightly.ziade.org/distribute_setup_dev.py
>> - a modified bootstrap.py file that will let you bootstrap a
>> zc.buildout environment with this version
>>
>> Any feedback would be greatly appreciated,
>>
>> Regards,
>> Tarek
>>
>>   
> I just committed some fixes to distribute_setup.py. Now it installed 
> nicely on Jython 2.5.1rc2 and Python 3.1.1 on Windows.
>
> However, easy_install did NOT work on Windows (Win7 64-bit, 64-bit 
> Python). I get the UAE dialog every time I launch easy_install as 
> non-admin, and even when running with administrator privileges, it 
> always exits with this message: "Cannot find Python executable 
> C:\Python31\python.exe", even though that file does exist at said 
> location.
> On Linux it gets a bit farther: it seemed to install the package, but 
> on closer inspection I noticed that the 2to3 converted code is not 
> used at all -- not in the zip_safe analysis nor the actual installation!
Yeah, I just now remembered that this part (2to3) is waiting for 
Lennart's patches as well...
>
>
> I suppose we need Lennart's patches to test user mode installation 
> (--user).
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From regebro at gmail.com  Wed Sep 23 08:15:26 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Sep 2009 08:15:26 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4AB97340.101@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB97340.101@nextday.fi>
Message-ID: <319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> However, easy_install did NOT work on Windows (Win7 64-bit, 64-bit Python).
> I get the UAE dialog every time I launch easy_install as non-admin, and even
> when running with administrator privileges, it always exits with this
> message: "Cannot find Python executable C:\Python31\python.exe", even though
> that file does exist at said location.
> On Linux it gets a bit farther: it seemed to install the package, but on
> closer inspection I noticed that the 2to3 converted code is not used at all
> -- not in the zip_safe analysis nor the actual installation!
>
> I suppose we need Lennart's patches to test user mode installation (--user).

You have my patches, so you have tested it. :-) Evidently it did not work. :-/
I'm not sure I have Windows access this week. We'll see.

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

From alex.gronholm at nextday.fi  Wed Sep 23 08:31:46 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 23 Sep 2009 09:31:46 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4AB97340.101@nextday.fi>	
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>	
	<4AB9BE3A.50706@nextday.fi>
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>
Message-ID: <4AB9C0D2.6030605@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> I'm not sure what you mean. I don't remember receiving any such things from
>> you, nor is it in the 0.6 branch.
>>     
>
> There are tons of patches in the 0.6 branch. That's why we wanted them tested.
>
>   
Yes, but did you or did you not commit such changes to the repository? 
If not, where can I find these patches so that I might apply them?
At least easy_install does not have the --user option added, which is 
necessary for this to work.


From regebro at gmail.com  Wed Sep 23 08:37:50 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Sep 2009 08:37:50 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4AB9C0D2.6030605@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB97340.101@nextday.fi>
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>
	<4AB9BE3A.50706@nextday.fi>
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>
	<4AB9C0D2.6030605@nextday.fi>
Message-ID: <319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> Yes, but did you or did you not commit such changes to the repository?

Yes, I did. Martin v L?wis did most of the work, so if you are looking
for my username you won't find them.

http://bitbucket.org/tarek/distribute/src/9145ea8b647b/

> At least easy_install does not have the --user option added, which is
> necessary for this to work.

Huh? It's not specifically a part of the Python 3 support, so if it's
not added I'm not sure why you think the Python 3 support should add
it. Can you explain what exactly you are trying to do, what you expect
to happen and what actually happens?

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

From strawman at astraw.com  Wed Sep 23 09:07:30 2009
From: strawman at astraw.com (Andrew Straw)
Date: Wed, 23 Sep 2009 00:07:30 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB923A7.7060006@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net>
Message-ID: <4AB9C932.2070907@astraw.com>

Gerry Reno wrote:
> Gerry Reno wrote:
>> Andrew Straw wrote:
>>> Gerry Reno wrote:
>>>> So now everything is working on hardy except for the fact that
>>>> stdeb 0.3
>>>> has to be modified to remove the --single-version-externally-managed
>>>> option. So can you just create a 0.3a version with this small
>>>> change and
>>>> that could go out to the repositories and be available by default to
>>>> everyone. There does not seem to be any impact that I can see in
>>>> making
>>>> this change and since so many people create their own install classes
>>>> this would actually prevent conflicts.
>>>
>>> I figured out what the reason for
>>> --single-version-externally-managed is
>>> -- it is required for namespace packages to function properly. Thus, I
>>> can't remove it, as doing so would be a regression.
>>>
>>> However, if you create a patch I can apply against the old-stable
>>> branch
>>> that makes this optional, (e.g. set in a similar way as the
>>> --ignore-install-requires option), I can add that and make release
>>> 0.3.1. 
>> Ok, I'll look at getting you a patch that removes the option.
>
>
> Patch to utils.py in old-stable branch attached.

I saw your patch, but that wasn't what I meant. Disabling
--single-version-externally-managed has to be optional, and the argument
must continue to be used by default. Simply removing the call will
create a regression for namespace packages. Thus, the
--single-version-externally-managed should only be removed when someone
explicitly asks for it to be removed (because they presumably know what
they're doing or are at least aware it may have negative consequences).
Hence my suggestion to look at how the --ignore-install-requires works
as an example of how to pass an option via the distuils infrastructure.


>>> Note also that I'm very close to releasing 0.4, as the 0.3 line
>>> has major problems with Jaunty and later.
>>>
>>> Are you planning to submit a patch for the bdist_deb command? I could
>>> include that, too.
>> Yes, I have something ready but I think the 'bdist_deb' command
>> belongs as a distutils patch. I created the command by subclassing
>> the distutils Command class. Maybe Tarek could comment on what might
>> be best here.
>> Here is my working 'bdist_deb' code verbatim from inside my setup.py:

OK, based on your code I added a "bdist_deb" distutils command to stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:

python -c "import stdeb; excecfile('setup.py')" bdist_deb

The implementation is in the old-stable branch
http://github.com/astraw/stdeb/commits/old-stable I will merge this into
the master branch soon.

-Andrew

From alex.gronholm at nextday.fi  Wed Sep 23 09:13:23 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 23 Sep 2009 10:13:23 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4AB97340.101@nextday.fi>	
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>	
	<4AB9BE3A.50706@nextday.fi>	
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>	
	<4AB9C0D2.6030605@nextday.fi>
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
Message-ID: <4AB9CA93.2030907@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Yes, but did you or did you not commit such changes to the repository?
>>     
>
> Yes, I did. Martin v L?wis did most of the work, so if you are looking
> for my username you won't find them.
>
> http://bitbucket.org/tarek/distribute/src/9145ea8b647b/
>   
I'm talking about the changes that would add the three keyword arguments 
to setup() (use_2to3 etc) so we wouldn't have to deal with two different 
APIs.
Such changes have not yet been committed to Tarek's repo. In my opinion, 
0.6.2 should not be released before this is done.
>   
>> At least easy_install does not have the --user option added, which is
>> necessary for this to work.
>>     
>
> Huh? It's not specifically a part of the Python 3 support, so if it's
> not added I'm not sure why you think the Python 3 support should add
> it. Can you explain what exactly you are trying to do, what you expect
> to happen and what actually happens
I just wanted to install distribute (and other packages as well) as 
non-root so I wouldn't screw up the system in case something went badly 
wrong. You're right of course, about it not being an inherent part of 
Python 3 support.

From alex.gronholm at nextday.fi  Wed Sep 23 09:50:45 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 23 Sep 2009 10:50:45 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4AB97340.101@nextday.fi>	
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>	
	<4AB9BE3A.50706@nextday.fi>	
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>	
	<4AB9C0D2.6030605@nextday.fi>
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
Message-ID: <4AB9D355.9040300@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Yes, but did you or did you not commit such changes to the repository?
>>     
>
> Yes, I did. Martin v L?wis did most of the work, so if you are looking
> for my username you won't find them.
>
> http://bitbucket.org/tarek/distribute/src/9145ea8b647b/
>
>   
>> At least easy_install does not have the --user option added, which is
>> necessary for this to work.
>>     
>
> Huh? It's not specifically a part of the Python 3 support, so if it's
> not added I'm not sure why you think the Python 3 support should add
> it. Can you explain what exactly you are trying to do, what you expect
> to happen and what actually happens?
>
>   
Just to clarify, I had not specified setuptools.run_2to3 = True 
anywhere, which is why any packages I installed on py3k were installed 
as-is, so no problems there (yet).

From regebro at gmail.com  Wed Sep 23 09:58:57 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Sep 2009 09:58:57 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4AB9CA93.2030907@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB97340.101@nextday.fi>
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>
	<4AB9BE3A.50706@nextday.fi>
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>
	<4AB9C0D2.6030605@nextday.fi>
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
	<4AB9CA93.2030907@nextday.fi>
Message-ID: <319e029f0909230058u7b0f2e1cse7366de521d7f476@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> I'm talking about the changes that would add the three keyword arguments to
> setup() (use_2to3 etc) so we wouldn't have to deal with two different APIs.
> Such changes have not yet been committed to Tarek's repo. In my opinion,
> 0.6.2 should not be released before this is done.

They have been commited, since a week, by Martin v L?wis. The push I
did yesterday to rename them apparently didn't work. hg is still
confusing me.

I pushed again.

> I just wanted to install distribute (and other packages as well) as non-root
> so I wouldn't screw up the system in case something went badly wrong.

Quite understandable, but it seems that's not in 0.6.x, it doesn't
show up under Linux either. Somebody else have to answer about this.

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

From alex.gronholm at nextday.fi  Wed Sep 23 10:11:00 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 23 Sep 2009 11:11:00 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <319e029f0909230058u7b0f2e1cse7366de521d7f476@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4AB97340.101@nextday.fi>	
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>	
	<4AB9BE3A.50706@nextday.fi>	
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>	
	<4AB9C0D2.6030605@nextday.fi>	
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>	
	<4AB9CA93.2030907@nextday.fi>
	<319e029f0909230058u7b0f2e1cse7366de521d7f476@mail.gmail.com>
Message-ID: <4AB9D814.60303@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> I'm talking about the changes that would add the three keyword arguments to
>> setup() (use_2to3 etc) so we wouldn't have to deal with two different APIs.
>> Such changes have not yet been committed to Tarek's repo. In my opinion,
>> 0.6.2 should not be released before this is done.
>>     
>
> They have been commited, since a week, by Martin v L?wis. The push I
> did yesterday to rename them apparently didn't work. hg is still
> confusing me.
>
> I pushed again.
>   
Yup, I see it now. It seems you accidentally created a new head two days 
ago. Shame on me for not noticing that earlier (bitbucket visualizes 
those things pretty well in the changesets view).
>   
>> I just wanted to install distribute (and other packages as well) as non-root
>> so I wouldn't screw up the system in case something went badly wrong.
>>     
>
> Quite understandable, but it seems that's not in 0.6.x, it doesn't
> show up under Linux either. Somebody else have to answer about this.
>
>   
I know it's not in 0.6.x -- the question is, should it be added in 
0.6.2, or in a future 0.6.x release, or left completely to 0.7?

From regebro at gmail.com  Wed Sep 23 10:28:39 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Sep 2009 10:28:39 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4AB9D814.60303@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB97340.101@nextday.fi>
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>
	<4AB9BE3A.50706@nextday.fi>
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>
	<4AB9C0D2.6030605@nextday.fi>
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
	<4AB9CA93.2030907@nextday.fi>
	<319e029f0909230058u7b0f2e1cse7366de521d7f476@mail.gmail.com>
	<4AB9D814.60303@nextday.fi>
Message-ID: <319e029f0909230128m48cf7095tef24dfbad6fd863c@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> Yup, I see it now. It seems you accidentally created a new head two days
> ago.

I did? How did I do that? How are you supposed to cimmit/push without
doing that, and why doesn't it bloody fail?

In short: Why does hg suck so much? I am extremely close to actually
refuse to use it until it's usable without a doctors degree in version
management.

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

From alex.gronholm at nextday.fi  Wed Sep 23 10:34:11 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 23 Sep 2009 11:34:11 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <319e029f0909230128m48cf7095tef24dfbad6fd863c@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4AB97340.101@nextday.fi>	
	<319e029f0909222315g28667b2fweb797e15f3e6b52@mail.gmail.com>	
	<4AB9BE3A.50706@nextday.fi>	
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>	
	<4AB9C0D2.6030605@nextday.fi>	
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>	
	<4AB9CA93.2030907@nextday.fi>	
	<319e029f0909230058u7b0f2e1cse7366de521d7f476@mail.gmail.com>	
	<4AB9D814.60303@nextday.fi>
	<319e029f0909230128m48cf7095tef24dfbad6fd863c@mail.gmail.com>
Message-ID: <4AB9DD83.3090401@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Yup, I see it now. It seems you accidentally created a new head two days
>> ago.
>>     
>
> I did? How did I do that? How are you supposed to cimmit/push without
> doing that, and why doesn't it bloody fail?
>
>   
It doesn't fail because it's not an error.
I'm not sure if I'm interpreting the graph right, but every time I'm 
about to accidentally do that, Eclipse screams bloody murder, so I don't 
think that was me.
> In short: Why does hg suck so much? I am extremely close to actually
> refuse to use it until it's usable without a doctors degree in version
> management.
>
>   
What would you rather use? Subversion? Let's face it, distributed SCMs 
aren't the easiest thing on the planet to learn, but they are the best 
solution for open source projects.


From regebro at gmail.com  Wed Sep 23 10:43:43 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Sep 2009 10:43:43 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4AB9DD83.3090401@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB9BE3A.50706@nextday.fi>
	<319e029f0909222325k44735404o2cf21ebcd1f5302e@mail.gmail.com>
	<4AB9C0D2.6030605@nextday.fi>
	<319e029f0909222337h73213f99yc8647dd22f1060bd@mail.gmail.com>
	<4AB9CA93.2030907@nextday.fi>
	<319e029f0909230058u7b0f2e1cse7366de521d7f476@mail.gmail.com>
	<4AB9D814.60303@nextday.fi>
	<319e029f0909230128m48cf7095tef24dfbad6fd863c@mail.gmail.com>
	<4AB9DD83.3090401@nextday.fi>
Message-ID: <319e029f0909230143g1923abb2n55e741472d343b92@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> What would you rather use? Subversion?

Yes.

> Let's face it, distributed SCMs aren't the easiest thing on the planet to learn

I understand the principles, and I don't see why those principles have
to mean that every time you check something in, something gets fudged
up. Maybe they do, and in that case, I don't think we should use them.
The current situation is even worse than CVS. I do understand the
benefits, but I can't see that they are worth the drawbacks with hg.

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

From chris at simplistix.co.uk  Wed Sep 23 14:07:28 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 23 Sep 2009 13:07:28 +0100
Subject: [Distutils] [buildout] is there a way to force re-install of a part?
Message-ID: <4ABA0F80.4010705@simplistix.co.uk>

Hi All,

Is there any way to force a part to re-install?

I have a part using the djangorecipe part that stubbornly refuses to 
notice that I've changed an eggs dependencies or changed the stuff in 
the develop line of the [buildout] section.

I've tried "bin/buildout install djangopart" but this doesn't have any 
effect. The only way I've found to get the part to re-install is to 
change the options in the part, install, and then put the options back 
like I want them before re-installing :-(

cheers,

Chris

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

From floris.bruynooghe at gmail.com  Wed Sep 23 14:51:17 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 23 Sep 2009 13:51:17 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <4AB35E44.9070707@simplistix.co.uk>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>
	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>
	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>
	<20090911163232.GB2903@laurie.devork>
	<94bdd2610909111002mb20506bk37abeb8ff5b74796@mail.gmail.com>
	<20090912145036.GB13831@laurie.devork>
	<4AB35E44.9070707@simplistix.co.uk>
Message-ID: <20090923125117.GA19615@laurie.devork>

On Fri, Sep 18, 2009 at 11:17:40AM +0100, Chris Withers wrote:
> Floris Bruynooghe wrote:
> >On Fri, Sep 11, 2009 at 07:02:53PM +0200, Tarek Ziad? wrote:
> >>On Fri, Sep 11, 2009 at 6:32 PM, Floris Bruynooghe
> >><floris.bruynooghe at gmail.com> wrote:
> >>>On Fri, Sep 11, 2009 at 05:14:58PM +0200, Tarek Ziad? wrote:
> >>>[...]
> >>>>That can be dropped since we have '==' and it's all strings.
> >>>'2.6' < '2.10'?
> >>>
> >>>Although not close you must be wary of this.  Bring on PEP 386 ;-)
> >>Right. Maybe we can drop < >, >= and >=, completely.
> >>
> >>In real world use cases, we can use "or" to make a section work for
> >>2.6, 3.1, etc.. for python versions.
> >>
> >>I can't think of a use case where "in" and "==" is not enough.
> >
> >Version comparison would be nice though.  Taking your example from
> >your blog post: if I where to try to install that on Python 2.4 I'd
> >have to edit the condition of the [py25] section to "in ('2.4',
> >'2.5')".  Maybe this is what you want though, in case you explicitly
> >don't support for 2.4.  OTOH it's nice if things would just work in
> >case of developers simply not having tried earlier versions.
> >
> >This also shows how "in" implies a tuple or a list as data type, your
> >mini-language was trying to avoid that.  Or did I miss something?
> 
> A lot of these problems would go away if we could just treat
> "Python" as a package like every other package when it comes to
> dependencies.

How would that help in specifying dependencies based on a python
version?  The conditional syntax as discussed so far does not allow
for conditions based on versions of other packages detected.  And
doing so would seem like a lot more complicated then what's being
discussed so far (at first sight anyway, haven't tought too deeply
about this yet).

Regards
Floris

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

From floris.bruynooghe at gmail.com  Wed Sep 23 14:56:19 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 23 Sep 2009 13:56:19 +0100
Subject: [Distutils] [Python-Dev] Distutils ML wrap-up: setup.cfg new
	format
In-Reply-To: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>
References: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>
Message-ID: <20090923125619.GB14012@laurie.devork>

[original mail from python-dev
http://mail.python.org/pipermail/python-dev/2009-September/091947.html]

On Tue, Sep 22, 2009 at 03:21:06PM +0200, Tarek Ziad? wrote:
> The pseudo-grammar is (I don't know how to write those but you'll
> get it hopefully)::
> 
>     comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
>     comparison: expr (comp_op expr)*
>     expr: STRING
>     test: or_test
>     or_test: and_test ('or' and_test)*
>     and_test: not_test ('and' not_test)*
>     not_test: 'not' not_test | comparison

Here you're re-introducing '<', '>', '<=' and '>=' while you said [0]
that you where going to drop them.  I'm still not convinced of
allowing this between strings as it will likely lead to mistakes when
comparing "versions".  I'm still tempted by making "python_version" a
RationalVersion() so that you can use '<', '>', '<=' and '>=' safely,
not really convinced of writing something like:

  [setup:python_version == '2.2' or python_version == '2.3' or
   python_version == '2.4']

(Can you even split section headers over multiple lines in ini-files?)


As an asside, python 3 is dropping '<>' so maybe it would be
easier/less confusing to just not include it here?


Regards
Floris


[0] http://mail.python.org/pipermail/distutils-sig/2009-September/013205.html


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

From ziade.tarek at gmail.com  Wed Sep 23 15:15:24 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Sep 2009 15:15:24 +0200
Subject: [Distutils] [Python-Dev] Distutils ML wrap-up: setup.cfg new
	format
In-Reply-To: <20090923125619.GB14012@laurie.devork>
References: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>
	<20090923125619.GB14012@laurie.devork>
Message-ID: <94bdd2610909230615n13563040g3668b6437b9bcde7@mail.gmail.com>

On Wed, Sep 23, 2009 at 2:56 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> [original mail from python-dev
> http://mail.python.org/pipermail/python-dev/2009-September/091947.html]
>
> On Tue, Sep 22, 2009 at 03:21:06PM +0200, Tarek Ziad? wrote:
>> The pseudo-grammar is (I don't know how to write those but you'll
>> get it hopefully)::
>>
>> ? ? comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
>> ? ? comparison: expr (comp_op expr)*
>> ? ? expr: STRING
>> ? ? test: or_test
>> ? ? or_test: and_test ('or' and_test)*
>> ? ? and_test: not_test ('and' not_test)*
>> ? ? not_test: 'not' not_test | comparison
>
> Here you're re-introducing '<', '>', '<=' and '>=' while you said [0]
> that you where going to drop them.

Right, that was a copy-paste typo:

comp: '=='|'!='|'in'|'not' 'in'

>?I'm still not convinced of
> allowing this between strings as it will likely lead to mistakes when
> comparing "versions". ?I'm still tempted by making "python_version" a
> RationalVersion() so that you can use '<', '>', '<=' and '>=' safely,
> not really convinced of writing something like:
>
> ?[setup:python_version == '2.2' or python_version == '2.3' or
> ? python_version == '2.4']

That's quite verbose indeed, but that is required if we want to
keep string comparison.

what about keeping python_version a string, but  changing the way it's created ?

python_version : string_version('%s.%s' % (sys.version_info[0],
sys.version_info[1]))

where string_version() is a function that makes sure the output is
something we can compare
to strings like '2.4', etc.

I wouldn't talk about RationalVersion() from PEP 386 here, because we
just want a subset of it in this function : The Python version scheme.

Then we could re-introduce '<' and '>'

>
> (Can you even split section headers over multiple lines in ini-files?)

I don't think so.

Regards

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

From fwierzbicki at gmail.com  Wed Sep 23 15:38:18 2009
From: fwierzbicki at gmail.com (Frank Wierzbicki)
Date: Wed, 23 Sep 2009 09:38:18 -0400
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4AB97340.101@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4AB97340.101@nextday.fi>
Message-ID: <4dab5f760909230638j26020e19o67d67de7ad67b811@mail.gmail.com>

2009/9/22 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> I just committed some fixes to distribute_setup.py. Now it installed nicely
> on Jython 2.5.1rc2 and Python 3.1.1 on Windows.
De-lurking for a second to thank you for looking into Jython support!

-Frank

From greno at verizon.net  Wed Sep 23 17:43:24 2009
From: greno at verizon.net (Gerry Reno)
Date: Wed, 23 Sep 2009 11:43:24 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4AB9C932.2070907@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
Message-ID: <4ABA421C.7000405@verizon.net>

Andrew Straw wrote:
>
> I saw your patch, but that wasn't what I meant. Disabling
> --single-version-externally-managed has to be optional, and the argument
> must continue to be used by default. Simply removing the call will
> create a regression for namespace packages. Thus, the
> --single-version-externally-managed should only be removed when someone
> explicitly asks for it to be removed (because they presumably know what
> they're doing or are at least aware it may have negative consequences).
> Hence my suggestion to look at how the --ignore-install-requires works
> as an example of how to pass an option via the distuils infrastructure.
>
>   
I'll look at --ignore-install-requires and send another patch.


> OK, based on your code I added a "bdist_deb" distutils command to stdeb.
> I've checked this into the old-stable branch and I'd appreciate it if
> you can check whether this works for you and send me any comments.
> Invoke it like this:
>
> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>   
See this was my point of why my 'bdist_deb' belonged as a distutils 
patch and not in stdeb.
The inherited capabilities, behaviors and invocation style needs to 
follow all the other 'bdist' command types.
And that means being able to invoke it the same as say 'bdist_rpm' like:

python setup.py bdist_deb
or
python setup.py bdist_deb --<std bdist type arg> ...

If we start allowing 'bdist' derivative commands to diverge in their 
inherited capabilities, invocation style, and expected behaviors then 
chaos will ensue.

Regards,
Gerry



From alex.gronholm at nextday.fi  Wed Sep 23 18:15:11 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 23 Sep 2009 19:15:11 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <4ABA498F.60805@nextday.fi>

Tarek Ziad? kirjoitti:
> Hello,
>
> The next Distribute version will be released soon, with python 3
> support (thanks to Martin, Lennart, and Alex !)
> and more bug fixed. (you can follow that in the issue tracker)
>
> If you want to give a hand on testing the next Distribute version,
> I've uploaded a dev version of the trunk of Distribute at
> nightly.ziade.org, meaning that you can try the upcoming release
> (at your own risks ;) )
>
> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
> - a modified distribute_setup.py script that will install the dev
> version : http://nightly.ziade.org/distribute_setup_dev.py
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>
> Any feedback would be greatly appreciated,
>
> Regards,
> Tarek
>   
Hey Tarek, you might want to update the files now that both I and 
Lennart made new commits crucial to the upcoming version.


From floris.bruynooghe at gmail.com  Wed Sep 23 18:15:53 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 23 Sep 2009 17:15:53 +0100
Subject: [Distutils] [Python-Dev] Distutils ML wrap-up: setup.cfg new
 format
In-Reply-To: <94bdd2610909230615n13563040g3668b6437b9bcde7@mail.gmail.com>
References: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>
	<20090923125619.GB14012@laurie.devork>
	<94bdd2610909230615n13563040g3668b6437b9bcde7@mail.gmail.com>
Message-ID: <20090923161553.GA22903@laurie.devork>

On Wed, Sep 23, 2009 at 03:15:24PM +0200, Tarek Ziad? wrote:
> On Wed, Sep 23, 2009 at 2:56 PM, Floris Bruynooghe
> <floris.bruynooghe at gmail.com> wrote:
> > [original mail from python-dev
> > http://mail.python.org/pipermail/python-dev/2009-September/091947.html]
> >
> > On Tue, Sep 22, 2009 at 03:21:06PM +0200, Tarek Ziad? wrote:
> >> The pseudo-grammar is (I don't know how to write those but you'll
> >> get it hopefully)::
> >>
> >> ? ? comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
> >> ? ? comparison: expr (comp_op expr)*
> >> ? ? expr: STRING
> >> ? ? test: or_test
> >> ? ? or_test: and_test ('or' and_test)*
> >> ? ? and_test: not_test ('and' not_test)*
> >> ? ? not_test: 'not' not_test | comparison
> >
> > Here you're re-introducing '<', '>', '<=' and '>=' while you said [0]
> > that you where going to drop them.
> 
> Right, that was a copy-paste typo:
> 
> comp: '=='|'!='|'in'|'not' 'in'
> 
> >?I'm still not convinced of
> > allowing this between strings as it will likely lead to mistakes when
> > comparing "versions". ?I'm still tempted by making "python_version" a
> > RationalVersion() so that you can use '<', '>', '<=' and '>=' safely,
> > not really convinced of writing something like:
> >
> > ?[setup:python_version == '2.2' or python_version == '2.3' or
> > ? python_version == '2.4']
> 
> That's quite verbose indeed, but that is required if we want to
> keep string comparison.
> 
> what about keeping python_version a string, but  changing the way it's created ?
> 
> python_version : string_version('%s.%s' % (sys.version_info[0],
> sys.version_info[1]))
> 
> where string_version() is a function that makes sure the output is
> something we can compare
> to strings like '2.4', etc.
> 
> I wouldn't talk about RationalVersion() from PEP 386 here, because we
> just want a subset of it in this function : The Python version scheme.
> 
> Then we could re-introduce '<' and '>'

That's not a bad idea, how about defining python_version as:

  '%.8X' % sys.hexversion

Then using '<' and '>' would work again I think, just a little harder
to use.  (Of course don't forget the bikeshedding about the name:
python_hexversion, hexversion, ...)


Floris


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

From strawman at astraw.com  Wed Sep 23 18:31:26 2009
From: strawman at astraw.com (Andrew Straw)
Date: Wed, 23 Sep 2009 09:31:26 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABA421C.7000405@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net>
Message-ID: <4ABA4D5E.4080008@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>>
>> I saw your patch, but that wasn't what I meant. Disabling
>> --single-version-externally-managed has to be optional, and the argument
>> must continue to be used by default. Simply removing the call will
>> create a regression for namespace packages. Thus, the
>> --single-version-externally-managed should only be removed when someone
>> explicitly asks for it to be removed (because they presumably know what
>> they're doing or are at least aware it may have negative consequences).
>> Hence my suggestion to look at how the --ignore-install-requires works
>> as an example of how to pass an option via the distuils infrastructure.
>>
>>   
> I'll look at --ignore-install-requires and send another patch.
OK, great.

>> OK, based on your code I added a "bdist_deb" distutils command to stdeb.
>> I've checked this into the old-stable branch and I'd appreciate it if
>> you can check whether this works for you and send me any comments.
>> Invoke it like this:
>>
>> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>   
> See this was my point of why my 'bdist_deb' belonged as a distutils
> patch and not in stdeb.
> The inherited capabilities, behaviors and invocation style needs to
> follow all the other 'bdist' command types.
> And that means being able to invoke it the same as say 'bdist_rpm' like:
>
> python setup.py bdist_deb
> or
> python setup.py bdist_deb --<std bdist type arg> ...
>
> If we start allowing 'bdist' derivative commands to diverge in their
> inherited capabilities, invocation style, and expected behaviors then
> chaos will ensue.
This does have the same invocation style -- if you change your setup.py
to import stdeb. Otherwise, it's still the same invocation style -- you
just have to import stdeb outside the setup.py file.

Also, this version of bdist_deb is never going to make it into the
standard library as it depends on stdeb.

So feel free to make a counter proposal, but I'm inclined to think this
is useful to people as-is and has the benefit of working today.

-Andrew

From regebro at gmail.com  Wed Sep 23 18:48:13 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 23 Sep 2009 18:48:13 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4ABA498F.60805@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4ABA498F.60805@nextday.fi>
Message-ID: <319e029f0909230948p58d71a6fwe7fa080a1a5afcf8@mail.gmail.com>

Well, I've been running current trunk for all my Python 2.4 Plone
needs today, and works for that, and it also works for zope.interface
under Python 3. So I'm happy at least. ;)

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

From eric at trueblade.com  Wed Sep 23 19:00:10 2009
From: eric at trueblade.com (Eric Smith)
Date: Wed, 23 Sep 2009 13:00:10 -0400
Subject: [Distutils] [Python-Dev] Distutils ML wrap-up: setup.cfg new
 format
In-Reply-To: <20090923161553.GA22903@laurie.devork>
References: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>	<20090923125619.GB14012@laurie.devork>	<94bdd2610909230615n13563040g3668b6437b9bcde7@mail.gmail.com>
	<20090923161553.GA22903@laurie.devork>
Message-ID: <4ABA541A.8010502@trueblade.com>

Floris Bruynooghe wrote:
> On Wed, Sep 23, 2009 at 03:15:24PM +0200, Tarek Ziad? wrote:
>> On Wed, Sep 23, 2009 at 2:56 PM, Floris Bruynooghe
>> <floris.bruynooghe at gmail.com> wrote:
>>> [original mail from python-dev
>>> http://mail.python.org/pipermail/python-dev/2009-September/091947.html]
>>>
>>> On Tue, Sep 22, 2009 at 03:21:06PM +0200, Tarek Ziad? wrote:
>>>> The pseudo-grammar is (I don't know how to write those but you'll
>>>> get it hopefully)::
>>>>
>>>>     comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
>>>>     comparison: expr (comp_op expr)*
>>>>     expr: STRING
>>>>     test: or_test
>>>>     or_test: and_test ('or' and_test)*
>>>>     and_test: not_test ('and' not_test)*
>>>>     not_test: 'not' not_test | comparison
>>> Here you're re-introducing '<', '>', '<=' and '>=' while you said [0]
>>> that you where going to drop them.
>> Right, that was a copy-paste typo:
>>
>> comp: '=='|'!='|'in'|'not' 'in'
>>
>>>  I'm still not convinced of
>>> allowing this between strings as it will likely lead to mistakes when
>>> comparing "versions".  I'm still tempted by making "python_version" a
>>> RationalVersion() so that you can use '<', '>', '<=' and '>=' safely,
>>> not really convinced of writing something like:
>>>
>>>  [setup:python_version == '2.2' or python_version == '2.3' or
>>>   python_version == '2.4']
>> That's quite verbose indeed, but that is required if we want to
>> keep string comparison.
>>
>> what about keeping python_version a string, but  changing the way it's created ?
>>
>> python_version : string_version('%s.%s' % (sys.version_info[0],
>> sys.version_info[1]))
>>
>> where string_version() is a function that makes sure the output is
>> something we can compare
>> to strings like '2.4', etc.
>>
>> I wouldn't talk about RationalVersion() from PEP 386 here, because we
>> just want a subset of it in this function : The Python version scheme.
>>
>> Then we could re-introduce '<' and '>'
> 
> That's not a bad idea, how about defining python_version as:
> 
>   '%.8X' % sys.hexversion
> 
> Then using '<' and '>' would work again I think, just a little harder
> to use.  (Of course don't forget the bikeshedding about the name:
> python_hexversion, hexversion, ...)

I think I'd rather see us restrict ourselves to just == and != until we 
can finalize the version numbering PEP, then allow '>' and '<' in all 
places (after converting internally to RationalVersion, or whatever). I 
realize it's a hassle in the short term, but in the long term it should 
make things easier for us.

Eric.


From ziade.tarek at gmail.com  Wed Sep 23 19:03:45 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Sep 2009 19:03:45 +0200
Subject: [Distutils] [Python-Dev] Distutils ML wrap-up: setup.cfg new
	format
In-Reply-To: <20090923161553.GA22903@laurie.devork>
References: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>
	<20090923125619.GB14012@laurie.devork>
	<94bdd2610909230615n13563040g3668b6437b9bcde7@mail.gmail.com>
	<20090923161553.GA22903@laurie.devork>
Message-ID: <94bdd2610909231003t64c8fe19qe890834febe96c16@mail.gmail.com>

On Wed, Sep 23, 2009 at 6:15 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
>
> That's not a bad idea, how about defining python_version as:
>
> ?'%.8X' % sys.hexversion
>
> Then using '<' and '>' would work again I think, just a little harder
> to use. ?(Of course don't forget the bikeshedding about the name:
> python_hexversion, hexversion, ...)

What about having both in that case ? a regular python version
and the one you mention in python_hexversion.

The documentation will state that python_hexversion can be used with '<' and '>'


Tarek

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

From ziade.tarek at gmail.com  Wed Sep 23 19:08:37 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Sep 2009 19:08:37 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4ABA498F.60805@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4ABA498F.60805@nextday.fi>
Message-ID: <94bdd2610909231008q1e93d861uad1a69d333586999@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:

> Hey Tarek, you might want to update the files now that both I and Lennart
> made new commits crucial to the upcoming version.


Done !

I've updated :

- distribute_setup.py
- distribute_setup_dev.py
- distribute-0.6.2dev.tar.gz

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



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

From floris.bruynooghe at gmail.com  Wed Sep 23 19:13:08 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 23 Sep 2009 18:13:08 +0100
Subject: [Distutils] [Python-Dev] Distutils ML wrap-up: setup.cfg new
 format
In-Reply-To: <94bdd2610909231003t64c8fe19qe890834febe96c16@mail.gmail.com>
References: <94bdd2610909220621u54984c94ucf522dbe1fe68671@mail.gmail.com>
	<20090923125619.GB14012@laurie.devork>
	<94bdd2610909230615n13563040g3668b6437b9bcde7@mail.gmail.com>
	<20090923161553.GA22903@laurie.devork>
	<94bdd2610909231003t64c8fe19qe890834febe96c16@mail.gmail.com>
Message-ID: <20090923171308.GA24200@laurie.devork>

On Wed, Sep 23, 2009 at 07:03:45PM +0200, Tarek Ziad? wrote:
> On Wed, Sep 23, 2009 at 6:15 PM, Floris Bruynooghe
> <floris.bruynooghe at gmail.com> wrote:
> >
> > That's not a bad idea, how about defining python_version as:
> >
> > ?'%.8X' % sys.hexversion
> >
> > Then using '<' and '>' would work again I think, just a little harder
> > to use. ?(Of course don't forget the bikeshedding about the name:
> > python_hexversion, hexversion, ...)
> 
> What about having both in that case ? a regular python version
> and the one you mention in python_hexversion.
> 
> The documentation will state that python_hexversion can be used with
> '<' and '>'

That works too of course.


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

From greno at verizon.net  Wed Sep 23 20:05:50 2009
From: greno at verizon.net (Gerry Reno)
Date: Wed, 23 Sep 2009 14:05:50 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABA4D5E.4080008@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net> <4ABA4D5E.4080008@astraw.com>
Message-ID: <4ABA637E.1080804@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> I saw your patch, but that wasn't what I meant. Disabling
>>> --single-version-externally-managed has to be optional, and the argument
>>> must continue to be used by default. Simply removing the call will
>>> create a regression for namespace packages. Thus, the
>>> --single-version-externally-managed should only be removed when someone
>>> explicitly asks for it to be removed (because they presumably know what
>>> they're doing or are at least aware it may have negative consequences).
>>> Hence my suggestion to look at how the --ignore-install-requires works
>>> as an example of how to pass an option via the distuils infrastructure.
>>>
>>>   
>>>       
>> I'll look at --ignore-install-requires and send another patch.
>>     
> OK, great.
>
>   
>>> OK, based on your code I added a "bdist_deb" distutils command to stdeb.
>>> I've checked this into the old-stable branch and I'd appreciate it if
>>> you can check whether this works for you and send me any comments.
>>> Invoke it like this:
>>>
>>> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>>   
>>>       
>> See this was my point of why my 'bdist_deb' belonged as a distutils
>> patch and not in stdeb.
>> The inherited capabilities, behaviors and invocation style needs to
>> follow all the other 'bdist' command types.
>> And that means being able to invoke it the same as say 'bdist_rpm' like:
>>
>> python setup.py bdist_deb
>> or
>> python setup.py bdist_deb --<std bdist type arg> ...
>>
>> If we start allowing 'bdist' derivative commands to diverge in their
>> inherited capabilities, invocation style, and expected behaviors then
>> chaos will ensue.
>>     
> This does have the same invocation style -- if you change your setup.py
> to import stdeb. Otherwise, it's still the same invocation style -- you
> just have to import stdeb outside the setup.py file.
>
> Also, this version of bdist_deb is never going to make it into the
> standard library as it depends on stdeb.
>
> So feel free to make a counter proposal, but I'm inclined to think this
> is useful to people as-is and has the benefit of working today.
>
>   
My view is this.  The 'bdist' family of commands should be reserved for 
pure Distutils implementations not dependent upon setuptools or stdeb.  
Putting a command to create the .deb based on my code into stdeb is fine 
but that command should not be a 'bdist_xxx' command.  It should be 
somthing like bstdeb_deb so that a true 'bdist_deb' can still be 
developed for Distutils and not be in conflict with some other 
'bdist_deb' out there.

At some point, the 'bdist' family of commands should evolve into 
OS-specific varieties.  And this means that for example, redhat, fedora, 
mandriva, or any other rpm-package distro would have their own 
'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then 
institute their own rules/policies onto a generic 'bdist_rpm'.  And the 
same would hold true for example a 'bdist_ubuntu' command that would 
inherit from a 'bdist_deb' command or in general for any 'bdist_DISTRO' 
command that would inherit from a 'bdist_PACKAGETOOL' command.

Maybe we can get some overall guidance here from Tarek who has been 
coordinating a lot of these types of things.


Regards,
Gerry


From alex.gronholm at nextday.fi  Wed Sep 23 22:19:06 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 23 Sep 2009 23:19:06 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <4ABA82BA.6030902@nextday.fi>

Tarek Ziad? kirjoitti:
> Hello,
>
> The next Distribute version will be released soon, with python 3
> support (thanks to Martin, Lennart, and Alex !)
> and more bug fixed. (you can follow that in the issue tracker)
>
> If you want to give a hand on testing the next Distribute version,
> I've uploaded a dev version of the trunk of Distribute at
> nightly.ziade.org, meaning that you can try the upcoming release
> (at your own risks ;) )
>
> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
> - a modified distribute_setup.py script that will install the dev
> version : http://nightly.ziade.org/distribute_setup_dev.py
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>
> Any feedback would be greatly appreciated,
>
> Regards,
> Tarek
>
>   
Successfully tested installing distribute on 32-bit WinXP, on Python 
3.1.1. Tried easy_install too, works fine.
Regarding the failure with 64-bit Win7, I uninstalled the 64-bit Python 
and then installed the 32-bit version, and now easy_install works just 
fine. I think there ought to be 64-bit stubs too -- I don't know how 
else to explain the problems with the 64-bit Python.


From strawman at astraw.com  Wed Sep 23 22:51:40 2009
From: strawman at astraw.com (Andrew Straw)
Date: Wed, 23 Sep 2009 13:51:40 -0700
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABA637E.1080804@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net> <4ABA4D5E.4080008@astraw.com>
	<4ABA637E.1080804@verizon.net>
Message-ID: <4ABA8A5C.7050007@astraw.com>


>>>> OK, based on your code I added a "bdist_deb" distutils command to
>>>> stdeb.
>>>> I've checked this into the old-stable branch and I'd appreciate it if
>>>> you can check whether this works for you and send me any comments.
>>>> Invoke it like this:
>>>>
>>>> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>>>         
>>> See this was my point of why my 'bdist_deb' belonged as a distutils
>>> patch and not in stdeb.
>>> The inherited capabilities, behaviors and invocation style needs to
>>> follow all the other 'bdist' command types.
>>> And that means being able to invoke it the same as say 'bdist_rpm'
>>> like:
>>>
>>> python setup.py bdist_deb
>>> or
>>> python setup.py bdist_deb --<std bdist type arg> ...
>>>
>>> If we start allowing 'bdist' derivative commands to diverge in their
>>> inherited capabilities, invocation style, and expected behaviors then
>>> chaos will ensue.
>>>     
>> This does have the same invocation style -- if you change your setup.py
>> to import stdeb. Otherwise, it's still the same invocation style -- you
>> just have to import stdeb outside the setup.py file.
>>
>> Also, this version of bdist_deb is never going to make it into the
>> standard library as it depends on stdeb.
>>
>> So feel free to make a counter proposal, but I'm inclined to think this
>> is useful to people as-is and has the benefit of working today.
>>
>>   
> My view is this.  The 'bdist' family of commands should be reserved
> for pure Distutils implementations not dependent upon setuptools or
> stdeb.  Putting a command to create the .deb based on my code into
> stdeb is fine but that command should not be a 'bdist_xxx' command. 
> It should be somthing like bstdeb_deb so that a true 'bdist_deb' can
> still be developed for Distutils and not be in conflict with some
> other 'bdist_deb' out there.

Well, it wouldn't be setting a precedent that importing a module would
extend the functionality of the stdlib's distutils commands -- the
setuptools and distribute projects already do this. For example, the
"sdist" command in setuptools has many differences with that of "sdist"
in plain distutils. The point is that a user can choose not to import
setuptools and thus not get the different behavior.

The case here is that if the stdlib ever grows bdist_deb, that's fine,
but I don't see why that should prevent stdeb from implementing a
bdist_deb command of its own. In this case, I think the issue is even
less relevant, since there is no stdlib "bdist_deb" command. Users would
naturally expect "bdist_deb" to do exactly what stdeb is implementing.
As long as I'm going ahead an implementing the functionality (which I'm
ambivalent about in and of itself for previously stated reasons), I
think it should be named the most obvious name.

> At some point, the 'bdist' family of commands should evolve into
> OS-specific varieties.  And this means that for example, redhat,
> fedora, mandriva, or any other rpm-package distro would have their own
> 'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
> institute their own rules/policies onto a generic 'bdist_rpm'.  And
> the same would hold true for example a 'bdist_ubuntu' command that
> would inherit from a 'bdist_deb' command or in general for any
> 'bdist_DISTRO' command that would inherit from a 'bdist_PACKAGETOOL'
> command.

I don't see what's so specific about ubuntu versus debian right now that
there's any reason for a different set of commands for the two.
Therefore, I think this is a red herring w.r.t. the present discussion.

> Maybe we can get some overall guidance here from Tarek who has been
> coordinating a lot of these types of things. 

Sure. CCed.

-Andrew

From greno at verizon.net  Thu Sep 24 01:23:57 2009
From: greno at verizon.net (Gerry Reno)
Date: Wed, 23 Sep 2009 19:23:57 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABA8A5C.7050007@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB315CE.6060104@astraw.com>
	<4AB48146.8090606@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net> <4ABA4D5E.4080008@astraw.com>
	<4ABA637E.1080804@verizon.net> <4ABA8A5C.7050007@astraw.com>
Message-ID: <4ABAAE0D.7050302@verizon.net>

Andrew Straw wrote:
>>>>> OK, based on your code I added a "bdist_deb" distutils command to
>>>>> stdeb.
>>>>> I've checked this into the old-stable branch and I'd appreciate it if
>>>>> you can check whether this works for you and send me any comments.
>>>>> Invoke it like this:
>>>>>
>>>>> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>>>>         
>>>>>           
>>>> See this was my point of why my 'bdist_deb' belonged as a distutils
>>>> patch and not in stdeb.
>>>> The inherited capabilities, behaviors and invocation style needs to
>>>> follow all the other 'bdist' command types.
>>>> And that means being able to invoke it the same as say 'bdist_rpm'
>>>> like:
>>>>
>>>> python setup.py bdist_deb
>>>> or
>>>> python setup.py bdist_deb --<std bdist type arg> ...
>>>>
>>>> If we start allowing 'bdist' derivative commands to diverge in their
>>>> inherited capabilities, invocation style, and expected behaviors then
>>>> chaos will ensue.
>>>>     
>>>>         
>>> This does have the same invocation style -- if you change your setup.py
>>> to import stdeb. Otherwise, it's still the same invocation style -- you
>>> just have to import stdeb outside the setup.py file.
>>>
>>> Also, this version of bdist_deb is never going to make it into the
>>> standard library as it depends on stdeb.
>>>
>>> So feel free to make a counter proposal, but I'm inclined to think this
>>> is useful to people as-is and has the benefit of working today.
>>>
>>>   
>>>       
>> My view is this.  The 'bdist' family of commands should be reserved
>> for pure Distutils implementations not dependent upon setuptools or
>> stdeb.  Putting a command to create the .deb based on my code into
>> stdeb is fine but that command should not be a 'bdist_xxx' command. 
>> It should be somthing like bstdeb_deb so that a true 'bdist_deb' can
>> still be developed for Distutils and not be in conflict with some
>> other 'bdist_deb' out there.
>>     
>
> Well, it wouldn't be setting a precedent that importing a module would
> extend the functionality of the stdlib's distutils commands -- the
> setuptools and distribute projects already do this. For example, the
> "sdist" command in setuptools has many differences with that of "sdist"
> in plain distutils. The point is that a user can choose not to import
> setuptools and thus not get the different behavior.
>
> The case here is that if the stdlib ever grows bdist_deb, that's fine,
> but I don't see why that should prevent stdeb from implementing a
> bdist_deb command of its own. In this case, I think the issue is even
> less relevant, since there is no stdlib "bdist_deb" command. Users would
> naturally expect "bdist_deb" to do exactly what stdeb is implementing.
> As long as I'm going ahead an implementing the functionality (which I'm
> ambivalent about in and of itself for previously stated reasons), I
> think it should be named the most obvious name.
>   
My only concern is that namespaces are important and if we end up with 
two solution paths that each use the same namespace then this becomes 
very confusing for users.  Yes, I understand that if you don't import 
stdeb in your setup.py then you can use a 'bdist_deb' from Distutils.


>   
>> At some point, the 'bdist' family of commands should evolve into
>> OS-specific varieties.  And this means that for example, redhat,
>> fedora, mandriva, or any other rpm-package distro would have their own
>> 'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
>> institute their own rules/policies onto a generic 'bdist_rpm'.  And
>> the same would hold true for example a 'bdist_ubuntu' command that
>> would inherit from a 'bdist_deb' command or in general for any
>> 'bdist_DISTRO' command that would inherit from a 'bdist_PACKAGETOOL'
>> command.
>>     
>
> I don't see what's so specific about ubuntu versus debian right now that
> there's any reason for a different set of commands for the two.
> Therefore, I think this is a red herring w.r.t. the present discussion.
>   
For ubuntu, at the moment at least, that's true.  But distros like 
redhat are creating their own rules/policies around rpm naming 
conventions, build options, etc. and of course they should be able to do 
this and I expect other distros will do the same, and these will diverge 
more over time even though they will all use the same packaging tool 
underneath.

>   
>> Maybe we can get some overall guidance here from Tarek who has been
>> coordinating a lot of these types of things. 
>>     
I think this is a good topic for someone with a long view about where 
things are headed here to weigh in on this.
I'm fine with whatever fits in with the longer term goals.


Regards,
Gerry


From greno at verizon.net  Thu Sep 24 03:53:13 2009
From: greno at verizon.net (Gerry Reno)
Date: Wed, 23 Sep 2009 21:53:13 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABAAE0D.7050302@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB48146.8090606@verizon.net>
	<4AB5A059.9060701@verizon.net> <4AB5B927.2050905@verizon.net>
	<4AB659C6.4070203@verizon.net> <4AB66020.10408@astraw.com>
	<4AB66461.1020007@verizon.net> <4AB67169.9080006@astraw.com>
	<4AB678DD.4060807@verizon.net> <4AB68884.1090905@astraw.com>
	<4AB696B7.9040705@verizon.net> <4AB6AE16.9030505@verizon.net>
	<4AB6B2CC.1090400@astraw.com> <4AB6B601.8050404@verizon.net>
	<4AB6C59F.209@astraw.com> <4AB6D4E6.5030402@verizon.net>
	<4AB6E9A0.80708@astraw.com> <4AB70C58.5010206@verizon.net>
	<4AB7141D.9040702@astraw.com> <4AB7D0F6.60502@verizon.net>
	<4AB7D3B8.7010109@astraw.com> <4AB7DD39.1060506@verizon.net>
	<4AB7F5D7.9020002@verizon.net> <4AB90B96.8090802@astraw.com>
	<4AB91003.5090507@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com> <4ABAAE0D.7050302@verizon.net>
Message-ID: <4ABAD109.4050409@verizon.net>

Andrew,
Here's another patch attempt. Is this what you had in mind?

Regards,
Gerry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: util.py.diff
Type: text/x-patch
Size: 667 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090923/7e84e9b7/attachment.bin>

From ziade.tarek at gmail.com  Thu Sep 24 13:19:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 24 Sep 2009 13:19:08 +0200
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABA8A5C.7050007@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net> <4ABA4D5E.4080008@astraw.com>
	<4ABA637E.1080804@verizon.net> <4ABA8A5C.7050007@astraw.com>
Message-ID: <94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>

2009/9/23 Andrew Straw <strawman at astraw.com>:
>
> Well, it wouldn't be setting a precedent that importing a module would
> extend the functionality of the stdlib's distutils commands -- the
> setuptools and distribute projects already do this. For example, the
> "sdist" command in setuptools has many differences with that of "sdist"
> in plain distutils. The point is that a user can choose not to import
> setuptools and thus not get the different behavior.
>
> The case here is that if the stdlib ever grows bdist_deb, that's fine,
> but I don't see why that should prevent stdeb from implementing a
> bdist_deb command of its own. In this case, I think the issue is even
> less relevant, since there is no stdlib "bdist_deb" command. Users would
> naturally expect "bdist_deb" to do exactly what stdeb is implementing.
> As long as I'm going ahead an implementing the functionality (which I'm
> ambivalent about in and of itself for previously stated reasons), I
> think it should be named the most obvious name.
>

During last Pycon summit, we v'e said that part of the problem with Distutils
was that it was doing too much things and that we should probably try to
remove all platform-specific commands to reduce its scope.

For instance, bdist_rpm is fine, but being located in Python stdlib, its release
cycle is too long, and it would probably be better for it to be on its own,
managed by people from the "rpm community" (if this term makes sense,
e.g. Fedora
guys maybe ?)

Same thing goes with bdist_deb : while it's more controversial to
remove existing bdist_*
command, we will not include new bdist_* commands for sure in Distutils,
and rather let the debian/ubuntu community provide the best packaging
solution on the top of Distutils.

That said, if stdeb provides a plain Distutils command, that doesn't
use Setuptools
and if that command is stable and used in the community, we will be happy to
add a pointer to it in Distutils documentation.

The problem of using Setuptools or Distribute in a command is that it
does a lot of patching
(much more that overriding distutils sdist command) and that changes
Distutils global
behavior. Notice that the Distribute project plans to remove that
patching in the future.

Notice also that Distutils has a plugin system, where you can point a
package that
contains extra commands. This configuration can be done in distutils.cfg.

This allows the usage of the command in the CLI without having to
import the command
directly in the setup.py file.

Last, about the name, I think using "bdist_deb" is fine imho. If
another project uses the same
name, it's juste a matter of configuring the one to be used in a given context.

Regards
Tarek

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

From alex.gronholm at nextday.fi  Thu Sep 24 18:25:00 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Thu, 24 Sep 2009 19:25:00 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
Message-ID: <4ABB9D5C.60005@nextday.fi>

Tarek Ziad? kirjoitti:
> Hello,
>
> The next Distribute version will be released soon, with python 3
> support (thanks to Martin, Lennart, and Alex !)
> and more bug fixed. (you can follow that in the issue tracker)
>
> If you want to give a hand on testing the next Distribute version,
> I've uploaded a dev version of the trunk of Distribute at
> nightly.ziade.org, meaning that you can try the upcoming release
> (at your own risks ;) )
>
> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
> - a modified distribute_setup.py script that will install the dev
> version : http://nightly.ziade.org/distribute_setup_dev.py
> - a modified bootstrap.py file that will let you bootstrap a
> zc.buildout environment with this version
>
> Any feedback would be greatly appreciated,
>
> Regards,
> Tarek
>
>   
Do you know anyone who could fix the 64-bit Windows issue before the 
0.6.2 release? While I know C, I've never done Windows programming.

From greno at verizon.net  Thu Sep 24 18:44:36 2009
From: greno at verizon.net (Gerry Reno)
Date: Thu, 24 Sep 2009 12:44:36 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net> <4ABA4D5E.4080008@astraw.com>
	<4ABA637E.1080804@verizon.net> <4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
Message-ID: <4ABBA1F4.9030402@verizon.net>

Tarek Ziad? wrote:
> 2009/9/23 Andrew Straw <strawman at astraw.com>:
>   
>> Well, it wouldn't be setting a precedent that importing a module would
>> extend the functionality of the stdlib's distutils commands -- the
>> setuptools and distribute projects already do this. For example, the
>> "sdist" command in setuptools has many differences with that of "sdist"
>> in plain distutils. The point is that a user can choose not to import
>> setuptools and thus not get the different behavior.
>>
>> The case here is that if the stdlib ever grows bdist_deb, that's fine,
>> but I don't see why that should prevent stdeb from implementing a
>> bdist_deb command of its own. In this case, I think the issue is even
>> less relevant, since there is no stdlib "bdist_deb" command. Users would
>> naturally expect "bdist_deb" to do exactly what stdeb is implementing.
>> As long as I'm going ahead an implementing the functionality (which I'm
>> ambivalent about in and of itself for previously stated reasons), I
>> think it should be named the most obvious name.
>>
>>     
>
> During last Pycon summit, we v'e said that part of the problem with Distutils
> was that it was doing too much things and that we should probably try to
> remove all platform-specific commands to reduce its scope.
>
> For instance, bdist_rpm is fine, but being located in Python stdlib, its release
> cycle is too long, and it would probably be better for it to be on its own,
> managed by people from the "rpm community" (if this term makes sense,
> e.g. Fedora
> guys maybe ?)
>
> Same thing goes with bdist_deb : while it's more controversial to
> remove existing bdist_*
> command, we will not include new bdist_* commands for sure in Distutils,
> and rather let the debian/ubuntu community provide the best packaging
> solution on the top of Distutils.
>
> That said, if stdeb provides a plain Distutils command, that doesn't
> use Setuptools
> and if that command is stable and used in the community, we will be happy to
> add a pointer to it in Distutils documentation.
>
> The problem of using Setuptools or Distribute in a command is that it
> does a lot of patching
> (much more that overriding distutils sdist command) and that changes
> Distutils global
> behavior. Notice that the Distribute project plans to remove that
> patching in the future.
>
> Notice also that Distutils has a plugin system, where you can point a
> package that
> contains extra commands. This configuration can be done in distutils.cfg.
>
> This allows the usage of the command in the CLI without having to
> import the command
> directly in the setup.py file.
>
> Last, about the name, I think using "bdist_deb" is fine imho. If
> another project uses the same
> name, it's juste a matter of configuring the one to be used in a given context.
>
> Regards
> Tarek
>   
So are you saying then that a stddeb-based 'bdist_deb' should be 
implemented as a standalone plugin to Distribute?  And how would that 
work for distros such as Ubuntu 8.0.4 Hardy?  Would they be able to take 
advantage of Distribute?

Regards,
Gerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090924/9ccf40dc/attachment.htm>

From eric at trueblade.com  Thu Sep 24 18:50:13 2009
From: eric at trueblade.com (Eric Smith)
Date: Thu, 24 Sep 2009 12:50:13 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABBA1F4.9030402@verizon.net>
References: <4AB30240.8020807@verizon.net>
	<4AB7F5D7.9020002@verizon.net>	<4AB90B96.8090802@astraw.com>
	<4AB91003.5090507@verizon.net>	<4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com>	<4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com>	<4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net>
Message-ID: <4ABBA345.4040906@trueblade.com>

Gerry Reno wrote:
> Tarek Ziad? wrote:
>> 2009/9/23 Andrew Straw <strawman at astraw.com>:
>>   
>>> Well, it wouldn't be setting a precedent that importing a module would
>>> extend the functionality of the stdlib's distutils commands -- the
>>> setuptools and distribute projects already do this. For example, the
>>> "sdist" command in setuptools has many differences with that of "sdist"
>>> in plain distutils. The point is that a user can choose not to import
>>> setuptools and thus not get the different behavior.
>>>
>>> The case here is that if the stdlib ever grows bdist_deb, that's fine,
>>> but I don't see why that should prevent stdeb from implementing a
>>> bdist_deb command of its own. In this case, I think the issue is even
>>> less relevant, since there is no stdlib "bdist_deb" command. Users would
>>> naturally expect "bdist_deb" to do exactly what stdeb is implementing.
>>> As long as I'm going ahead an implementing the functionality (which I'm
>>> ambivalent about in and of itself for previously stated reasons), I
>>> think it should be named the most obvious name.
>>>
>>>     
>>
>> During last Pycon summit, we v'e said that part of the problem with Distutils
>> was that it was doing too much things and that we should probably try to
>> remove all platform-specific commands to reduce its scope.
>>
>> For instance, bdist_rpm is fine, but being located in Python stdlib, its release
>> cycle is too long, and it would probably be better for it to be on its own,
>> managed by people from the "rpm community" (if this term makes sense,
>> e.g. Fedora
>> guys maybe ?)
>>
>> Same thing goes with bdist_deb : while it's more controversial to
>> remove existing bdist_*
>> command, we will not include new bdist_* commands for sure in Distutils,
>> and rather let the debian/ubuntu community provide the best packaging
>> solution on the top of Distutils.
>>
>> That said, if stdeb provides a plain Distutils command, that doesn't
>> use Setuptools
>> and if that command is stable and used in the community, we will be happy to
>> add a pointer to it in Distutils documentation.
>>
>> The problem of using Setuptools or Distribute in a command is that it
>> does a lot of patching
>> (much more that overriding distutils sdist command) and that changes
>> Distutils global
>> behavior. Notice that the Distribute project plans to remove that
>> patching in the future.
>>
>> Notice also that Distutils has a plugin system, where you can point a
>> package that
>> contains extra commands. This configuration can be done in distutils.cfg.
>>
>> This allows the usage of the command in the CLI without having to
>> import the command
>> directly in the setup.py file.
>>
>> Last, about the name, I think using "bdist_deb" is fine imho. If
>> another project uses the same
>> name, it's juste a matter of configuring the one to be used in a given context.
>>
>> Regards
>> Tarek
>>   
> So are you saying then that a stddeb-based 'bdist_deb' should be 
> implemented as a standalone plugin to Distribute?  And how would that 
> work for distros such as Ubuntu 8.0.4 Hardy?  Would they be able to take 
> advantage of Distribute?

I think a long term goal should be getting away from the plugin nature 
of distutils. I don't see why distutils (or my mythical distlib) 
shouldn't just be a package (or more likely multiple packages) that 
stand-alone tools can use. Other than much complexity and confusion, I 
don't see what plugins have bought us. Not everything (and especially 
not distutils) needs to be a framework.

I'll admit that this plan in years down the road, at best. And it's not 
anyone's official position.

Eric.

From tseaver at palladion.com  Thu Sep 24 19:22:17 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 24 Sep 2009 13:22:17 -0400
Subject: [Distutils] [buildout] is there a way to force re-install of a
	part?
In-Reply-To: <4ABA0F80.4010705@simplistix.co.uk>
References: <4ABA0F80.4010705@simplistix.co.uk>
Message-ID: <h9g9sb$6e3$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Withers wrote:
> Hi All,
> 
> Is there any way to force a part to re-install?
> 
> I have a part using the djangorecipe part that stubbornly refuses to 
> notice that I've changed an eggs dependencies or changed the stuff in 
> the develop line of the [buildout] section.
> 
> I've tried "bin/buildout install djangopart" but this doesn't have any 
> effect. The only way I've found to get the part to re-install is to 
> change the options in the part, install, and then put the options back 
> like I want them before re-installing :-(

 $ rm -rf parts/djangopart; bin/buildout


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKu6rJ+gerLs4ltQ4RAoIOAJ9BbsGI1TIxY9RsxxbYwKT7sw4umQCbB7yC
Icj0ST7L6H/4ZWMMUUiws0I=
=Q3kU
-----END PGP SIGNATURE-----


From ziade.tarek at gmail.com  Thu Sep 24 19:08:15 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 24 Sep 2009 19:08:15 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4ABB9D5C.60005@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4ABB9D5C.60005@nextday.fi>
Message-ID: <94bdd2610909241008n62f5f206g3da13a055f9a8c83@mail.gmail.com>

2009/9/24 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> Tarek Ziad? kirjoitti:
>>
>> Hello,
>>
>> The next Distribute version will be released soon, with python 3
>> support (thanks to Martin, Lennart, and Alex !)
>> and more bug fixed. (you can follow that in the issue tracker)
>>
>> If you want to give a hand on testing the next Distribute version,
>> I've uploaded a dev version of the trunk of Distribute at
>> nightly.ziade.org, meaning that you can try the upcoming release
>> (at your own risks ;) )
>>
>> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
>> - a modified distribute_setup.py script that will install the dev
>> version : http://nightly.ziade.org/distribute_setup_dev.py
>> - a modified bootstrap.py file that will let you bootstrap a
>> zc.buildout environment with this version
>>
>> Any feedback would be greatly appreciated,
>>
>> Regards,
>> Tarek
>>
>>
>
> Do you know anyone who could fix the 64-bit Windows issue before the 0.6.2
> release? While I know C, I've never done Windows programming.

IIRC this is a long-dated setuptools bug, and related to the .exe
files in teh package,
that are 32bts only

I'll need to dig on this

Tarek

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

From ziade.tarek at gmail.com  Thu Sep 24 19:21:14 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 24 Sep 2009 19:21:14 +0200
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <4ABBA345.4040906@trueblade.com>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
Message-ID: <94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>

Gerry:
>> So are you saying then that a stddeb-based 'bdist_deb' should be
>> implemented as a standalone plugin to Distribute? ?And how would that work
>> for distros such as Ubuntu 8.0.4 Hardy? ?Would they be able to take
>> advantage of Distribute?

Yes, it's just a matter of packaging this command in a standalone distribution.
Once it's installed, and distutils.cfg properly configured, it can be
used as a plugin.

Distribute is not yet a good citizen for being used in such packages,
because it still
patches distutils like setuptools does.

Eric:
> I think a long term goal should be getting away from the plugin nature of
> distutils. I don't see why distutils (or my mythical distlib) shouldn't just
> be a package (or more likely multiple packages) that stand-alone tools can
> use. Other than much complexity and confusion, I don't see what plugins have
> bought us. Not everything (and especially not distutils) needs to be a
> framework.

It's just a matter of defining *where* is the CLI and how it works.
The plugin system here is just to make those commands reachable from
distutils's
setup.py machinery. If another package has its own CLI, it can ignore
this plugin system I guess.

>
> I'll admit that this plan in years down the road, at best. And it's not
> anyone's official position.
>

Agreed, we need to think about alternatives.

but in any case, nowadays, if the stdeb project wrap its work in a
bdist_deb command that can
be used as a distutils plugin, I don't think it's a problem for the future.

I would be pretty happy about it :)

Tarek

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

From greno at verizon.net  Thu Sep 24 22:33:15 2009
From: greno at verizon.net (Gerry Reno)
Date: Thu, 24 Sep 2009 16:33:15 -0400
Subject: [Distutils] stdeb-0.3 error
In-Reply-To: <94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
Message-ID: <4ABBD78B.4030902@verizon.net>

Tarek Ziad? wrote:
> Gerry:
>   
>>> So are you saying then that a stddeb-based 'bdist_deb' should be
>>> implemented as a standalone plugin to Distribute?  And how would that work
>>> for distros such as Ubuntu 8.0.4 Hardy?  Would they be able to take
>>> advantage of Distribute?
>>>       
>
> Yes, it's just a matter of packaging this command in a standalone distribution.
> Once it's installed, and distutils.cfg properly configured, it can be
> used as a plugin.
>
> Distribute is not yet a good citizen for being used in such packages,
> because it still
> patches distutils like setuptools does.
>
> Eric:
>   
>> I think a long term goal should be getting away from the plugin nature of
>> distutils. I don't see why distutils (or my mythical distlib) shouldn't just
>> be a package (or more likely multiple packages) that stand-alone tools can
>> use. Other than much complexity and confusion, I don't see what plugins have
>> bought us. Not everything (and especially not distutils) needs to be a
>> framework.
>>     
>
> It's just a matter of defining *where* is the CLI and how it works.
> The plugin system here is just to make those commands reachable from
> distutils's
> setup.py machinery. If another package has its own CLI, it can ignore
> this plugin system I guess.
>
>   
>> I'll admit that this plan in years down the road, at best. And it's not
>> anyone's official position.
>>
>>     
>
> Agreed, we need to think about alternatives.
>
> but in any case, nowadays, if the stdeb project wrap its work in a
> bdist_deb command that can
> be used as a distutils plugin, I don't think it's a problem for the future.
>
> I would be pretty happy about it :)
>
> Tarek
>
>   

Then I'm ok then with having 'bdist_deb' be the name and using the 
plugin approach.

Andrew, what do you think about this solution?


Regards,
Gerry


From strawman at astraw.com  Thu Sep 24 23:37:23 2009
From: strawman at astraw.com (Andrew Straw)
Date: Thu, 24 Sep 2009 14:37:23 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4ABBD78B.4030902@verizon.net>
References: <4AB30240.8020807@verizon.net>
	<4AB923A7.7060006@verizon.net>	<4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net>	<4ABA4D5E.4080008@astraw.com>
	<4ABA637E.1080804@verizon.net>	<4ABA8A5C.7050007@astraw.com>	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>	<4ABBA1F4.9030402@verizon.net>
	<4ABBA345.4040906@trueblade.com>	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net>
Message-ID: <4ABBE693.6050300@astraw.com>

Gerry Reno wrote:
> Then I'm ok then with having 'bdist_deb' be the name and using the
> plugin approach.
>
> Andrew, what do you think about this solution?
It's already committed as of a couple days ago in the "old-stable"
branch and I just merged it into the master branch.

I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the master
branch) with this soon.

-Andrew

From strawman at astraw.com  Thu Sep 24 23:44:10 2009
From: strawman at astraw.com (Andrew Straw)
Date: Thu, 24 Sep 2009 14:44:10 -0700
Subject: [Distutils] disabling --single-version-externally-managed in stdeb
	0.3.x
In-Reply-To: <4ABAD109.4050409@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB5A059.9060701@verizon.net>
	<4AB5B927.2050905@verizon.net> <4AB659C6.4070203@verizon.net>
	<4AB66020.10408@astraw.com> <4AB66461.1020007@verizon.net>
	<4AB67169.9080006@astraw.com> <4AB678DD.4060807@verizon.net>
	<4AB68884.1090905@astraw.com> <4AB696B7.9040705@verizon.net>
	<4AB6AE16.9030505@verizon.net> <4AB6B2CC.1090400@astraw.com>
	<4AB6B601.8050404@verizon.net> <4AB6C59F.209@astraw.com>
	<4AB6D4E6.5030402@verizon.net> <4AB6E9A0.80708@astraw.com>
	<4AB70C58.5010206@verizon.net> <4AB7141D.9040702@astraw.com>
	<4AB7D0F6.60502@verizon.net> <4AB7D3B8.7010109@astraw.com>
	<4AB7DD39.1060506@verizon.net> <4AB7F5D7.9020002@verizon.net>
	<4AB90B96.8090802@astraw.com> <4AB91003.5090507@verizon.net>
	<4AB923A7.7060006@verizon.net> <4AB9C932.2070907@astraw.com>
	<4ABA421C.7000405@verizon.net> <4ABA4D5E.4080008@astraw.com>
	<4ABA637E.1080804@verizon.net> <4ABA8A5C.7050007@astraw.com>
	<4ABAAE0D.7050302@verizon.net> <4ABAD109.4050409@verizon.net>
Message-ID: <4ABBE82A.50306@astraw.com>

Gerry Reno wrote:
> Andrew,
> Here's another patch attempt. Is this what you had in mind?
>
> Regards,
> Gerry
OK, I looked at this, and now I'm throughly confused by what you are
trying to do. Back to your big picture, as I understood it, you were
trying to avoid importing setuptools because you derive some distutils
commands and you don't want to derive from the setuptools versions. And
the --single-version-externally-managed was giving you problems because
that's not supported by distutils.

But A) I can't see how this patch would address the issue of setuptools
not being imported, because that still happens. And B) the patch as you
sent it was incomplete, requiring more work on my part even to be able
to get it to run without raising exceptions. So I'm not sure that I
actually "get" what your patch does here. I attempted to do my best and
have now started a branch for this patch and subsequent efforts. See
http://github.com/astraw/stdeb/tree/gerry-reno . My testing on this
issue has been based on the version in this branch. Please either submit
any patches off the old-stable branch or extending this gerry-reno branch.

-Andrew

From alex.gronholm at nextday.fi  Thu Sep 24 23:55:07 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Fri, 25 Sep 2009 00:55:07 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909241008n62f5f206g3da13a055f9a8c83@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4ABB9D5C.60005@nextday.fi>
	<94bdd2610909241008n62f5f206g3da13a055f9a8c83@mail.gmail.com>
Message-ID: <4ABBEABB.60208@nextday.fi>

Tarek Ziad? kirjoitti:
> 2009/9/24 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Tarek Ziad? kirjoitti:
>>     
>>> Hello,
>>>
>>> The next Distribute version will be released soon, with python 3
>>> support (thanks to Martin, Lennart, and Alex !)
>>> and more bug fixed. (you can follow that in the issue tracker)
>>>
>>> If you want to give a hand on testing the next Distribute version,
>>> I've uploaded a dev version of the trunk of Distribute at
>>> nightly.ziade.org, meaning that you can try the upcoming release
>>> (at your own risks ;) )
>>>
>>> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
>>> - a modified distribute_setup.py script that will install the dev
>>> version : http://nightly.ziade.org/distribute_setup_dev.py
>>> - a modified bootstrap.py file that will let you bootstrap a
>>> zc.buildout environment with this version
>>>
>>> Any feedback would be greatly appreciated,
>>>
>>> Regards,
>>> Tarek
>>>
>>>
>>>       
>> Do you know anyone who could fix the 64-bit Windows issue before the 0.6.2
>> release? While I know C, I've never done Windows programming.
>>     
>
> IIRC this is a long-dated setuptools bug, and related to the .exe
> files in teh package,
> that are 32bts only
>
> I'll need to dig on this
>
> Tarek
>
>   
There is a mingw-w64 package on sourceforge. Maybe this could help?
http://sourceforge.net/projects/mingw-w64/

From greno at verizon.net  Fri Sep 25 00:11:15 2009
From: greno at verizon.net (Gerry Reno)
Date: Thu, 24 Sep 2009 18:11:15 -0400
Subject: [Distutils] disabling --single-version-externally-managed in
	stdeb 0.3.x
In-Reply-To: <4ABBE82A.50306@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB5B927.2050905@verizon.net>
	<4AB659C6.4070203@verizon.net> <4AB66020.10408@astraw.com>
	<4AB66461.1020007@verizon.net> <4AB67169.9080006@astraw.com>
	<4AB678DD.4060807@verizon.net> <4AB68884.1090905@astraw.com>
	<4AB696B7.9040705@verizon.net> <4AB6AE16.9030505@verizon.net>
	<4AB6B2CC.1090400@astraw.com> <4AB6B601.8050404@verizon.net>
	<4AB6C59F.209@astraw.com> <4AB6D4E6.5030402@verizon.net>
	<4AB6E9A0.80708@astraw.com> <4AB70C58.5010206@verizon.net>
	<4AB7141D.9040702@astraw.com> <4AB7D0F6.60502@verizon.net>
	<4AB7D3B8.7010109@astraw.com> <4AB7DD39.1060506@verizon.net>
	<4AB7F5D7.9020002@verizon.net> <4AB90B96.8090802@astraw.com>
	<4AB91003.5090507@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com> <4ABAAE0D.7050302@verizon.net>
	<4ABAD109.4050409@verizon.net> <4ABBE82A.50306@astraw.com>
Message-ID: <4ABBEE83.5080605@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew,
>> Here's another patch attempt. Is this what you had in mind?
>>
>> Regards,
>> Gerry
>>     
> OK, I looked at this, and now I'm throughly confused by what you are
> trying to do. Back to your big picture, as I understood it, you were
> trying to avoid importing setuptools because you derive some distutils
> commands and you don't want to derive from the setuptools versions. And
> the --single-version-externally-managed was giving you problems because
> that's not supported by distutils.
>
> But A) I can't see how this patch would address the issue of setuptools
> not being imported, because that still happens. 
Yes, inside the 'run' method within the 'bdist_deb' distutils command I 
had imported setuptools there but not at the top of setup.py.

> And B) the patch as you
> sent it was incomplete, requiring more work on my part even to be able
> to get it to run without raising exceptions. So I'm not sure that I
> actually "get" what your patch does here. I attempted to do my best and
> have now started a branch for this patch and subsequent efforts. See
> http://github.com/astraw/stdeb/tree/gerry-reno . My testing on this
> issue has been based on the version in this branch. Please either submit
> any patches off the old-stable branch or extending this gerry-reno branch.
>   
The patch looks for the option 
'--ignore-single-version-externally-managed' and then accordingly sets 
an env var that is used in the install line.

This looked like a reasonable way to control behavior inside the rules.  
That's why I was asking if that is what you had in mind.

I'll look at the branches and what needed to be added.

Regards,
Gerry


From olof.bjarnason at gmail.com  Fri Sep 25 10:23:58 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Fri, 25 Sep 2009 10:23:58 +0200
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
Message-ID: <c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>

Hi!

I'm new at the mailing list. I write small games in Python/PyGame. I
want to find a way to make a downloadable package/installer/script
to put on my webpage, especially for Ubuntu users.

I've skimmed a couple of tutorials on how to generate .deb-files, but,
wow, it's a whole new skill set to do that!

Does anyone have any hint on a more economic way of creating
single-file distribution packages for Python+PyGame projects? Maybe
some GUI-tool that automates the .deb file creation process, but
targetting Python specifically and not C++.

I've looked at Ubuntu's PPA system, didn't find it end-user-friendly enough.
Also, the Quickly project was too invasive on the way I like to develop
software (it took over the bzr/lp tools; I want to control that).

/Olof

From ben+python at benfinney.id.au  Fri Sep 25 10:52:18 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 25 Sep 2009 18:52:18 +1000
Subject: [Distutils] Distributing Python-programs to Ubuntu users
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
Message-ID: <87k4zn76f1.fsf@benfinney.id.au>

Thanks for moving the discussion to this forum, where it's better
suited. I'll reprise my existing reply again here for this new thread.

Olof Bjarnason <olof.bjarnason at gmail.com> writes:

> I'm new at the mailing list. I write small games in Python/PyGame. I
> want to find a way to make a downloadable package/installer/script to
> put on my webpage, especially for Ubuntu users.

The primary means of distributing your work to the outside world should,
first, be a working Distutils ?sdist? (?source distribution?). This
allows the work to be installed via ?python ./setup.py install?, with
installation options customisable by those users who want to do so.

An important set of users who might (read ?will?) want to customise
installation options is that set of users who can package your work for
specific distributions. They will take the Distutils configuration as a
starting point, and apply OS-specific packaging from that point.

You would do well to be familiar with the Filesystem Hierarchy Standard
<URL:http://www.pathname.com/fhs/> and specifications for desktop
applications <URL:http://www.freedesktop.org/wiki/Specifications> as
they apply to whatever programs you're making. Many aspects of these
(Especially of the FHS) are taken care of for you by the Distutils
infrastructure, but many are not.

> I've skimmed a couple of tutorials on how to generate .deb-files, but,
> wow, it's a whole new skill set to do that!

Right. It's a separate body of research, learning, and discipline to
make packages that operate smoothly on a particular operating system. If
you're not interested in that, please don't do a half-hearted job;
instead, focus on making a great program, and leave the job of making a
great package to someone better placed to do it.

> Does anyone have any hint on a more economic way of creating
> single-file distribution packages for Python+PyGame projects? Maybe
> some GUI-tool that automates the .deb file creation process, but
> targetting Python specifically and not C++.

Those tools that exist do more harm than good, in my opinion: they
either do very little to help, or they necessarily make guesses about
the right thing to do. The policies and specifications change from time
to time, and such automated tools cannot hope to be both comprehensive
and up-to-date.

As someone who has some familiarity with the OS packaging process, I
would beg you not to make OS-specific packages without a good, current
understanding of the OS packaging policy you're targeting. If that
doesn't sound like fun, just concentrate on making your program great,
standards-compliant, and responsive to bug reports ? especially from OS
package maintainers. That will make it much more attractive and give a
much better change of having a good range of OS-specific packages.

-- 
 \            ?Technology is neither good nor bad; nor is it neutral.? |
  `\                       ?Melvin Kranzberg's First Law of Technology |
_o__)                                                                  |
Ben Finney


From olof.bjarnason at gmail.com  Fri Sep 25 11:35:53 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Fri, 25 Sep 2009 11:35:53 +0200
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <87k4zn76f1.fsf@benfinney.id.au>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
	<87k4zn76f1.fsf@benfinney.id.au>
Message-ID: <c3dfe1d0909250235n7a936d66he456f697d36c8c22@mail.gmail.com>

2009/9/25 Ben Finney <ben+python at benfinney.id.au>:
> Thanks for moving the discussion to this forum, where it's better
> suited. I'll reprise my existing reply again here for this new thread.
>
> Olof Bjarnason <olof.bjarnason at gmail.com> writes:
>
>> I'm new at the mailing list. I write small games in Python/PyGame. I
>> want to find a way to make a downloadable package/installer/script to
>> put on my webpage, especially for Ubuntu users.
>
> The primary means of distributing your work to the outside world should,
> first, be a working Distutils ?sdist? (?source distribution?). This
> allows the work to be installed via ?python ./setup.py install?, with
> installation options customisable by those users who want to do so.
>
> An important set of users who might (read ?will?) want to customise
> installation options is that set of users who can package your work for
> specific distributions. They will take the Distutils configuration as a
> starting point, and apply OS-specific packaging from that point.
>
> You would do well to be familiar with the Filesystem Hierarchy Standard
> <URL:http://www.pathname.com/fhs/> and specifications for desktop
> applications <URL:http://www.freedesktop.org/wiki/Specifications> as
> they apply to whatever programs you're making. Many aspects of these
> (Especially of the FHS) are taken care of for you by the Distutils
> infrastructure, but many are not.
>
>> I've skimmed a couple of tutorials on how to generate .deb-files, but,
>> wow, it's a whole new skill set to do that!
>
> Right. It's a separate body of research, learning, and discipline to
> make packages that operate smoothly on a particular operating system. If
> you're not interested in that, please don't do a half-hearted job;
> instead, focus on making a great program, and leave the job of making a
> great package to someone better placed to do it.
>
>> Does anyone have any hint on a more economic way of creating
>> single-file distribution packages for Python+PyGame projects? Maybe
>> some GUI-tool that automates the .deb file creation process, but
>> targetting Python specifically and not C++.
>
> Those tools that exist do more harm than good, in my opinion: they
> either do very little to help, or they necessarily make guesses about
> the right thing to do. The policies and specifications change from time
> to time, and such automated tools cannot hope to be both comprehensive
> and up-to-date.
>
> As someone who has some familiarity with the OS packaging process, I
> would beg you not to make OS-specific packages without a good, current
> understanding of the OS packaging policy you're targeting. If that
> doesn't sound like fun, just concentrate on making your program great,
> standards-compliant, and responsive to bug reports ? especially from OS
> package maintainers. That will make it much more attractive and give a
> much better change of having a good range of OS-specific packages.

Thanks for you long and thourough answer Ben!

So your proposed course of action is

1) learn distutils + setup.py ecosystem
2) concentrate on application itself, not packaging
3) make some kind of fast-feedback system to achieve (2)

I can see a conflict between (3) and (2) - since packaging is not
under my control all feedback will be severely delayed, from users of
my app. What is a good approach to minimize time from release to
packaging?

I agree in general with your remarks, it's just that fast feedback is
one of the most important things to have for game (or any app for that
matter).

>
> --
> ?\ ? ? ? ? ? ??Technology is neither good nor bad; nor is it neutral.? |
> ?`\ ? ? ? ? ? ? ? ? ? ? ? ?Melvin Kranzberg's First Law of Technology |
> _o__) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> Ben Finney
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From floris.bruynooghe at gmail.com  Fri Sep 25 11:41:14 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Fri, 25 Sep 2009 10:41:14 +0100
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
Message-ID: <20090925094114.GA18653@laurie.devork>

On Fri, Sep 25, 2009 at 10:23:58AM +0200, Olof Bjarnason wrote:
> I'm new at the mailing list. I write small games in Python/PyGame. I
> want to find a way to make a downloadable package/installer/script
> to put on my webpage, especially for Ubuntu users.
> 
> I've skimmed a couple of tutorials on how to generate .deb-files, but,
> wow, it's a whole new skill set to do that!
> 
> Does anyone have any hint on a more economic way of creating
> single-file distribution packages for Python+PyGame projects? Maybe
> some GUI-tool that automates the .deb file creation process, but
> targetting Python specifically and not C++.

If your code (including dependencies) only uses pure-python you could
use the executable zipfile feature of Python 2.6 to simply ship an
executable that only needs Python.

$ cat > __main__.py
print('hi there')
^D
$ zip test.zip __main__.py
adding: __main__.py (stored 0%)
$ cat > hashbang.txt
#!/usr/bin/env python3.0
^D
$ cat hashbang.txt test.zip > my_exec
$ chmod +x my_exec
$ ./my_exec
hi there
$

Obviously you'd have to put all your the packages and modules you
depend on inside the zipfile.

This sort of sounds like what you are looking for.  It's not a
replacement for a properly shipped/distributed application but does a
good job if you just want to give your friends a small game to play.


Regards
Floris

PS: My search-foo must be low today as I couldn't find any official
documentation on this.  Any pointers?

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

From olof.bjarnason at gmail.com  Fri Sep 25 11:46:48 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Fri, 25 Sep 2009 11:46:48 +0200
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <20090925094114.GA18653@laurie.devork>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
	<20090925094114.GA18653@laurie.devork>
Message-ID: <c3dfe1d0909250246s7f6fe26au6978a1e47942afd1@mail.gmail.com>

2009/9/25 Floris Bruynooghe <floris.bruynooghe at gmail.com>:
> On Fri, Sep 25, 2009 at 10:23:58AM +0200, Olof Bjarnason wrote:
>> I'm new at the mailing list. I write small games in Python/PyGame. I
>> want to find a way to make a downloadable package/installer/script
>> to put on my webpage, especially for Ubuntu users.
>>
>> I've skimmed a couple of tutorials on how to generate .deb-files, but,
>> wow, it's a whole new skill set to do that!
>>
>> Does anyone have any hint on a more economic way of creating
>> single-file distribution packages for Python+PyGame projects? Maybe
>> some GUI-tool that automates the .deb file creation process, but
>> targetting Python specifically and not C++.
>
> If your code (including dependencies) only uses pure-python you could
> use the executable zipfile feature of Python 2.6 to simply ship an
> executable that only needs Python.

It's not only python, it's PyGame too.

>
> $ cat > __main__.py
> print('hi there')
> ^D
> $ zip test.zip __main__.py
> adding: __main__.py (stored 0%)
> $ cat > hashbang.txt
> #!/usr/bin/env python3.0
> ^D
> $ cat hashbang.txt test.zip > my_exec
> $ chmod +x my_exec
> $ ./my_exec
> hi there
> $
>
> Obviously you'd have to put all your the packages and modules you
> depend on inside the zipfile.
>
> This sort of sounds like what you are looking for. ?It's not a
> replacement for a properly shipped/distributed application but does a
> good job if you just want to give your friends a small game to play.
>
>
> Regards
> Floris
>
> PS: My search-foo must be low today as I couldn't find any official
> documentation on this. ?Any pointers?
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From ben+python at benfinney.id.au  Fri Sep 25 13:01:25 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 25 Sep 2009 21:01:25 +1000
Subject: [Distutils] Distributing Python-programs to Ubuntu users
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
	<87k4zn76f1.fsf@benfinney.id.au>
	<c3dfe1d0909250235n7a936d66he456f697d36c8c22@mail.gmail.com>
Message-ID: <87fxab70fu.fsf@benfinney.id.au>

Olof Bjarnason <olof.bjarnason at gmail.com> writes:

> So your proposed course of action is
>
> 1) learn distutils + setup.py ecosystem

Yes, this is essential. It's also, fortunately, not a very large topic
<URL:http://docs.python.org/distutils/>.

It is, unfortunately, rather flaky (you can read the archives of this
forum to see some of the hair-pulling it causes), and it gets more
complex in the non-core third-party extensions that have arisen to
address some of the Distutils shortcomings (see e.g. Setuptools), but
first things first: learn and use Distutils, the current standard
distribution system for Python software.

> 2) concentrate on application itself, not packaging

Yes. With a good program, distributed with the whole work under
widely-understood free software license terms (e.g. GNU GPL) and
published on PyPI <URL:http://pypi.python.org/pypi/> as an ?sdist?,
packagers will come to make OS-specific binary packages.

> 3) make some kind of fast-feedback system to achieve (2)
>
> I can see a conflict between (3) and (2) - since packaging is not
> under my control all feedback will be severely delayed, from users of
> my app. What is a good approach to minimize time from release to
> packaging?

The early adopters of your software will be those who are not afraid of
building it themselves from an ?sdist?. That population will be where
the OS-specific package maintainers will come from. So, be responsive to
your early adopters, and set up a distributed version control system and
bug tracking system (at e.g. Bitbucket or Launchpad you can have both in
the same place).

Those early adopters may well provide patches against your code (which
is why having a public distributed VCS is important), and will want to
be able to track their reported issues over time (which is why an
organised bug tracking system is important), as the issues are exposed
and dealt with.

If you continue to make releases that incorporate those changes that
make sense for distribution to all users, that seems the best fast
feedback. I don't see a conflict between your focus on being the core
developer of the actual work, and others's focus on the OS-specific
issues that arise. With each party focussing their attention where their
skills are, and with the appropriate workflow tools in place, it's about
as rapid as mere human programmers can hope for.

-- 
 \          ?All good things are cheap; all bad are very dear.? ?Henry |
  `\                                                     David Thoreau |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Fri Sep 25 15:35:39 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 25 Sep 2009 15:35:39 +0200
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <4ABA82BA.6030902@nextday.fi>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>
	<4ABA82BA.6030902@nextday.fi>
Message-ID: <94bdd2610909250635n343d5d23r30cadd7d76b0b258@mail.gmail.com>

2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> Tarek Ziad? kirjoitti:
>>
>> Hello,
>>
>> The next Distribute version will be released soon, with python 3
>> support (thanks to Martin, Lennart, and Alex !)
>> and more bug fixed. (you can follow that in the issue tracker)
>>
>> If you want to give a hand on testing the next Distribute version,
>> I've uploaded a dev version of the trunk of Distribute at
>> nightly.ziade.org, meaning that you can try the upcoming release
>> (at your own risks ;) )
>>
>> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
>> - a modified distribute_setup.py script that will install the dev
>> version : http://nightly.ziade.org/distribute_setup_dev.py
>> - a modified bootstrap.py file that will let you bootstrap a
>> zc.buildout environment with this version
>>
>> Any feedback would be greatly appreciated,
>>
>> Regards,
>> Tarek
>>
>>
>
> Successfully tested installing distribute on 32-bit WinXP, on Python 3.1.1.
> Tried easy_install too, works fine.
> Regarding the failure with 64-bit Win7, I uninstalled the 64-bit Python and
> then installed the 32-bit version, and now easy_install works just fine. I
> think there ought to be 64-bit stubs too -- I don't know how else to explain
> the problems with the 64-bit Python.
>

Could you check if your failure is one of those, please ?

- http://bugs.python.org/setuptools/issue2
- http://bugs.python.org/setuptools/issue3



Tarek

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

From astaley at berkeley.edu  Fri Sep 25 15:54:50 2009
From: astaley at berkeley.edu (Aaron Staley)
Date: Fri, 25 Sep 2009 06:54:50 -0700
Subject: [Distutils] Bug in setuptool's findall
Message-ID: <4ABCCBAA.2070604@picloud.net>

Hello,
    setuptools replaces distutl's findall() with:

    for base, dirs, files in os.walk(dir):
        print 'walk', base, dirs, files
        if base==os.curdir or base.startswith(os.curdir+os.sep):
            base = base[2:]
        if base:
            files = [os.path.join(base, f) for f in files]
        all_files.extend(filter(os.path.isfile, files))



This unfortunately will not follow directory symlinks (as followlinks is 
set to false in os.walk by default).  This is NOT the behavior of the 
original findall; oddly enough, the new findall actually produces bugs 
relative to distutil's.


-Aaron

From alex.gronholm at nextday.fi  Fri Sep 25 19:35:27 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Fri, 25 Sep 2009 20:35:27 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909250635n343d5d23r30cadd7d76b0b258@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4ABA82BA.6030902@nextday.fi>
	<94bdd2610909250635n343d5d23r30cadd7d76b0b258@mail.gmail.com>
Message-ID: <4ABCFF5F.2070705@nextday.fi>

Tarek Ziad? kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Tarek Ziad? kirjoitti:
>>     
>>> Hello,
>>>
>>> The next Distribute version will be released soon, with python 3
>>> support (thanks to Martin, Lennart, and Alex !)
>>> and more bug fixed. (you can follow that in the issue tracker)
>>>
>>> If you want to give a hand on testing the next Distribute version,
>>> I've uploaded a dev version of the trunk of Distribute at
>>> nightly.ziade.org, meaning that you can try the upcoming release
>>> (at your own risks ;) )
>>>
>>> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
>>> - a modified distribute_setup.py script that will install the dev
>>> version : http://nightly.ziade.org/distribute_setup_dev.py
>>> - a modified bootstrap.py file that will let you bootstrap a
>>> zc.buildout environment with this version
>>>
>>> Any feedback would be greatly appreciated,
>>>
>>> Regards,
>>> Tarek
>>>
>>>
>>>       
>> Successfully tested installing distribute on 32-bit WinXP, on Python 3.1.1.
>> Tried easy_install too, works fine.
>> Regarding the failure with 64-bit Win7, I uninstalled the 64-bit Python and
>> then installed the 32-bit version, and now easy_install works just fine. I
>> think there ought to be 64-bit stubs too -- I don't know how else to explain
>> the problems with the 64-bit Python.
>>
>>     
>
> Could you check if your failure is one of those, please ?
>
> - http://bugs.python.org/setuptools/issue2
>   
Yes, this is precisely what I am experiencing. Good to see someone's 
already looked into it and come up with a solution!
> - http://bugs.python.org/setuptools/issue3
>
>
>
> Tarek
>
>   


From chris at simplistix.co.uk  Fri Sep 25 19:55:23 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 25 Sep 2009 18:55:23 +0100
Subject: [Distutils] [buildout] unzip = true doesn't
Message-ID: <4ABD040B.7060701@simplistix.co.uk>

Hi All,

I had a buildout.cfg which I changed to start:

[buildout]
unzip=true

Re-running the buildout doesn't appear to make sure existing eggs that 
have been downloaded are unzipped. Is that to be expected?

cheers,

Chris

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

From alex.gronholm at nextday.fi  Fri Sep 25 21:26:42 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Fri, 25 Sep 2009 22:26:42 +0300
Subject: [Distutils] Distribute 0.6.2 - testing the release - help
	needed!
In-Reply-To: <94bdd2610909250635n343d5d23r30cadd7d76b0b258@mail.gmail.com>
References: <94bdd2610909200603r4edb611bn7e155cf2c67edeab@mail.gmail.com>	
	<4ABA82BA.6030902@nextday.fi>
	<94bdd2610909250635n343d5d23r30cadd7d76b0b258@mail.gmail.com>
Message-ID: <4ABD1972.20307@nextday.fi>

Tarek Ziad? kirjoitti:
> 2009/9/23 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Tarek Ziad? kirjoitti:
>>     
>>> Hello,
>>>
>>> The next Distribute version will be released soon, with python 3
>>> support (thanks to Martin, Lennart, and Alex !)
>>> and more bug fixed. (you can follow that in the issue tracker)
>>>
>>> If you want to give a hand on testing the next Distribute version,
>>> I've uploaded a dev version of the trunk of Distribute at
>>> nightly.ziade.org, meaning that you can try the upcoming release
>>> (at your own risks ;) )
>>>
>>> - the tarball : http://nightly.ziade.org/distribute-0.6.2dev.tar.gz
>>> - a modified distribute_setup.py script that will install the dev
>>> version : http://nightly.ziade.org/distribute_setup_dev.py
>>> - a modified bootstrap.py file that will let you bootstrap a
>>> zc.buildout environment with this version
>>>
>>> Any feedback would be greatly appreciated,
>>>
>>> Regards,
>>> Tarek
>>>
>>>
>>>       
>> Successfully tested installing distribute on 32-bit WinXP, on Python 3.1.1.
>> Tried easy_install too, works fine.
>> Regarding the failure with 64-bit Win7, I uninstalled the 64-bit Python and
>> then installed the 32-bit version, and now easy_install works just fine. I
>> think there ought to be 64-bit stubs too -- I don't know how else to explain
>> the problems with the 64-bit Python.
>>
>>     
>
> Could you check if your failure is one of those, please ?
>
> - http://bugs.python.org/setuptools/issue2
>
>   
I tested Jason's patch and it seems to work beautifully. The code looks 
OK, doesn't seem to break anything :)
I committed this to the repo as revision #434.

From alex.gronholm at nextday.fi  Fri Sep 25 23:40:18 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Sat, 26 Sep 2009 00:40:18 +0300
Subject: [Distutils] Last call for distribute 0.6.2
Message-ID: <4ABD38C2.3050601@nextday.fi>

We are now ready to release 0.6.2. If you feel that there is a critical 
bug we should fix before this, this is your last chance.

Python 2.3 compatibility was restored in the latest changeset, so feel 
free to test that too.

From zooko at zooko.com  Sat Sep 26 00:20:04 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Fri, 25 Sep 2009 16:20:04 -0600
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
Message-ID: <03A5E24B-7577-405A-8EBB-EA5620F76357@zooko.com>

On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:

> I've skimmed a couple of tutorials on how to generate .deb-files,  
> but, wow, it's a whole new skill set to do that!

Have you tried stdeb?

http://github.com/astraw/stdeb

Check out the section entitled "Quickstart 1: Just tell me the  
fastest way to make a .deb".

Regards,

Zooko

From ziade.tarek at gmail.com  Sat Sep 26 00:21:09 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 26 Sep 2009 00:21:09 +0200
Subject: [Distutils] Last call for distribute 0.6.2
In-Reply-To: <4ABD38C2.3050601@nextday.fi>
References: <4ABD38C2.3050601@nextday.fi>
Message-ID: <94bdd2610909251521y7b7fd027vb3c1443ccebea621@mail.gmail.com>

2009/9/25 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> We are now ready to release 0.6.2. If you feel that there is a critical bug
> we should fix before this, this is your last chance.

I've updated the nightlies if you want to give it a shot.

>
> Python 2.3 compatibility was restored in the latest changeset, so feel free
> to test that too.

Lennart, (or the people that were involved in that, I can't recall the
full list)

Would you mind adding if you have time a small section on "how to use
Distribute in Py3k"
in README.txt ?

Which woud be a very short summary, pointing to the crucial parts of
docs/python3.txt

Tarek

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



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

From regebro at gmail.com  Sat Sep 26 07:28:59 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 26 Sep 2009 07:28:59 +0200
Subject: [Distutils] Last call for distribute 0.6.2
In-Reply-To: <94bdd2610909251521y7b7fd027vb3c1443ccebea621@mail.gmail.com>
References: <4ABD38C2.3050601@nextday.fi>
	<94bdd2610909251521y7b7fd027vb3c1443ccebea621@mail.gmail.com>
Message-ID: <319e029f0909252228l755c1cd1l46ada73751ee931@mail.gmail.com>

2009/9/26 Tarek Ziad? <ziade.tarek at gmail.com>:
> Would you mind adding if you have time a small section on "how to use
> Distribute in Py3k"
> in README.txt ?

Well using it in py3k is no different than in py2. It's only when you
use it for running 2to3 that there is a difference, and I don't see
the point in having a summary for that, you should really read the
whole document. :)

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

From olof.bjarnason at gmail.com  Sat Sep 26 10:14:51 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Sat, 26 Sep 2009 10:14:51 +0200
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <03A5E24B-7577-405A-8EBB-EA5620F76357@zooko.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
	<03A5E24B-7577-405A-8EBB-EA5620F76357@zooko.com>
Message-ID: <c3dfe1d0909260114o30d5f725yd715256a750c69d1@mail.gmail.com>

2009/9/26 Zooko Wilcox-O'Hearn <zooko at zooko.com>:
> On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:
>
>> I've skimmed a couple of tutorials on how to generate .deb-files, but,
>> wow, it's a whole new skill set to do that!
>
> Have you tried stdeb?
>
> http://github.com/astraw/stdeb
>
> Check out the section entitled "Quickstart 1: Just tell me the fastest way
> to make a .deb".

This looks interesting!

This seems to be the path to follow:

1. Learn setup.py+distutils
2. Fix my project to follow that convention
3. Upload project to pypi
4. Use stdeb to generate .deb

>
> Regards,
>
> Zooko
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From strawman at astraw.com  Sat Sep 26 16:43:17 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sat, 26 Sep 2009 07:43:17 -0700
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <c3dfe1d0909260114o30d5f725yd715256a750c69d1@mail.gmail.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>	<03A5E24B-7577-405A-8EBB-EA5620F76357@zooko.com>
	<c3dfe1d0909260114o30d5f725yd715256a750c69d1@mail.gmail.com>
Message-ID: <4ABE2885.2080702@astraw.com>

Olof Bjarnason wrote:
> 2009/9/26 Zooko Wilcox-O'Hearn <zooko at zooko.com>:
>   
>> On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:
>>
>>     
>>> I've skimmed a couple of tutorials on how to generate .deb-files, but,
>>> wow, it's a whole new skill set to do that!
>>>       
>> Have you tried stdeb?
>>
>> http://github.com/astraw/stdeb
>>
>> Check out the section entitled "Quickstart 1: Just tell me the fastest way
>> to make a .deb".
>>     
>
> This looks interesting!
>
> This seems to be the path to follow:
>
> 1. Learn setup.py+distutils
> 2. Fix my project to follow that convention
> 3. Upload project to pypi
>   
Strictly speaking, that step 3 is not necessary.
> 4. Use stdeb to generate .deb


-Andrew

From olof.bjarnason at gmail.com  Sat Sep 26 17:51:30 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Sat, 26 Sep 2009 17:51:30 +0200
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <4ABE2885.2080702@astraw.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>
	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>
	<03A5E24B-7577-405A-8EBB-EA5620F76357@zooko.com>
	<c3dfe1d0909260114o30d5f725yd715256a750c69d1@mail.gmail.com>
	<4ABE2885.2080702@astraw.com>
Message-ID: <c3dfe1d0909260851l3cc54f25g4f9ef4e6d4a8642@mail.gmail.com>

2009/9/26 Andrew Straw <strawman at astraw.com>:
> Olof Bjarnason wrote:
>> 2009/9/26 Zooko Wilcox-O'Hearn <zooko at zooko.com>:
>>
>>> On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:
>>>
>>>
>>>> I've skimmed a couple of tutorials on how to generate .deb-files, but,
>>>> wow, it's a whole new skill set to do that!
>>>>
>>> Have you tried stdeb?
>>>
>>> http://github.com/astraw/stdeb
>>>
>>> Check out the section entitled "Quickstart 1: Just tell me the fastest way
>>> to make a .deb".
>>>
>>
>> This looks interesting!
>>
>> This seems to be the path to follow:
>>
>> 1. Learn setup.py+distutils
>> 2. Fix my project to follow that convention
>> 3. Upload project to pypi
>>
> Strictly speaking, that step 3 is not necessary.
>> 4. Use stdeb to generate .deb

OK thanks. I gather stdeb does handle .deb-package dependencies, like
PyGame, right?

>
>
> -Andrew
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From ziade.tarek at gmail.com  Sat Sep 26 20:28:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 26 Sep 2009 20:28:25 +0200
Subject: [Distutils] Distribute 0.6.2 released
Message-ID: <94bdd2610909261128w18f4ef43ma6489b22e2bb18ed@mail.gmail.com>

Hello

On behalf of the Distribute team, I am very proud to announce the
release of Distribute 0.6.2.

http://pypi.python.org/pypi/distribute/0.6.2

This release is the first release that is compatible with Python 3,
kudos to Martin von L?wis, Lennart Regebro and
Alex Gr?nholm and the ones I am missing, on this work ! (see the
contributors.txt file)

The next 0.6.3 release will focus on eliminating the remaining bugs
and continuing the stabilization
of Distribute, while we are actively working on a full refactoring in
the 0.7 series.

If you have any comment, feedback or if you want to contribute, please
drop a line in distutils-sig at python.org,
or in our bug tracker (http://bitbucket.org/tarek/distribute/issues)

* CHANGES *

    * Added Python 3 support. see docs/python3.txt This closes
http://bitbucket.org/tarek/distribute/issue/39.
    * Added option to run 2to3 automatically when installing on Python
3. This closes http://bitbucket.org/tarek/distribute/issue/31.
    * Fixed invalid usage of requirement.parse, that broke develop -d.
This closes http://bugs.python.org/setuptools/issue44.
    * Fixed script launcher for 64-bit Windows. This closes
http://bugs.python.org/setuptools/issue2.
    * KeyError when compiling extensions. This closes
http://bugs.python.org/setuptools/issue41.
    * Fixed bootstrap not working on Windows. This closes
http://bitbucket.org/tarek/distribute/issue/49.
    * Fixed 2.6 dependencies. This closes
http://bitbucket.org/tarek/distribute/issue/50.
    * Make sure setuptools is patched when running through
easy_install This closes http://bugs.python.org/setuptools/issue40.

Regards,
Tarek

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

From strawman at astraw.com  Sat Sep 26 22:42:17 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sat, 26 Sep 2009 13:42:17 -0700
Subject: [Distutils] Distributing Python-programs to Ubuntu users
In-Reply-To: <c3dfe1d0909260851l3cc54f25g4f9ef4e6d4a8642@mail.gmail.com>
References: <c3dfe1d0909242315j3893d364mc3794c44e6d836a3@mail.gmail.com>	<c3dfe1d0909250123v1679237cs6f5555c136bc6809@mail.gmail.com>	<03A5E24B-7577-405A-8EBB-EA5620F76357@zooko.com>	<c3dfe1d0909260114o30d5f725yd715256a750c69d1@mail.gmail.com>	<4ABE2885.2080702@astraw.com>
	<c3dfe1d0909260851l3cc54f25g4f9ef4e6d4a8642@mail.gmail.com>
Message-ID: <4ABE7CA9.8090605@astraw.com>

Olof Bjarnason wrote:
> OK thanks. I gather stdeb does handle .deb-package dependencies, like
> PyGame, right?
>   
Yes, you have to add them as a config option. See the "Depends" config
option in "Customizing the produced Debian source package (config
options)" in the README.

-Andrew

From ziade.tarek at gmail.com  Sun Sep 27 04:43:41 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 27 Sep 2009 04:43:41 +0200
Subject: [Distutils] Distribute 0.6.2 released
In-Reply-To: <94bdd2610909261128w18f4ef43ma6489b22e2bb18ed@mail.gmail.com>
References: <94bdd2610909261128w18f4ef43ma6489b22e2bb18ed@mail.gmail.com>
Message-ID: <94bdd2610909261943o36c59eb2qf1b87821bc2b1613@mail.gmail.com>

On Sat, Sep 26, 2009 at 8:28 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Hello
>
> On behalf of the Distribute team, I am very proud to announce the
> release of Distribute 0.6.2.
>
> http://pypi.python.org/pypi/distribute/0.6.2

We've found some issues in 0.6.2 concerning Py3k support, so we've fixed it,
and released 0.6.3 right away so you don't get the problem.

Also, we've added a distribute_setup_3k.py script for conveniency, to
install Distribute in Python 3.

Tarek

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

From jeremy at jeremysanders.net  Sun Sep 27 11:46:48 2009
From: jeremy at jeremysanders.net (Jeremy Sanders)
Date: Sun, 27 Sep 2009 10:46:48 +0100
Subject: [Distutils] SIP/PyQt and distutils
Message-ID: <h9nca8$s0p$1@ger.gmane.org>

Hi - I feel like I'm in maze of twisty passages trying to get my SIP/PyQt 
extension to play nicely with distutils. Most of the package is pure Python, 
but I have one standard C extension and a new SIP one I have added to the 
project.

I need to be able to compile C++ files with the compiler and all its 
arguments specified for the SIP extension. Is there any way to do this with 
distutils? I've gone through the sourcecode and can't see an obvious way to 
do this without hacking it completely. distutils compiles C++ files with gcc 
(not g++) and uses invalid compiler arguments on this Ubuntu system.

Alternatively, SIP makes a nice Makefile which works. Can I run make as part 
of the build process and add the object file to distutils list of files to 
be installed?

Are there any better options than distutils?

Jeremy

-- 
jeremy at jeremysanders.net
http://www.jeremysanders.net/


From zooko at zooko.com  Sun Sep 27 18:42:03 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sun, 27 Sep 2009 10:42:03 -0600
Subject: [Distutils] SIP/PyQt and distutils
In-Reply-To: <h9nca8$s0p$1@ger.gmane.org>
References: <h9nca8$s0p$1@ger.gmane.org>
Message-ID: <5B6D5514-20DD-4B70-9311-3AC02EBC3AE2@zooko.com>

On Sunday,2009-09-27, at 3:46 , Jeremy Sanders wrote:

> distutils compiles C++ files with gcc (not g++) and uses invalid  
> compiler arguments on this Ubuntu system.

This setup.py works to build C++ files on Ubuntu:

http://allmydata.org/trac/pycryptopp/browser/setup.py

I'm not sure that you really need to explicitly invoke "g++" for  
anything nowadays.  Modern "gcc" notices that the input is C++ and  
compiles it accordingly.

Could you be more specific about what doesn't work?

See also the C++ sig, where they have a lot more expertise about this:

http://www.python.org/community/sigs/current/cplusplus-sig/

Regards,

Zooko

From jeremy at jeremysanders.net  Sun Sep 27 19:19:08 2009
From: jeremy at jeremysanders.net (Jeremy Sanders)
Date: Sun, 27 Sep 2009 18:19:08 +0100
Subject: [Distutils] SIP/PyQt and distutils
References: <h9nca8$s0p$1@ger.gmane.org>
	<5B6D5514-20DD-4B70-9311-3AC02EBC3AE2@zooko.com>
Message-ID: <h9o6qc$sll$1@ger.gmane.org>

Zooko Wilcox-O'Hearn wrote:

> I'm not sure that you really need to explicitly invoke "g++" for
> anything nowadays.  Modern "gcc" notices that the input is C++ and
> compiles it accordingly.
> 
> Could you be more specific about what doesn't work?

It does work, but prints out warnings:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-
prototypes -fPIC -I/helpers/src -I/usr/include/qt4/QtCore -
I/usr/include/qt4/QtGui-I/usr/include/qt4 -I/usr/include/python2.6 -
Ihelpers/src -I/usr/include/python2.6 -c helpers/src/qtloops_helpers.cpp -o 
build/temp.linux-i686-2.6/helpers/src/qtloops_helpers.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++

It would be nice if it didn't use invalid C++ options.

I'd like to be able to exactly specify the arguments to the compiler as Qt 
requires particular options.

Jeremy

-- 
jeremy at jeremysanders.net
http://www.jeremysanders.net/


From alex.gronholm at nextday.fi  Sun Sep 27 19:27:55 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Sun, 27 Sep 2009 20:27:55 +0300
Subject: [Distutils] SIP/PyQt and distutils
In-Reply-To: <h9o6qc$sll$1@ger.gmane.org>
References: <h9nca8$s0p$1@ger.gmane.org>	<5B6D5514-20DD-4B70-9311-3AC02EBC3AE2@zooko.com>
	<h9o6qc$sll$1@ger.gmane.org>
Message-ID: <4ABFA09B.1090408@nextday.fi>

Jeremy Sanders kirjoitti:
> Zooko Wilcox-O'Hearn wrote:
>
>   
>> I'm not sure that you really need to explicitly invoke "g++" for
>> anything nowadays.  Modern "gcc" notices that the input is C++ and
>> compiles it accordingly.
>>
>> Could you be more specific about what doesn't work?
>>     
>
> It does work, but prints out warnings:
>
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-
> prototypes -fPIC -I/helpers/src -I/usr/include/qt4/QtCore -
> I/usr/include/qt4/QtGui-I/usr/include/qt4 -I/usr/include/python2.6 -
> Ihelpers/src -I/usr/include/python2.6 -c helpers/src/qtloops_helpers.cpp -o 
> build/temp.linux-i686-2.6/helpers/src/qtloops_helpers.o
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
> Ada/C/ObjC but not for C++
>
> It would be nice if it didn't use invalid C++ options.
>
> I'd like to be able to exactly specify the arguments to the compiler as Qt 
> requires particular options.
>
> Jeremy
>
>   
Compiling the extensions for pycryptopp also gives these kinds of warnings.

From olof.bjarnason at gmail.com  Sun Sep 27 20:05:09 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Sun, 27 Sep 2009 20:05:09 +0200
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
Message-ID: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>

Hi distutils!

So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.

What are the "correct" steps of installing this tool, assuming
Ubuntu9.04. I guess I need this:

1. Python (check)
2. distutils (check)
3. setuptools (dunno? how do I install?)
4. stdeb (how do I install correctly?)

As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
cheesecake, setuptools and stdeb. It's a whole new universe! :)

-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From greno at verizon.net  Sun Sep 27 20:34:01 2009
From: greno at verizon.net (Gerry Reno)
Date: Sun, 27 Sep 2009 14:34:01 -0400
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
Message-ID: <4ABFB019.7060608@verizon.net>

Olof Bjarnason wrote:
> Hi distutils!
>
> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>
> What are the "correct" steps of installing this tool, assuming
> Ubuntu9.04. I guess I need this:
>
> 1. Python (check)
> 2. distutils (check)
> 3. setuptools (dunno? how do I install?)
> 4. stdeb (how do I install correctly?)
>
> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>
>   
You need to install setuptools from your distro package manager.

You can then use easy_install to install stdeb.

Regards,
Gerry


From strawman at astraw.com  Sun Sep 27 20:38:31 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 27 Sep 2009 11:38:31 -0700
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
Message-ID: <4ABFB127.9090204@astraw.com>

Olof Bjarnason wrote:
> Hi distutils!
>
> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>
> What are the "correct" steps of installing this tool, assuming
> Ubuntu9.04. I guess I need this:
>
> 1. Python (check)
> 2. distutils (check)
> 3. setuptools (dunno? how do I install?)
> 4. stdeb (how do I install correctly?)
>
> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>
>   
Hi Olof,

For ubuntu 9.04, you will need stdeb 0.4 (the current git master
branch), which isn't released yet. I consider
http://github.com/astraw/stdeb/issues/#issue/10 to be blocking the
release of 0.4.

Stay tuned... with luck I'll find a workaround today. But I'm interested
in seeing the resolution to the debhelper bug (Debian bug #548392) so I
can account for that, too.

-Andrew

From olof.bjarnason at gmail.com  Sun Sep 27 21:18:06 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Sun, 27 Sep 2009 21:18:06 +0200
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <4ABFB127.9090204@astraw.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
	<4ABFB127.9090204@astraw.com>
Message-ID: <c3dfe1d0909271218u1b33461bu7aad9e373c9a5f0@mail.gmail.com>

2009/9/27 Andrew Straw <strawman at astraw.com>:
> Olof Bjarnason wrote:
>> Hi distutils!
>>
>> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>>
>> What are the "correct" steps of installing this tool, assuming
>> Ubuntu9.04. I guess I need this:
>>
>> 1. Python (check)
>> 2. distutils (check)
>> 3. setuptools (dunno? how do I install?)
>> 4. stdeb (how do I install correctly?)
>>
>> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
>> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>>
>>
> Hi Olof,
>
> For ubuntu 9.04, you will need stdeb 0.4 (the current git master
> branch), which isn't released yet. I consider
> http://github.com/astraw/stdeb/issues/#issue/10 to be blocking the
> release of 0.4.
>
> Stay tuned... with luck I'll find a workaround today. But I'm interested
> in seeing the resolution to the debhelper bug (Debian bug #548392) so I
> can account for that, too.

Gerry/Andrew - thanks for help.

At least I got past installing setuptools/easy_install.

I guess easy_install/PyPI/setuptools is a pythonic way of getting past
all package managers in the world ;)

Anyway Andrew, I thought you'd be interested in the output from my
"easy_install stdeb":

Here:

olof at olof-work:~/prj/fortressdefender$ sudo easy_install -n stdeb
Searching for stdeb
Reading http://pypi.python.org/simple/stdeb/
Reading http://stdeb.python-hosting.com/
Reading http://github.com/astraw/stdeb
Best match: stdeb 0.3
Downloading http://pypi.python.org/packages/source/s/stdeb/stdeb-0.3.tar.gz#md5=e692f745597dcdd9343ce133e3b910d0
Processing stdeb-0.3.tar.gz
Running stdeb-0.3/setup.py -n -q bdist_egg --dist-dir
/tmp/easy_install-ogTrmA/stdeb-0.3/egg-dist-tmp-3N3QwZ
/usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown
distribution option: 'zip_ok'
  warnings.warn(msg)
warning: install_lib: 'build/lib.linux-i686-2.6' does not exist -- no
Python modules to install
zip_safe flag not set; analyzing archive contents...

>
> -Andrew
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From alex.gronholm at nextday.fi  Sun Sep 27 21:25:34 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Sun, 27 Sep 2009 22:25:34 +0300
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
Message-ID: <4ABFBC2E.8020305@nextday.fi>

Olof Bjarnason kirjoitti:
> Hi distutils!
>
> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>
> What are the "correct" steps of installing this tool, assuming
> Ubuntu9.04. I guess I need this:
>
> 1. Python (check)
> 2. distutils (check)
>   
Distutils is a part of the standard library, so you can't have Python 
without distutils anyway.
> 3. setuptools (dunno? how do I install?)
>   
As a contributor to the distribute project (the successor to 
setuptools), I would advise you to download the distribute bootstrap 
script from:
http://nightly.ziade.org/distribute_setup.py
Then run it as root, and that's it!
> 4. stdeb (how do I install correctly?)
>
> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>
>   


From ziade.tarek at gmail.com  Sun Sep 27 21:34:04 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 27 Sep 2009 21:34:04 +0200
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <4ABFBC2E.8020305@nextday.fi>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
	<4ABFBC2E.8020305@nextday.fi>
Message-ID: <94bdd2610909271234i5363aee5w71cc94cb36a75bdc@mail.gmail.com>

2009/9/27 Alex Gr?nholm <alex.gronholm at nextday.fi>:
>> 3. setuptools (dunno? how do I install?)
>>
>
> As a contributor to the distribute project (the successor to setuptools), I
> would advise you to download the distribute bootstrap script from:
> http://nightly.ziade.org/distribute_setup.py
> Then run it as root, and that's it!

I have worked with Matthias Klose to fix a showstopper in
python-setuptools  for 2.6.2+

We've discussed the option of adding in Ubuntu a python-distribute package.

Maybe we could do the same thing with debian if anyone knows a debian
package manager
that is willing to help us ?

Tarek

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

From olof.bjarnason at gmail.com  Sun Sep 27 21:36:27 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Sun, 27 Sep 2009 21:36:27 +0200
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <4ABFBC2E.8020305@nextday.fi>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
	<4ABFBC2E.8020305@nextday.fi>
Message-ID: <c3dfe1d0909271236h157bf15cua011888502534f01@mail.gmail.com>

Den 27 september 2009 21.25 skrev Alex Gr?nholm <alex.gronholm at nextday.fi>:
> Olof Bjarnason kirjoitti:
>>
>> Hi distutils!
>>
>> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>>
>> What are the "correct" steps of installing this tool, assuming
>> Ubuntu9.04. I guess I need this:
>>
>> 1. Python (check)
>> 2. distutils (check)
>>
>
> Distutils is a part of the standard library, so you can't have Python
> without distutils anyway.
>>
>> 3. setuptools (dunno? how do I install?)
>>
>
> As a contributor to the distribute project (the successor to setuptools), I
> would advise you to download the distribute bootstrap script from:
> http://nightly.ziade.org/distribute_setup.py
> Then run it as root, and that's it!

Um ok but I already got setuptools now. Should I install distribute too?

>>
>> 4. stdeb (how do I install correctly?)
>>
>> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
>> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>>
>>
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From alex.gronholm at nextday.fi  Sun Sep 27 21:39:46 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Sun, 27 Sep 2009 22:39:46 +0300
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <c3dfe1d0909271236h157bf15cua011888502534f01@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>	
	<4ABFBC2E.8020305@nextday.fi>
	<c3dfe1d0909271236h157bf15cua011888502534f01@mail.gmail.com>
Message-ID: <4ABFBF82.2000709@nextday.fi>

Olof Bjarnason kirjoitti:
> Den 27 september 2009 21.25 skrev Alex Gr?nholm <alex.gronholm at nextday.fi>:
>   
>> Olof Bjarnason kirjoitti:
>>     
>>> Hi distutils!
>>>
>>> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>>>
>>> What are the "correct" steps of installing this tool, assuming
>>> Ubuntu9.04. I guess I need this:
>>>
>>> 1. Python (check)
>>> 2. distutils (check)
>>>
>>>       
>> Distutils is a part of the standard library, so you can't have Python
>> without distutils anyway.
>>     
>>> 3. setuptools (dunno? how do I install?)
>>>
>>>       
>> As a contributor to the distribute project (the successor to setuptools), I
>> would advise you to download the distribute bootstrap script from:
>> http://nightly.ziade.org/distribute_setup.py
>> Then run it as root, and that's it!
>>     
>
> Um ok but I already got setuptools now. Should I install distribute too?
>
>   
Not necessarily. You should know, however, that setuptools has 
effectively been discontinued and will not get any bug fixes.
The distribute bootstrap will replace setuptools with a fake package, so 
it's a true drop-in replacement.
>>> 4. stdeb (how do I install correctly?)
>>>
>>> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
>>> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>>>
>>>
>>>       
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>>     


From strawman at astraw.com  Sun Sep 27 21:41:15 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 27 Sep 2009 12:41:15 -0700
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <c3dfe1d0909271236h157bf15cua011888502534f01@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>	<4ABFBC2E.8020305@nextday.fi>
	<c3dfe1d0909271236h157bf15cua011888502534f01@mail.gmail.com>
Message-ID: <4ABFBFDB.5050606@astraw.com>

Olof Bjarnason wrote:
> Um ok but I already got setuptools now. Should I install distribute too?
>   
No, distribute has not been tested with stdeb yet. (To my knowledge.)

-Andrew

From floris.bruynooghe at gmail.com  Sun Sep 27 23:48:04 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Sun, 27 Sep 2009 22:48:04 +0100
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <94bdd2610909271234i5363aee5w71cc94cb36a75bdc@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
	<4ABFBC2E.8020305@nextday.fi>
	<94bdd2610909271234i5363aee5w71cc94cb36a75bdc@mail.gmail.com>
Message-ID: <20090927214804.GA28680@laurie.devork>

On Sun, Sep 27, 2009 at 09:34:04PM +0200, Tarek Ziad? wrote:
> I have worked with Matthias Klose to fix a showstopper in
> python-setuptools  for 2.6.2+
> 
> We've discussed the option of adding in Ubuntu a python-distribute package.
> 
> Maybe we could do the same thing with debian if anyone knows a debian
> package manager
> that is willing to help us ?

Try sending a mail to debian-python at lists.debian.org, there's people
there that should be able to help with that.  AFAIK Matthias Klose is
a Debian Developer too actually...


Floris

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

From strawman at astraw.com  Mon Sep 28 00:08:59 2009
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 27 Sep 2009 15:08:59 -0700
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <4ABFB127.9090204@astraw.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
	<4ABFB127.9090204@astraw.com>
Message-ID: <4ABFE27B.7070907@astraw.com>

Andrew Straw wrote:
> Olof Bjarnason wrote:
>   
>> Hi distutils!
>>
>> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>>
>> What are the "correct" steps of installing this tool, assuming
>> Ubuntu9.04. I guess I need this:
>>
>> 1. Python (check)
>> 2. distutils (check)
>> 3. setuptools (dunno? how do I install?)
>> 4. stdeb (how do I install correctly?)
>>
>> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
>> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>>
>>   
>>     
> Hi Olof,
>
> For ubuntu 9.04, you will need stdeb 0.4 (the current git master
> branch), which isn't released yet. I consider
> http://github.com/astraw/stdeb/issues/#issue/10 to be blocking the
> release of 0.4.
>
> Stay tuned... with luck I'll find a workaround today. But I'm interested
> in seeing the resolution to the debhelper bug (Debian bug #548392) so I
> can account for that, too.
>   

OK, I have uploaded stdeb 0.4 to http://pypi.python.org/pypi/stdeb/0.4
(Also 0.3.1 to http://pypi.python.org/pypi/stdeb/0.3.1 )

The README.rst file in there should hopefully have enough to get you
started (presuming your setup.py file works).

I'll make an announcement once the dust settles from the hosting
company's computer move. (github is switching to rackspace today.)

-Andrew

From olof.bjarnason at gmail.com  Mon Sep 28 06:43:55 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Mon, 28 Sep 2009 06:43:55 +0200
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <4ABFE27B.7070907@astraw.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>
	<4ABFB127.9090204@astraw.com> <4ABFE27B.7070907@astraw.com>
Message-ID: <c3dfe1d0909272143q373911fci2f717547c21e79ab@mail.gmail.com>

2009/9/28 Andrew Straw <strawman at astraw.com>:
> Andrew Straw wrote:
>> Olof Bjarnason wrote:
>>
>>> Hi distutils!
>>>
>>> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>>>
>>> What are the "correct" steps of installing this tool, assuming
>>> Ubuntu9.04. I guess I need this:
>>>
>>> 1. Python (check)
>>> 2. distutils (check)
>>> 3. setuptools (dunno? how do I install?)
>>> 4. stdeb (how do I install correctly?)
>>>
>>> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
>>> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>>>
>>>
>>>
>> Hi Olof,
>>
>> For ubuntu 9.04, you will need stdeb 0.4 (the current git master
>> branch), which isn't released yet. I consider
>> http://github.com/astraw/stdeb/issues/#issue/10 to be blocking the
>> release of 0.4.
>>
>> Stay tuned... with luck I'll find a workaround today. But I'm interested
>> in seeing the resolution to the debhelper bug (Debian bug #548392) so I
>> can account for that, too.
>>
>
> OK, I have uploaded stdeb 0.4 to http://pypi.python.org/pypi/stdeb/0.4
> (Also 0.3.1 to http://pypi.python.org/pypi/stdeb/0.3.1 )
>
> The README.rst file in there should hopefully have enough to get you
> started (presuming your setup.py file works).
>
> I'll make an announcement once the dust settles from the hosting
> company's computer move. (github is switching to rackspace today.)

Cool. Is there a way to update with easy_install from 0.3 which I,
oops, installed last night ;) ?

>
> -Andrew
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From alex.gronholm at nextday.fi  Mon Sep 28 06:45:02 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Mon, 28 Sep 2009 07:45:02 +0300
Subject: [Distutils] Installing stdeb on vanilla Ubuntu
In-Reply-To: <c3dfe1d0909272143q373911fci2f717547c21e79ab@mail.gmail.com>
References: <c3dfe1d0909271105t76c8ccbdl7ec8ff0f2be454e2@mail.gmail.com>	<4ABFB127.9090204@astraw.com>
	<4ABFE27B.7070907@astraw.com>
	<c3dfe1d0909272143q373911fci2f717547c21e79ab@mail.gmail.com>
Message-ID: <4AC03F4E.1030509@nextday.fi>

Olof Bjarnason kirjoitti:
> 2009/9/28 Andrew Straw <strawman at astraw.com>:
>   
>> Andrew Straw wrote:
>>     
>>> Olof Bjarnason wrote:
>>>
>>>       
>>>> Hi distutils!
>>>>
>>>> So I'm quite sure stdeb is the tool for "py2deb" I'm looking for.
>>>>
>>>> What are the "correct" steps of installing this tool, assuming
>>>> Ubuntu9.04. I guess I need this:
>>>>
>>>> 1. Python (check)
>>>> 2. distutils (check)
>>>> 3. setuptools (dunno? how do I install?)
>>>> 4. stdeb (how do I install correctly?)
>>>>
>>>> As all of you know by now, I'm fairly new to distutils, PyPI, eggs,
>>>> cheesecake, setuptools and stdeb. It's a whole new universe! :)
>>>>
>>>>
>>>>
>>>>         
>>> Hi Olof,
>>>
>>> For ubuntu 9.04, you will need stdeb 0.4 (the current git master
>>> branch), which isn't released yet. I consider
>>> http://github.com/astraw/stdeb/issues/#issue/10 to be blocking the
>>> release of 0.4.
>>>
>>> Stay tuned... with luck I'll find a workaround today. But I'm interested
>>> in seeing the resolution to the debhelper bug (Debian bug #548392) so I
>>> can account for that, too.
>>>
>>>       
>> OK, I have uploaded stdeb 0.4 to http://pypi.python.org/pypi/stdeb/0.4
>> (Also 0.3.1 to http://pypi.python.org/pypi/stdeb/0.3.1 )
>>
>> The README.rst file in there should hopefully have enough to get you
>> started (presuming your setup.py file works).
>>
>> I'll make an announcement once the dust settles from the hosting
>> company's computer move. (github is switching to rackspace today.)
>>     
>
> Cool. Is there a way to update with easy_install from 0.3 which I,
> oops, installed last night ;) ?
>
>   
easy_install -U stdeb
>> -Andrew
>>
>>     
>
>
>
>   


From greno at verizon.net  Mon Sep 28 15:42:15 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 09:42:15 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4ABBE693.6050300@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
Message-ID: <4AC0BD37.1010507@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Then I'm ok then with having 'bdist_deb' be the name and using the
>> plugin approach.
>>
>> Andrew, what do you think about this solution?
>>     
> It's already committed as of a couple days ago in the "old-stable"
> branch and I just merged it into the master branch.
>
> I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the master
> branch) with this soon.
>
> -Andrew
>   
In reviewing the gerry-reno git branch and the old-stable branch I don't 
see where there are any user-options declared in 
stdeb/command/bdist_deb.py.  Shouldn't the same user-options be there as 
are in sdist_dsc.py?  The 'bdist_deb' command usefulness would be very 
limited without the ability to pass options to it and hence to 'sdist_dsc'.

Regards,
Gerry


From strawman at astraw.com  Mon Sep 28 16:49:14 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 07:49:14 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0BD37.1010507@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net>
Message-ID: <4AC0CCEA.5080509@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> Then I'm ok then with having 'bdist_deb' be the name and using the
>>> plugin approach.
>>>
>>> Andrew, what do you think about this solution?
>>>     
>> It's already committed as of a couple days ago in the "old-stable"
>> branch and I just merged it into the master branch.
>>
>> I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the master
>> branch) with this soon.
>>
>> -Andrew
>>   
> In reviewing the gerry-reno git branch and the old-stable branch I
> don't see where there are any user-options declared in
> stdeb/command/bdist_deb.py.  Shouldn't the same user-options be there
> as are in sdist_dsc.py?  The 'bdist_deb' command usefulness would be
> very limited without the ability to pass options to it and hence to
> 'sdist_dsc'.
What options do you want to pass to it? bdist_deb does very little other
than call dpkg-buildpackage on the result of sdist_dsc.

As far as how -- that's standard distutils. You should be able to follow
the lead from the sdist_dsc command, for example.

(I'm still waiting for github come come 100% back online.)

-Andrew

From greno at verizon.net  Mon Sep 28 16:53:26 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 10:53:26 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0CCEA.5080509@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
Message-ID: <4AC0CDE6.2010604@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> Gerry Reno wrote:
>>>  
>>>       
>>>> Then I'm ok then with having 'bdist_deb' be the name and using the
>>>> plugin approach.
>>>>
>>>> Andrew, what do you think about this solution?
>>>>     
>>>>         
>>> It's already committed as of a couple days ago in the "old-stable"
>>> branch and I just merged it into the master branch.
>>>
>>> I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the master
>>> branch) with this soon.
>>>
>>> -Andrew
>>>   
>>>       
>> In reviewing the gerry-reno git branch and the old-stable branch I
>> don't see where there are any user-options declared in
>> stdeb/command/bdist_deb.py.  Shouldn't the same user-options be there
>> as are in sdist_dsc.py?  The 'bdist_deb' command usefulness would be
>> very limited without the ability to pass options to it and hence to
>> 'sdist_dsc'.
>>     
> What options do you want to pass to it? bdist_deb does very little other
> than call dpkg-buildpackage on the result of sdist_dsc.
>
> As far as how -- that's standard distutils. You should be able to follow
> the lead from the sdist_dsc command, for example.
>
>   
Well, for starters, we need to be able to pass  the option 
'--ignore-single-version-externally-managed' and beyond that we need to 
pass other options down to sdist_dsc, things like 
'--ignore-install-requires'.

Regards,
Gerry


From strawman at astraw.com  Mon Sep 28 17:21:51 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 08:21:51 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0CDE6.2010604@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net>
Message-ID: <4AC0D48F.90000@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> Andrew Straw wrote:
>>>    
>>>> Gerry Reno wrote:
>>>>  
>>>>      
>>>>> Then I'm ok then with having 'bdist_deb' be the name and using the
>>>>> plugin approach.
>>>>>
>>>>> Andrew, what do you think about this solution?
>>>>>             
>>>> It's already committed as of a couple days ago in the "old-stable"
>>>> branch and I just merged it into the master branch.
>>>>
>>>> I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the
>>>> master
>>>> branch) with this soon.
>>>>
>>>> -Andrew
>>>>         
>>> In reviewing the gerry-reno git branch and the old-stable branch I
>>> don't see where there are any user-options declared in
>>> stdeb/command/bdist_deb.py.  Shouldn't the same user-options be there
>>> as are in sdist_dsc.py?  The 'bdist_deb' command usefulness would be
>>> very limited without the ability to pass options to it and hence to
>>> 'sdist_dsc'.
>>>     
>> What options do you want to pass to it? bdist_deb does very little other
>> than call dpkg-buildpackage on the result of sdist_dsc.
>>
>> As far as how -- that's standard distutils. You should be able to follow
>> the lead from the sdist_dsc command, for example.
>>
>>   
> Well, for starters, we need to be able to pass  the option
> '--ignore-single-version-externally-managed' and beyond that we need
> to pass other options down to sdist_dsc, things like
> '--ignore-install-requires'.
Just pass the arguments directly to sdist_dsc. It should be something
like this:

python setup.py sdist_dsc --ignore-single-version-externally-managed
--ignore-install-requires bdist_deb

This is similar to other distutils cases. For example

python setup.py build_ext --compiler=mingw32 --bdist_wininst

Will do compilation using the mingw compiler and then build a .exe
installer for Windows.

From greno at verizon.net  Mon Sep 28 18:06:01 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 12:06:01 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0D48F.90000@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AB923A7.7060006@verizon.net>
	<4AB9C932.2070907@astraw.com> <4ABA421C.7000405@verizon.net>
	<4ABA4D5E.4080008@astraw.com> <4ABA637E.1080804@verizon.net>
	<4ABA8A5C.7050007@astraw.com>
	<94bdd2610909240419j4124fe74y5c15bee8ecb514ad@mail.gmail.com>
	<4ABBA1F4.9030402@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
Message-ID: <4AC0DEE9.5060800@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> Gerry Reno wrote:
>>>  
>>>       
>>>> Andrew Straw wrote:
>>>>    
>>>>         
>>>>> Gerry Reno wrote:
>>>>>  
>>>>>      
>>>>>           
>>>>>> Then I'm ok then with having 'bdist_deb' be the name and using the
>>>>>> plugin approach.
>>>>>>
>>>>>> Andrew, what do you think about this solution?
>>>>>>             
>>>>>>             
>>>>> It's already committed as of a couple days ago in the "old-stable"
>>>>> branch and I just merged it into the master branch.
>>>>>
>>>>> I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the
>>>>> master
>>>>> branch) with this soon.
>>>>>
>>>>> -Andrew
>>>>>         
>>>>>           
>>>> In reviewing the gerry-reno git branch and the old-stable branch I
>>>> don't see where there are any user-options declared in
>>>> stdeb/command/bdist_deb.py.  Shouldn't the same user-options be there
>>>> as are in sdist_dsc.py?  The 'bdist_deb' command usefulness would be
>>>> very limited without the ability to pass options to it and hence to
>>>> 'sdist_dsc'.
>>>>     
>>>>         
>>> What options do you want to pass to it? bdist_deb does very little other
>>> than call dpkg-buildpackage on the result of sdist_dsc.
>>>
>>> As far as how -- that's standard distutils. You should be able to follow
>>> the lead from the sdist_dsc command, for example.
>>>
>>>   
>>>       
>> Well, for starters, we need to be able to pass  the option
>> '--ignore-single-version-externally-managed' and beyond that we need
>> to pass other options down to sdist_dsc, things like
>> '--ignore-install-requires'.
>>     
> Just pass the arguments directly to sdist_dsc. It should be something
> like this:
>
> python setup.py sdist_dsc --ignore-single-version-externally-managed
> --ignore-install-requires bdist_deb
>   
How's that going to work?  You have 'sdist_dsc' on the command line as 
well as 'bdist_deb'.   'bdist_deb' also calls 'sdist_dsc' internally but 
this time it would be without any arguments?  How can that work?

Regards,
Gerry


From olof.bjarnason at gmail.com  Mon Sep 28 18:12:23 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Mon, 28 Sep 2009 18:12:23 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0DEE9.5060800@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
Message-ID: <c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>

2009/9/28 Gerry Reno <greno at verizon.net>:
> Andrew Straw wrote:
>>
>> Gerry Reno wrote:
>>
>>>
>>> Andrew Straw wrote:
>>>
>>>>
>>>> Gerry Reno wrote:
>>>>
>>>>>
>>>>> Andrew Straw wrote:
>>>>>
>>>>>>
>>>>>> Gerry Reno wrote:
>>>>>>
>>>>>>>
>>>>>>> Then I'm ok then with having 'bdist_deb' be the name and using the
>>>>>>> plugin approach.
>>>>>>>
>>>>>>> Andrew, what do you think about this solution?
>>>>>>>
>>>>>>
>>>>>> It's already committed as of a couple days ago in the "old-stable"
>>>>>> branch and I just merged it into the master branch.
>>>>>>
>>>>>> I'll release 0.3.1 (from the old-stable branch) and 0.4 (from the
>>>>>> master
>>>>>> branch) with this soon.
>>>>>>
>>>>>> -Andrew
>>>>>>
>>>>>
>>>>> In reviewing the gerry-reno git branch and the old-stable branch I
>>>>> don't see where there are any user-options declared in
>>>>> stdeb/command/bdist_deb.py. ?Shouldn't the same user-options be there
>>>>> as are in sdist_dsc.py? ?The 'bdist_deb' command usefulness would be
>>>>> very limited without the ability to pass options to it and hence to
>>>>> 'sdist_dsc'.
>>>>>
>>>>
>>>> What options do you want to pass to it? bdist_deb does very little other
>>>> than call dpkg-buildpackage on the result of sdist_dsc.
>>>>
>>>> As far as how -- that's standard distutils. You should be able to follow
>>>> the lead from the sdist_dsc command, for example.
>>>>
>>>>
>>>
>>> Well, for starters, we need to be able to pass ?the option
>>> '--ignore-single-version-externally-managed' and beyond that we need
>>> to pass other options down to sdist_dsc, things like
>>> '--ignore-install-requires'.
>>>
>>
>> Just pass the arguments directly to sdist_dsc. It should be something
>> like this:
>>
>> python setup.py sdist_dsc --ignore-single-version-externally-managed
>> --ignore-install-requires bdist_deb
>>
>
> How's that going to work? ?You have 'sdist_dsc' on the command line as well
> as 'bdist_deb'. ? 'bdist_deb' also calls 'sdist_dsc' internally but this
> time it would be without any arguments? ?How can that work?
>

OK I know I'm a noob on *nix distribution of python apps', but:

Would it be possible to extend setup.py with info for package dependency?

Then python setup.py sdist_deb would know what package dependencies it
needs to add to the resulting .deb file.

> Regards,
> Gerry
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From strawman at astraw.com  Mon Sep 28 18:33:54 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 09:33:54 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4ABBA345.4040906@trueblade.com>	
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>	
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>	
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>	
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>	
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
Message-ID: <4AC0E572.4010401@astraw.com>

Olof Bjarnason wrote:
> 2009/9/28 Gerry Reno <greno at verizon.net>:
>   
>>> Just pass the arguments directly to sdist_dsc. It should be something
>>> like this:
>>>
>>> python setup.py sdist_dsc --ignore-single-version-externally-managed
>>> --ignore-install-requires bdist_deb
>>>
>>>       
>> How's that going to work?  You have 'sdist_dsc' on the command line as well
>> as 'bdist_deb'.   'bdist_deb' also calls 'sdist_dsc' internally but this
>> time it would be without any arguments?  How can that work?
>>     
This is standard distutils command processing -- this has nothing to do
with stdeb per se. The reason I gave an example not involving stdeb
(which was snipped out by you in your quote above) is so that you can
try it yourself and explore further without thinking it's somehow an
stdeb issue. Specifically, you do not need to understand anything
specific to stdeb to understand how to pass multiple arguments to
sub-commands of a distutils command. (And if stdeb handles things
differently, it's a bug and I would appreciate hearing about it.)

For example, "build_ext" is a sub-command of "install" that get called
to build extension modules prior to installation. (Being a sub-command
is not strictly true in the sense that the install command doesn't list
build_ext in its sub_commands in distutils/commands/install.py, but it
acts as if it's true.) Likewise, "sdist_dsc" is a sub-command of
"bdist_deb". In all cases one, might want to pass arguments to the
sub-command before running a later command. distutils allows this.

>> OK I know I'm a noob on *nix distribution of python apps', but:
>>
>> Would it be possible to extend setup.py with info for package dependency?
>>
>> Then python setup.py sdist_deb would know what package dependencies it
>> needs to add to the resulting .deb file.
>>     
Read the README.rst that is shipped with stdeb, specifically the section
"Customizing the produced Debian source package (config options)". You
want the "Depends" field in the stdeb.cfg file. (This will presumably be
back online at the stdeb homepage at http://github.com/astraw/stdeb
also, once github's move to rackspace is complete.)

There is also some stuff to automatically attempt to find dependencies
based on the setuptools install_requires fields.

-Andrew

From greno at verizon.net  Mon Sep 28 19:08:36 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 13:08:36 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0E572.4010401@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBA345.4040906@trueblade.com>
	<94bdd2610909241021i25a18d6fkfdc0638ad85bcdc5@mail.gmail.com>
	<4ABBD78B.4030902@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com>
Message-ID: <4AC0ED94.5050405@verizon.net>

Andrew Straw wrote:
> Olof Bjarnason wrote:
>> 2009/9/28 Gerry Reno <greno at verizon.net>:
>>   
>>>> Just pass the arguments directly to sdist_dsc. It should be something
>>>> like this:
>>>>
>>>> python setup.py sdist_dsc --ignore-single-version-externally-managed
>>>> --ignore-install-requires bdist_deb
>>>>
>>>>       
>>> How's that going to work?  You have 'sdist_dsc' on the command line as well
>>> as 'bdist_deb'.   'bdist_deb' also calls 'sdist_dsc' internally but this
>>> time it would be without any arguments?  How can that work?
>>>     
> This is standard distutils command processing -- this has nothing to do
> with stdeb per se. The reason I gave an example not involving stdeb
> (which was snipped out by you in your quote above) is so that you can
> try it yourself and explore further without thinking it's somehow an
> stdeb issue. Specifically, you do not need to understand anything
> specific to stdeb to understand how to pass multiple arguments to
> sub-commands of a distutils command. (And if stdeb handles things
> differently, it's a bug and I would appreciate hearing about it.)
>
> For example, "build_ext" is a sub-command of "install" that get called
> to build extension modules prior to installation. (Being a sub-command
> is not strictly true in the sense that the install command doesn't list
> build_ext in its sub_commands in distutils/commands/install.py, but it
> acts as if it's true.) Likewise, "sdist_dsc" is a sub-command of
> "bdist_deb". In all cases one, might want to pass arguments to the
> sub-command before running a later command. distutils allows this.
>
Ok, the commands behave like makefile rules, once run they don't run 
again. 

But there are still several issues here:

Remember that I said that my goal with 'bdist_deb' was for users to have 
a SINGLE command to generate a .deb.

What needs to be achieved is for a command like this:
$ python setup.py  bdist_deb
OR
$ python setup.py  bdist_deb  --ignore-single-version-externally-managed

to be possible.  'bdist_deb' would call sdist_dsc internally with the 
necessary args WITHOUT having to explicitly put 'sdist_dsc' on the 
command line.

This is how I was expecting that you would implement the bdist_deb 
command inside of stdeb.


Another issue:  In util.py on line 962 (gerry-reno git):
%(setup_env_vars)spython$* -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \\

Maybe it should be like this (note semicolon splitting line into two 
statements):
%(setup_env_vars)s;    python$* -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \\

Otherwise any of the env vars don't seem to be in effect for the  line 
itself.   If you put any of the env vars in the line, they don't expand 
to the value set in set_env_vars.  They expand to previous value or to null.


Regards,
Gerry


From olof.bjarnason at gmail.com  Mon Sep 28 20:12:14 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Mon, 28 Sep 2009 20:12:14 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0ED94.5050405@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
Message-ID: <c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>

2009/9/28 Gerry Reno <greno at verizon.net>:
> Andrew Straw wrote:
>>
>> Olof Bjarnason wrote:
>>>
>>> 2009/9/28 Gerry Reno <greno at verizon.net>:
>>>
>>>>>
>>>>> Just pass the arguments directly to sdist_dsc. It should be something
>>>>> like this:
>>>>>
>>>>> python setup.py sdist_dsc --ignore-single-version-externally-managed
>>>>> --ignore-install-requires bdist_deb
>>>>>
>>>>>
>>>>
>>>> How's that going to work? ?You have 'sdist_dsc' on the command line as
>>>> well
>>>> as 'bdist_deb'. ? 'bdist_deb' also calls 'sdist_dsc' internally but this
>>>> time it would be without any arguments? ?How can that work?
>>>>
>>
>> This is standard distutils command processing -- this has nothing to do
>> with stdeb per se. The reason I gave an example not involving stdeb
>> (which was snipped out by you in your quote above) is so that you can
>> try it yourself and explore further without thinking it's somehow an
>> stdeb issue. Specifically, you do not need to understand anything
>> specific to stdeb to understand how to pass multiple arguments to
>> sub-commands of a distutils command. (And if stdeb handles things
>> differently, it's a bug and I would appreciate hearing about it.)
>>
>> For example, "build_ext" is a sub-command of "install" that get called
>> to build extension modules prior to installation. (Being a sub-command
>> is not strictly true in the sense that the install command doesn't list
>> build_ext in its sub_commands in distutils/commands/install.py, but it
>> acts as if it's true.) Likewise, "sdist_dsc" is a sub-command of
>> "bdist_deb". In all cases one, might want to pass arguments to the
>> sub-command before running a later command. distutils allows this.
>>
> Ok, the commands behave like makefile rules, once run they don't run again.
> But there are still several issues here:
>
> Remember that I said that my goal with 'bdist_deb' was for users to have a
> SINGLE command to generate a .deb.
>
> What needs to be achieved is for a command like this:
> $ python setup.py ?bdist_deb
> OR
> $ python setup.py ?bdist_deb ?--ignore-single-version-externally-managed
>
> to be possible. ?'bdist_deb' would call sdist_dsc internally with the
> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the command
> line.

This would be _exactly_ what I'm looking for :)

But how would you know what package dependencies the python application has?
Also, would it be a binary or source distribution package..?

>
> This is how I was expecting that you would implement the bdist_deb command
> inside of stdeb.
>
>
> Another issue: ?In util.py on line 962 (gerry-reno git):
> %(setup_env_vars)spython$* -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> install \\
>
> Maybe it should be like this (note semicolon splitting line into two
> statements):
> %(setup_env_vars)s; ? ?python$* -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> install \\
>
> Otherwise any of the env vars don't seem to be in effect for the ?line
> itself. ? If you put any of the env vars in the line, they don't expand to
> the value set in set_env_vars. ?They expand to previous value or to null.
>
>
> Regards,
> Gerry
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From greno at verizon.net  Mon Sep 28 20:24:16 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 14:24:16 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
Message-ID: <4AC0FF50.5020906@verizon.net>

Olof Bjarnason wrote:
>   
>> Ok, the commands behave like makefile rules, once run they don't run again.
>> But there are still several issues here:
>>
>> Remember that I said that my goal with 'bdist_deb' was for users to have a
>> SINGLE command to generate a .deb.
>>
>> What needs to be achieved is for a command like this:
>> $ python setup.py  bdist_deb
>> OR
>> $ python setup.py  bdist_deb  --ignore-single-version-externally-managed
>>
>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the command
>> line.
>>     
>
> This would be _exactly_ what I'm looking for :)
>   

I know.  I've had many of my users requesting exactly the same thing as 
well and I've been pursuing this for months now and when I got a 
'bdist_deb' working with stdeb I knew I was getting close.  It just 
needs a little more tweeking and I think we'll have it.  Let's wait and 
see what Andrew says here.


Regards,
Gerry


From strawman at astraw.com  Mon Sep 28 20:53:22 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 11:53:22 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC0FF50.5020906@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net>
Message-ID: <4AC10622.5080807@astraw.com>

Gerry Reno wrote:
> Olof Bjarnason wrote:
>>  
>>> Ok, the commands behave like makefile rules, once run they don't run
>>> again.
>>> But there are still several issues here:
>>>
>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>> have a
>>> SINGLE command to generate a .deb.
>>>
>>> What needs to be achieved is for a command like this:
>>> $ python setup.py  bdist_deb
>>> OR
>>> $ python setup.py  bdist_deb 
>>> --ignore-single-version-externally-managed
>>>
>>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>> command
>>> line.
>>>     
>>
>> This would be _exactly_ what I'm looking for :)
>>   
>
> I know.  I've had many of my users requesting exactly the same thing
> as well and I've been pursuing this for months now and when I got a
> 'bdist_deb' working with stdeb I knew I was getting close.  It just
> needs a little more tweeking and I think we'll have it.  Let's wait
> and see what Andrew says here.
I don't understand what you're waiting on me for at this point.

Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
--single-version-externally-managed option anyway and therefore doesn't
support the "--ignore-single-version-externally-managed" option. I don't
understand why you need to pass
"--ignore-single-version-externally-managed". "python setup.py
bdist_deb" should work for you. Please report with specific information
about expected and actual behavior if things are not working to your
desire (taking care to read the, admittedly minimal, documentation in
README.rst).

Gerry -- I don't understand why you want to subvert the normal distutils
way of doing things. Passing arguments to bdist_deb that are really
arguments to sdist_dsc just isn't the way distutils does things. You're
asking for the equivalent of being able to pass arguments to the
distutils install command that are ultimately intended for the distutils
build_ext command. If you want to test (and possibly implement)
functionality such as adding a [sdist_dsc] section to setup.cfg where
these options could just live so that you don't need to pass arguments
at the command line, thats would be welcome.

Gerry, point 2 -- I still think you're not looking at your own big
picture here -- AFAIK, you are bending over backwards to attempt to pass
the "--ignore-single-version-externally-managed" so that you don't have
to import setuptools in your setup.py file to avoid the monkeypatching
that setuptools does. But, setuptools is explicitly imported in the
debian/rules files created in stdeb 0.3.x. I get the impression that
you're fixated on this argument passing business and not looking at the
bigger picture of the architecture involved and whether your ultimate
goal is even achievable with stdeb 0.3.x.

-Andrew

From greno at verizon.net  Mon Sep 28 21:08:40 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 15:08:40 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC10622.5080807@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
Message-ID: <4AC109B8.7060807@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Olof Bjarnason wrote:
>>     
>>>  
>>>       
>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>> again.
>>>> But there are still several issues here:
>>>>
>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>> have a
>>>> SINGLE command to generate a .deb.
>>>>
>>>> What needs to be achieved is for a command like this:
>>>> $ python setup.py  bdist_deb
>>>> OR
>>>> $ python setup.py  bdist_deb 
>>>> --ignore-single-version-externally-managed
>>>>
>>>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>> command
>>>> line.
>>>>     
>>>>         
>>> This would be _exactly_ what I'm looking for :)
>>>   
>>>       
>> I know.  I've had many of my users requesting exactly the same thing
>> as well and I've been pursuing this for months now and when I got a
>> 'bdist_deb' working with stdeb I knew I was getting close.  It just
>> needs a little more tweeking and I think we'll have it.  Let's wait
>> and see what Andrew says here.
>>     
> I don't understand what you're waiting on me for at this point.
>
> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
> --single-version-externally-managed option anyway and therefore doesn't
> support the "--ignore-single-version-externally-managed" option. I don't
> understand why you need to pass
> "--ignore-single-version-externally-managed". "python setup.py
> bdist_deb" should work for you. Please report with specific information
> about expected and actual behavior if things are not working to your
> desire (taking care to read the, admittedly minimal, documentation in
> README.rst).
>
> Gerry -- I don't understand why you want to subvert the normal distutils
> way of doing things. Passing arguments to bdist_deb that are really
> arguments to sdist_dsc just isn't the way distutils does things. 
Please explain this then.  Why EVEN bother to call 'sdist_dsc' from 
within 'bdist_deb' if you cannot somehow pass arguments to the internal 
'sdist_dsc' call?


> You're
> asking for the equivalent of being able to pass arguments to the
> distutils install command that are ultimately intended for the distutils
> build_ext command. If you want to test (and possibly implement)
> functionality such as adding a [sdist_dsc] section to setup.cfg where
> these options could just live so that you don't need to pass arguments
> at the command line, thats would be welcome.
>
> Gerry, point 2 -- I still think you're not looking at your own big
> picture here -- AFAIK, you are bending over backwards to attempt to pass
> the "--ignore-single-version-externally-managed" so that you don't have
> to import setuptools in your setup.py file to avoid the monkeypatching
> that setuptools does. 
Stop. NO.  IF I import stdeb in the setup.py THEN any local distutils 
install class gets an error:
--single-version-externally-managed not recognized (or something 
similar).  The only way to get by this is by passing in the NEW option 
that I made, '--ignore-single-version-externally-managed' which removes 
this option from the install command which then allows the install to 
succeed.   This is because it looks like stdeb hijacks the distutils 
install command.


> But, setuptools is explicitly imported in the
> debian/rules files created in stdeb 0.3.x. I get the impression that
> you're fixated on this argument passing business and not looking at the
> bigger picture of the architecture involved and whether your ultimate
> goal is even achievable with stdeb 0.3.x.
>
>   
Regards,
Gerry


From olof.bjarnason at gmail.com  Mon Sep 28 21:44:32 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Mon, 28 Sep 2009 21:44:32 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC10622.5080807@astraw.com>
References: <4AB30240.8020807@verizon.net> <4AC0CDE6.2010604@verizon.net>
	<4AC0D48F.90000@astraw.com> <4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
Message-ID: <c3dfe1d0909281244t7a3ce467y2e3e1fe65e3fdb10@mail.gmail.com>

2009/9/28 Andrew Straw <strawman at astraw.com>:
> Gerry Reno wrote:
>> Olof Bjarnason wrote:
>>>
>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>> again.
>>>> But there are still several issues here:
>>>>
>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>> have a
>>>> SINGLE command to generate a .deb.
>>>>
>>>> What needs to be achieved is for a command like this:
>>>> $ python setup.py ?bdist_deb
>>>> OR
>>>> $ python setup.py ?bdist_deb
>>>> --ignore-single-version-externally-managed
>>>>
>>>> to be possible. ?'bdist_deb' would call sdist_dsc internally with the
>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>> command
>>>> line.
>>>>
>>>
>>> This would be _exactly_ what I'm looking for :)
>>>
>>
>> I know. ?I've had many of my users requesting exactly the same thing
>> as well and I've been pursuing this for months now and when I got a
>> 'bdist_deb' working with stdeb I knew I was getting close. ?It just
>> needs a little more tweeking and I think we'll have it. ?Let's wait
>> and see what Andrew says here.
> I don't understand what you're waiting on me for at this point.
>
> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
> --single-version-externally-managed option anyway and therefore doesn't
> support the "--ignore-single-version-externally-managed" option. I don't
> understand why you need to pass
> "--ignore-single-version-externally-managed". "python setup.py
> bdist_deb" should work for you. Please report with specific information
> about expected and actual behavior if things are not working to your
> desire (taking care to read the, admittedly minimal, documentation in
> README.rst).

I tried "stdeb_run_setup", it got me a lot of files (and directories)
although no .deb file.

Also tried "python setup.py bdist_deb" and ".. sdist_deb". Didn't work.

What is the command line I'm supposed to run in the setup.py directory?

Note: I'm a newbee on these tools, spent a total <1 hr so far on 'em,
sorry for being so thick. It is a whole jungle to understand all these
different tools/nomenclature and how it all hangs together. I'm new to
distutils, setuptools, stdeb and .deb building in general.

>
> Gerry -- I don't understand why you want to subvert the normal distutils
> way of doing things. Passing arguments to bdist_deb that are really
> arguments to sdist_dsc just isn't the way distutils does things. You're
> asking for the equivalent of being able to pass arguments to the
> distutils install command that are ultimately intended for the distutils
> build_ext command. If you want to test (and possibly implement)
> functionality such as adding a [sdist_dsc] section to setup.cfg where
> these options could just live so that you don't need to pass arguments
> at the command line, thats would be welcome.
>
> Gerry, point 2 -- I still think you're not looking at your own big
> picture here -- AFAIK, you are bending over backwards to attempt to pass
> the "--ignore-single-version-externally-managed" so that you don't have
> to import setuptools in your setup.py file to avoid the monkeypatching
> that setuptools does. But, setuptools is explicitly imported in the
> debian/rules files created in stdeb 0.3.x. I get the impression that
> you're fixated on this argument passing business and not looking at the
> bigger picture of the architecture involved and whether your ultimate
> goal is even achievable with stdeb 0.3.x.
>
> -Andrew
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From olof.bjarnason at gmail.com  Mon Sep 28 21:56:53 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Mon, 28 Sep 2009 21:56:53 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <c3dfe1d0909281244t7a3ce467y2e3e1fe65e3fdb10@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<c3dfe1d0909281244t7a3ce467y2e3e1fe65e3fdb10@mail.gmail.com>
Message-ID: <c3dfe1d0909281256l2cac13d3wab55e51535073a9@mail.gmail.com>

2009/9/28 Olof Bjarnason <olof.bjarnason at gmail.com>:
> 2009/9/28 Andrew Straw <strawman at astraw.com>:
>> Gerry Reno wrote:
>>> Olof Bjarnason wrote:
>>>>
>>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>>> again.
>>>>> But there are still several issues here:
>>>>>
>>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>>> have a
>>>>> SINGLE command to generate a .deb.
>>>>>
>>>>> What needs to be achieved is for a command like this:
>>>>> $ python setup.py ?bdist_deb
>>>>> OR
>>>>> $ python setup.py ?bdist_deb
>>>>> --ignore-single-version-externally-managed
>>>>>
>>>>> to be possible. ?'bdist_deb' would call sdist_dsc internally with the
>>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>>> command
>>>>> line.
>>>>>
>>>>
>>>> This would be _exactly_ what I'm looking for :)
>>>>
>>>
>>> I know. ?I've had many of my users requesting exactly the same thing
>>> as well and I've been pursuing this for months now and when I got a
>>> 'bdist_deb' working with stdeb I knew I was getting close. ?It just
>>> needs a little more tweeking and I think we'll have it. ?Let's wait
>>> and see what Andrew says here.
>> I don't understand what you're waiting on me for at this point.
>>
>> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
>> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
>> --single-version-externally-managed option anyway and therefore doesn't
>> support the "--ignore-single-version-externally-managed" option. I don't
>> understand why you need to pass
>> "--ignore-single-version-externally-managed". "python setup.py
>> bdist_deb" should work for you. Please report with specific information
>> about expected and actual behavior if things are not working to your
>> desire (taking care to read the, admittedly minimal, documentation in
>> README.rst).
>
> I tried "stdeb_run_setup", it got me a lot of files (and directories)
> although no .deb file.
>
> Also tried "python setup.py bdist_deb" and ".. sdist_deb". Didn't work.
>
> What is the command line I'm supposed to run in the setup.py directory?

OK I came a little further apt-get:ing debhelper and python-all-dev,
then issuing

sudo python -c "import stdeb; execfile('setup.py')" bdist_deb

.. but it ended with this:

Compatibility mode: using detected XS-Python-Version.
   dh_scrollkeeper
   dh_usrlocal
   dh_link
   dh_compress
   dh_fixperms
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   dh_gencontrol
   dh_md5sums
   dh_builddeb
varning, "debian/python-fortressdefender/DEBIAN/control" inneh?ller
anv?ndardefinierat f?lt "Python-Version"
dpkg-deb - fel: (upstream) version ("dev") inneh?ller inga siffror
dpkg-deb: 1 fel i kontrollfilen
dh_builddeb: command returned error code 512
make: *** [binary] Fel 1
dpkg-buildpackage: misslyckades: fakeroot debian/rules binary
returnerade felkod 2
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "setup.py", line 42, in <module>
    scripts = ["bin/fortressdefender"],
  File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "build/bdist.linux-x86_64/egg/stdeb/command/bdist_deb.py", line
40, in run
  File "build/bdist.linux-x86_64/egg/stdeb/util.py", line 73, in process_command
  File "build/bdist.linux-x86_64/egg/stdeb/util.py", line 31, in check_call
stdeb.util.CalledProcessError: 2


>
> Note: I'm a newbee on these tools, spent a total <1 hr so far on 'em,
> sorry for being so thick. It is a whole jungle to understand all these
> different tools/nomenclature and how it all hangs together. I'm new to
> distutils, setuptools, stdeb and .deb building in general.
>
>>
>> Gerry -- I don't understand why you want to subvert the normal distutils
>> way of doing things. Passing arguments to bdist_deb that are really
>> arguments to sdist_dsc just isn't the way distutils does things. You're
>> asking for the equivalent of being able to pass arguments to the
>> distutils install command that are ultimately intended for the distutils
>> build_ext command. If you want to test (and possibly implement)
>> functionality such as adding a [sdist_dsc] section to setup.cfg where
>> these options could just live so that you don't need to pass arguments
>> at the command line, thats would be welcome.
>>
>> Gerry, point 2 -- I still think you're not looking at your own big
>> picture here -- AFAIK, you are bending over backwards to attempt to pass
>> the "--ignore-single-version-externally-managed" so that you don't have
>> to import setuptools in your setup.py file to avoid the monkeypatching
>> that setuptools does. But, setuptools is explicitly imported in the
>> debian/rules files created in stdeb 0.3.x. I get the impression that
>> you're fixated on this argument passing business and not looking at the
>> bigger picture of the architecture involved and whether your ultimate
>> goal is even achievable with stdeb 0.3.x.
>>
>> -Andrew
>>
>
>
>
> --
> twitter.com/olofb
> olofb.wordpress.com
> olofb.wordpress.com/tag/english
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From strawman at astraw.com  Mon Sep 28 21:59:53 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 12:59:53 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC109B8.7060807@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net>
Message-ID: <4AC115B9.6000307@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> Olof Bjarnason wrote:
>>>    
>>>>  
>>>>      
>>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>>> again.
>>>>> But there are still several issues here:
>>>>>
>>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>>> have a
>>>>> SINGLE command to generate a .deb.
>>>>>
>>>>> What needs to be achieved is for a command like this:
>>>>> $ python setup.py  bdist_deb
>>>>> OR
>>>>> $ python setup.py  bdist_deb
>>>>> --ignore-single-version-externally-managed
>>>>>
>>>>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>>> command
>>>>> line.
>>>>>             
>>>> This would be _exactly_ what I'm looking for :)
>>>>         
>>> I know.  I've had many of my users requesting exactly the same thing
>>> as well and I've been pursuing this for months now and when I got a
>>> 'bdist_deb' working with stdeb I knew I was getting close.  It just
>>> needs a little more tweeking and I think we'll have it.  Let's wait
>>> and see what Andrew says here.
>>>     
>> I don't understand what you're waiting on me for at this point.
>>
>> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
>> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
>> --single-version-externally-managed option anyway and therefore doesn't
>> support the "--ignore-single-version-externally-managed" option. I don't
>> understand why you need to pass
>> "--ignore-single-version-externally-managed". "python setup.py
>> bdist_deb" should work for you. Please report with specific information
>> about expected and actual behavior if things are not working to your
>> desire (taking care to read the, admittedly minimal, documentation in
>> README.rst).
>>
>> Gerry -- I don't understand why you want to subvert the normal distutils
>> way of doing things. Passing arguments to bdist_deb that are really
>> arguments to sdist_dsc just isn't the way distutils does things. 
> Please explain this then.  Why EVEN bother to call 'sdist_dsc' from
> within 'bdist_deb' if you cannot somehow pass arguments to the
> internal 'sdist_dsc' call?
You can. "python setup.py commandA --option-for-command-A commandB
--option-for-command-B". This is just how distutils works. This is not
an stdeb issue. If you don't need to pass options to commandA, but
commandA is still a sub-command of commandB, then commandA will still
get called, just without any options. As I said, you can also pass
options by placing them in the appropriate setup.cfg location.

For example:

python setup.py build_py --build-lib=zzz bdist_dumb

is exactly equivalent to

python setup.py bdist_dumb

with if setup.cfg file contains:

[build_py]
build-lib=zzz

Because build_py A) is a sub-command of bdist_dumb and therefore gets
run and B) picks up its options using the standard distutils mechanisms,
either from the command line or setup.cfg.

>
>
>> You're
>> asking for the equivalent of being able to pass arguments to the
>> distutils install command that are ultimately intended for the distutils
>> build_ext command. If you want to test (and possibly implement)
>> functionality such as adding a [sdist_dsc] section to setup.cfg where
>> these options could just live so that you don't need to pass arguments
>> at the command line, thats would be welcome.
>>
>> Gerry, point 2 -- I still think you're not looking at your own big
>> picture here -- AFAIK, you are bending over backwards to attempt to pass
>> the "--ignore-single-version-externally-managed" so that you don't have
>> to import setuptools in your setup.py file to avoid the monkeypatching
>> that setuptools does. 
> Stop. NO.  IF I import stdeb in the setup.py THEN any local distutils
> install class gets an error:
> --single-version-externally-managed not recognized (or something
> similar).
So why don't you just derive from setuptools' install command (rather
than distutils' install command) if you insist on using stdeb 0.3? I
think this will solve all your problems in a much simpler way.

> The only way to get by this is by passing in the NEW option that I
> made, '--ignore-single-version-externally-managed' which removes this
> option from the install command which then allows the install to
> succeed.   This is because it looks like stdeb hijacks the distutils
> install command.

I have yet to see a working patch that I can actually test that backs up
your assertion. As it is, I simply don't believe you because the
debian/rules created by stdeb 0.3 not only passes that option, but it
also explicitly imports setuptools. The setuptools install command does
know the --single-version-externally-managed option. (I think in your
memory of what worked, you are forgetting that you also removed the
"import setuptools".)

-Andrew

From strawman at astraw.com  Mon Sep 28 22:04:57 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 13:04:57 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <c3dfe1d0909281256l2cac13d3wab55e51535073a9@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4AC0D48F.90000@astraw.com>	
	<4AC0DEE9.5060800@verizon.net>	
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>	
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>	
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>	
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>	
	<c3dfe1d0909281244t7a3ce467y2e3e1fe65e3fdb10@mail.gmail.com>
	<c3dfe1d0909281256l2cac13d3wab55e51535073a9@mail.gmail.com>
Message-ID: <4AC116E9.9020401@astraw.com>

Olof Bjarnason wrote:
> 2009/9/28 Olof Bjarnason <olof.bjarnason at gmail.com>:
>   
>> 2009/9/28 Andrew Straw <strawman at astraw.com>:
>>     
>>> Gerry Reno wrote:
>>>       
>>>> Olof Bjarnason wrote:
>>>>         
>>>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>>>> again.
>>>>>> But there are still several issues here:
>>>>>>
>>>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>>>> have a
>>>>>> SINGLE command to generate a .deb.
>>>>>>
>>>>>> What needs to be achieved is for a command like this:
>>>>>> $ python setup.py  bdist_deb
>>>>>> OR
>>>>>> $ python setup.py  bdist_deb
>>>>>> --ignore-single-version-externally-managed
>>>>>>
>>>>>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>>>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>>>> command
>>>>>> line.
>>>>>>
>>>>>>             
>>>>> This would be _exactly_ what I'm looking for :)
>>>>>
>>>>>           
>>>> I know.  I've had many of my users requesting exactly the same thing
>>>> as well and I've been pursuing this for months now and when I got a
>>>> 'bdist_deb' working with stdeb I knew I was getting close.  It just
>>>> needs a little more tweeking and I think we'll have it.  Let's wait
>>>> and see what Andrew says here.
>>>>         
>>> I don't understand what you're waiting on me for at this point.
>>>
>>> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
>>> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
>>> --single-version-externally-managed option anyway and therefore doesn't
>>> support the "--ignore-single-version-externally-managed" option. I don't
>>> understand why you need to pass
>>> "--ignore-single-version-externally-managed". "python setup.py
>>> bdist_deb" should work for you. Please report with specific information
>>> about expected and actual behavior if things are not working to your
>>> desire (taking care to read the, admittedly minimal, documentation in
>>> README.rst).
>>>       
>> I tried "stdeb_run_setup", it got me a lot of files (and directories)
>> although no .deb file.
>>
>> Also tried "python setup.py bdist_deb" and ".. sdist_deb". Didn't work.
>>
>> What is the command line I'm supposed to run in the setup.py directory?
>>     
>
> OK I came a little further apt-get:ing debhelper and python-all-dev,
> then issuing
>
> sudo python -c "import stdeb; execfile('setup.py')" bdist_deb
>
> .. but it ended with this:
>
> Compatibility mode: using detected XS-Python-Version.
>    dh_scrollkeeper
>    dh_usrlocal
>    dh_link
>    dh_compress
>    dh_fixperms
>    dh_strip
>    dh_makeshlibs
>    dh_shlibdeps
>    dh_installdeb
>    dh_gencontrol
>    dh_md5sums
>    dh_builddeb
> varning, "debian/python-fortressdefender/DEBIAN/control" inneh?ller
> anv?ndardefinierat f?lt "Python-Version"
> dpkg-deb - fel: (upstream) version ("dev") inneh?ller inga siffror
> dpkg-deb: 1 fel i kontrollfilen
> dh_builddeb: command returned error code 512
> make: *** [binary] Fel 1
> dpkg-buildpackage: misslyckades: fakeroot debian/rules binary
> returnerade felkod 2
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "setup.py", line 42, in <module>
>     scripts = ["bin/fortressdefender"],
>   File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
>     dist.run_commands()
>   File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
>     self.run_command(cmd)
>   File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
>     cmd_obj.run()
>   File "build/bdist.linux-x86_64/egg/stdeb/command/bdist_deb.py", line
> 40, in run
>   File "build/bdist.linux-x86_64/egg/stdeb/util.py", line 73, in process_command
>   File "build/bdist.linux-x86_64/egg/stdeb/util.py", line 31, in check_call
> stdeb.util.CalledProcessError: 2
>
>
>   
please do:

sudo apt-get install build-essential
sudo apt-get install fakeroot

And try again.

-Andrew

From olof.bjarnason at gmail.com  Mon Sep 28 22:13:22 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Mon, 28 Sep 2009 22:13:22 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC116E9.9020401@astraw.com>
References: <4AB30240.8020807@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<c3dfe1d0909281244t7a3ce467y2e3e1fe65e3fdb10@mail.gmail.com>
	<c3dfe1d0909281256l2cac13d3wab55e51535073a9@mail.gmail.com>
	<4AC116E9.9020401@astraw.com>
Message-ID: <c3dfe1d0909281313y6a6a32adk23cb2d75802a8984@mail.gmail.com>

2009/9/28 Andrew Straw <strawman at astraw.com>:
> Olof Bjarnason wrote:
>> 2009/9/28 Olof Bjarnason <olof.bjarnason at gmail.com>:
>>
>>> 2009/9/28 Andrew Straw <strawman at astraw.com>:
>>>
>>>> Gerry Reno wrote:
>>>>
>>>>> Olof Bjarnason wrote:
>>>>>
>>>>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>>>>> again.
>>>>>>> But there are still several issues here:
>>>>>>>
>>>>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>>>>> have a
>>>>>>> SINGLE command to generate a .deb.
>>>>>>>
>>>>>>> What needs to be achieved is for a command like this:
>>>>>>> $ python setup.py ?bdist_deb
>>>>>>> OR
>>>>>>> $ python setup.py ?bdist_deb
>>>>>>> --ignore-single-version-externally-managed
>>>>>>>
>>>>>>> to be possible. ?'bdist_deb' would call sdist_dsc internally with the
>>>>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>>>>> command
>>>>>>> line.
>>>>>>>
>>>>>>>
>>>>>> This would be _exactly_ what I'm looking for :)
>>>>>>
>>>>>>
>>>>> I know. ?I've had many of my users requesting exactly the same thing
>>>>> as well and I've been pursuing this for months now and when I got a
>>>>> 'bdist_deb' working with stdeb I knew I was getting close. ?It just
>>>>> needs a little more tweeking and I think we'll have it. ?Let's wait
>>>>> and see what Andrew says here.
>>>>>
>>>> I don't understand what you're waiting on me for at this point.
>>>>
>>>> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
>>>> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
>>>> --single-version-externally-managed option anyway and therefore doesn't
>>>> support the "--ignore-single-version-externally-managed" option. I don't
>>>> understand why you need to pass
>>>> "--ignore-single-version-externally-managed". "python setup.py
>>>> bdist_deb" should work for you. Please report with specific information
>>>> about expected and actual behavior if things are not working to your
>>>> desire (taking care to read the, admittedly minimal, documentation in
>>>> README.rst).
>>>>
>>> I tried "stdeb_run_setup", it got me a lot of files (and directories)
>>> although no .deb file.
>>>
>>> Also tried "python setup.py bdist_deb" and ".. sdist_deb". Didn't work.
>>>
>>> What is the command line I'm supposed to run in the setup.py directory?
>>>
>>
>> OK I came a little further apt-get:ing debhelper and python-all-dev,
>> then issuing
>>
>> sudo python -c "import stdeb; execfile('setup.py')" bdist_deb
>>
>> .. but it ended with this:
>>
>> Compatibility mode: using detected XS-Python-Version.
>> ? ?dh_scrollkeeper
>> ? ?dh_usrlocal
>> ? ?dh_link
>> ? ?dh_compress
>> ? ?dh_fixperms
>> ? ?dh_strip
>> ? ?dh_makeshlibs
>> ? ?dh_shlibdeps
>> ? ?dh_installdeb
>> ? ?dh_gencontrol
>> ? ?dh_md5sums
>> ? ?dh_builddeb
>> varning, "debian/python-fortressdefender/DEBIAN/control" inneh?ller
>> anv?ndardefinierat f?lt "Python-Version"
>> dpkg-deb - fel: (upstream) version ("dev") inneh?ller inga siffror
>> dpkg-deb: 1 fel i kontrollfilen
>> dh_builddeb: command returned error code 512
>> make: *** [binary] Fel 1
>> dpkg-buildpackage: misslyckades: fakeroot debian/rules binary
>> returnerade felkod 2
>> Traceback (most recent call last):
>> ? File "<string>", line 1, in <module>
>> ? File "setup.py", line 42, in <module>
>> ? ? scripts = ["bin/fortressdefender"],
>> ? File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
>> ? ? dist.run_commands()
>> ? File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
>> ? ? self.run_command(cmd)
>> ? File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
>> ? ? cmd_obj.run()
>> ? File "build/bdist.linux-x86_64/egg/stdeb/command/bdist_deb.py", line
>> 40, in run
>> ? File "build/bdist.linux-x86_64/egg/stdeb/util.py", line 73, in process_command
>> ? File "build/bdist.linux-x86_64/egg/stdeb/util.py", line 31, in check_call
>> stdeb.util.CalledProcessError: 2
>>
>>
>>
> please do:
>
> sudo apt-get install build-essential
> sudo apt-get install fakeroot

Did both, added no package to my system.

(I guess you are intending to supply a stdeb.deb in the future to fix
all dependencies ;) ?

It would be slick with a script that did this command line:

sudo python -c "import stdeb; execfile('setup.py')" bdist_deb)

I'm going to bed over here. Attaching the whole dump of the above command line.


>
> And try again.
>
> -Andrew
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english
-------------- next part --------------
olof at olof-desktop:~/prj/fd/fortressdefender$ sudo python -c "import stdeb; execfile('setup.py')" bdist_deb
['Constants.py', 'Point.py', 'SoundPlayer.py', 'Entity.py', 'FixY.py', 'CloseActionTrigger.py', 'setup.py', 'MouseEventHandler.py', 'FakeDrawer.py', 'RunAllUnitTests.py', 'Spring.py', 'Colors.py', 'Drawer.py', 'Ball.py', 'Run.pyw']
running bdist_deb
running sdist_dsc
running egg_info
writing fortressdefender.egg-info/PKG-INFO
writing top-level names to fortressdefender.egg-info/top_level.txt
writing dependency_links to fortressdefender.egg-info/dependency_links.txt
warning: manifest_maker: standard file '-c' not found
reading manifest file 'fortressdefender.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'fortressdefender.egg-info/SOURCES.txt'
/usr/local/lib/python2.6/dist-packages/stdeb-0.4-py2.6.egg/stdeb/util.py:630: UserWarning: working around Debian #548392, changing XS-Python-Version: to 'current'
CALLING dpkg-source -b fortressdefender-dev fortressdefender_dev.orig.tar.gz (in dir deb_dist)
dpkg-source: info: anv?nder k?llkodsformatet "1.0"
dpkg-source: info: bygger fortressdefender med befintlig fortressdefender_dev.orig.tar.gz
dpkg-source: info: bygger fortressdefender i fortressdefender_dev-1.diff.gz
dpkg-source: info: bygger fortressdefender i fortressdefender_dev-1.dsc

From greno at verizon.net  Mon Sep 28 22:54:40 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 16:54:40 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC115B9.6000307@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
Message-ID: <4AC12290.3040404@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>> Andrew Straw wrote:
>>> Gerry Reno wrote:
>>>  
>>>> Olof Bjarnason wrote:
>>>>    
>>>>>  
>>>>>      
>>>>>> Ok, the commands behave like makefile rules, once run they don't run
>>>>>> again.
>>>>>> But there are still several issues here:
>>>>>>
>>>>>> Remember that I said that my goal with 'bdist_deb' was for users to
>>>>>> have a
>>>>>> SINGLE command to generate a .deb.
>>>>>>
>>>>>> What needs to be achieved is for a command like this:
>>>>>> $ python setup.py  bdist_deb
>>>>>> OR
>>>>>> $ python setup.py  bdist_deb
>>>>>> --ignore-single-version-externally-managed
>>>>>>
>>>>>> to be possible.  'bdist_deb' would call sdist_dsc internally with the
>>>>>> necessary args WITHOUT having to explicitly put 'sdist_dsc' on the
>>>>>> command
>>>>>> line.
>>>>>>             
>>>>> This would be _exactly_ what I'm looking for :)
>>>>>         
>>>> I know.  I've had many of my users requesting exactly the same thing
>>>> as well and I've been pursuing this for months now and when I got a
>>>> 'bdist_deb' working with stdeb I knew I was getting close.  It just
>>>> needs a little more tweeking and I think we'll have it.  Let's wait
>>>> and see what Andrew says here.
>>>>     
>>> I don't understand what you're waiting on me for at this point.
>>>
>>> Olaf -- as I understand it -- you need to work with Ubuntu 9.04. I just
>>> released stdeb 0.4 which supports this "bdist_deb" and doesn't pass the
>>> --single-version-externally-managed option anyway and therefore doesn't
>>> support the "--ignore-single-version-externally-managed" option. I don't
>>> understand why you need to pass
>>> "--ignore-single-version-externally-managed". "python setup.py
>>> bdist_deb" should work for you. Please report with specific information
>>> about expected and actual behavior if things are not working to your
>>> desire (taking care to read the, admittedly minimal, documentation in
>>> README.rst).
>>>
>>> Gerry -- I don't understand why you want to subvert the normal distutils
>>> way of doing things. Passing arguments to bdist_deb that are really
>>> arguments to sdist_dsc just isn't the way distutils does things. 
>> Please explain this then.  Why EVEN bother to call 'sdist_dsc' from
>> within 'bdist_deb' if you cannot somehow pass arguments to the
>> internal 'sdist_dsc' call?
> You can. "python setup.py commandA --option-for-command-A commandB
> --option-for-command-B". This is just how distutils works. This is not
> an stdeb issue. If you don't need to pass options to commandA, but
> commandA is still a sub-command of commandB, then commandA will still
> get called, just without any options. As I said, you can also pass
> options by placing them in the appropriate setup.cfg location.
>
> For example:
>
> python setup.py build_py --build-lib=zzz bdist_dumb
>
> is exactly equivalent to
>
> python setup.py bdist_dumb
>
> with if setup.cfg file contains:
>
> [build_py]
> build-lib=zzz
>
> Because build_py A) is a sub-command of bdist_dumb and therefore gets
> run and B) picks up its options using the standard distutils mechanisms,
> either from the command line or setup.cfg.

YES, I UNDERSTAND THE MECHANISM.
What if stdeb only had the command 'bdist_deb' and had no other 
command.  Everything else was taken care of internally.  What then?  Are 
you saying then that it is impossible to pass in any options to 
'bdist_deb' to affect the generation of the source package?  If true, 
this makes NO SENSE.




>
>>
>>> You're
>>> asking for the equivalent of being able to pass arguments to the
>>> distutils install command that are ultimately intended for the distutils
>>> build_ext command. If you want to test (and possibly implement)
>>> functionality such as adding a [sdist_dsc] section to setup.cfg where
>>> these options could just live so that you don't need to pass arguments
>>> at the command line, thats would be welcome.
>>>
>>> Gerry, point 2 -- I still think you're not looking at your own big
>>> picture here -- AFAIK, you are bending over backwards to attempt to pass
>>> the "--ignore-single-version-externally-managed" so that you don't have
>>> to import setuptools in your setup.py file to avoid the monkeypatching
>>> that setuptools does. 
>> Stop. NO.  IF I import stdeb in the setup.py THEN any local distutils
>> install class gets an error:
>> --single-version-externally-managed not recognized (or something
>> similar).
> So why don't you just derive from setuptools' install command (rather
> than distutils' install command) if you insist on using stdeb 0.3? I
> think this will solve all your problems in a much simpler way.
Yes, I can see that once we got invaded with setuptools it seems you 
really have no other choice.



>
>> The only way to get by this is by passing in the NEW option that I
>> made, '--ignore-single-version-externally-managed' which removes this
>> option from the install command which then allows the install to
>> succeed.   This is because it looks like stdeb hijacks the distutils
>> install command.
>
> I have yet to see a working patch that I can actually test that backs up
> your assertion. As it is, I simply don't believe you because the
> debian/rules created by stdeb 0.3 not only passes that option, but it
> also explicitly imports setuptools. The setuptools install command does
> know the --single-version-externally-managed option. (I think in your
> memory of what worked, you are forgetting that you also removed the
> "import setuptools".)
>
> -Andrew
>

And getting back to the issue that got skipped:
Another issue:  In util.py on line 962 (gerry-reno git):
%(setup_env_vars)spython$* -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \\

Maybe it should be like this (note semicolon splitting line into two 
statements):
%(setup_env_vars)s;    python$* -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \\

Otherwise any of the env vars don't seem to be in effect for the  line 
itself.   If you put any of the env vars in the line, they don't expand 
to the value set in set_env_vars.  They expand to previous value or to 
null.



Regards,
Gerry


From strawman at astraw.com  Mon Sep 28 23:13:25 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 14:13:25 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC12290.3040404@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net>
Message-ID: <4AC126F5.9040204@astraw.com>

Gerry Reno wrote:
>
> What if stdeb only had the command 'bdist_deb' and had no other command.

I will not remove the "sdist_dsc" command from stdeb. I believe that the
ability to produce debian source packages is much more important that
the ability to produce binary packages which only target a single
architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
add-on to that saving a couple lines of typing which may be helpful to
people who aren't familiar with those lines. But I see the .dsc and
associated files as much more useful as the compiled .deb files.


> Everything else was taken care of internally.  What then?  Are you
> saying then that it is impossible to pass in any options to
> 'bdist_deb' to affect the generation of the source package?  If true,
> this makes NO SENSE.
I still don't understand why you insist the options are to the bdist_deb
command. What is wrong with passing the options to the sdist_dsc command
where they take effect anyway?


> Yes, I can see that once we got invaded with setuptools it seems you
> really have no other choice.
Hang on a minute. The "st" in stdeb is for "setuptools". While in the
0.4 version this may take a less prominent role, and Distribute might be
able to step in, the ontogeny of stdeb is very much tied up with
setuptools. So I'm not comfortable promoting the idea that there ever
existed stdeb without setuptools. Maybe it can happen in the future --
but it's certainly never happened in the past.

> And getting back to the issue that got skipped:
> Another issue:  In util.py on line 962 (gerry-reno git):
> %(setup_env_vars)spython$* -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> install \\
>
> Maybe it should be like this (note semicolon splitting line into two
> statements):
> %(setup_env_vars)s;    python$* -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> install \\
>
> Otherwise any of the env vars don't seem to be in effect for the  line
> itself.   If you put any of the env vars in the line, they don't
> expand to the value set in set_env_vars.  They expand to previous
> value or to null.
For setting environment variables this way, they cannot be separated by
a semicolon.

From greno at verizon.net  Tue Sep 29 00:03:09 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 18:03:09 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC126F5.9040204@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
Message-ID: <4AC1329D.6060809@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> What if stdeb only had the command 'bdist_deb' and had no other command.
>>     
>
> I will not remove the "sdist_dsc" command from stdeb. I believe that the
> ability to produce debian source packages is much more important that
> the ability to produce binary packages which only target a single
> architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
> add-on to that saving a couple lines of typing which may be helpful to
> people who aren't familiar with those lines. But I see the .dsc and
> associated files as much more useful as the compiled .deb files.
>
>
>   
LMAO.  Dang it.  I am not suggesting or implying that you should remove 
the 'sdist_dsc' command.  I'm trying to illustrate that the 
commandA-opts are just that and nothing more: commandA-opts.  And 
whatever part of the build/install process that they apply to, then the 
commandA can use them for WHATEVER purpose.  Which means that since 
'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all 
'sdist_dsc' options to be passed into the 'bdist_deb' command which can 
then pass them along to 'sdist_dsc'.  'bdist_deb' is a SUPERSET of 
'sdist_dsc'.


>> Everything else was taken care of internally.  What then?  Are you
>> saying then that it is impossible to pass in any options to
>> 'bdist_deb' to affect the generation of the source package?  If true,
>> this makes NO SENSE.
>>     
> I still don't understand why you insist the options are to the bdist_deb
> command. What is wrong with passing the options to the sdist_dsc command
> where they take effect anyway?
>
>
>   
>> Yes, I can see that once we got invaded with setuptools it seems you
>> really have no other choice.
>>     
> Hang on a minute. The "st" in stdeb is for "setuptools". While in the
> 0.4 version this may take a less prominent role, and Distribute might be
> able to step in, the ontogeny of stdeb is very much tied up with
> setuptools. So I'm not comfortable promoting the idea that there ever
> existed stdeb without setuptools. Maybe it can happen in the future --
> but it's certainly never happened in the past.
>   
I never said that stdeb ever existing in any other form but that of 
using setuptools.  I was merely making a statement as to the impact that 
this has.

>   
>> And getting back to the issue that got skipped:
>> Another issue:  In util.py on line 962 (gerry-reno git):
>> %(setup_env_vars)spython$* -c "import
>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
>> install \\
>>
>> Maybe it should be like this (note semicolon splitting line into two
>> statements):
>> %(setup_env_vars)s;    python$* -c "import
>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
>> install \\
>>
>> Otherwise any of the env vars don't seem to be in effect for the  line
>> itself.   If you put any of the env vars in the line, they don't
>> expand to the value set in set_env_vars.  They expand to previous
>> value or to null.
>>     
> For setting environment variables this way, they cannot be separated by
> a semicolon
The environment variables are not individually separated by a 
semicolon.  The WHOLE shell script environment variable declaration 
statement needs to be separated from the install line statement.

Simple demonstration of the problem with the 'echo' statement simulating 
the 'install' statement:
$ a='123' b='456' echo test $a $b
test
$ a='123' b='456'; echo test $a $b
test 123 456


Regards,
Gerry


From strawman at astraw.com  Tue Sep 29 00:16:16 2009
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 28 Sep 2009 15:16:16 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC1329D.6060809@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net>
Message-ID: <4AC135B0.2060302@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> What if stdeb only had the command 'bdist_deb' and had no other
>>> command.
>>>     
>>
>> I will not remove the "sdist_dsc" command from stdeb. I believe that the
>> ability to produce debian source packages is much more important that
>> the ability to produce binary packages which only target a single
>> architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
>> add-on to that saving a couple lines of typing which may be helpful to
>> people who aren't familiar with those lines. But I see the .dsc and
>> associated files as much more useful as the compiled .deb files.
>>
>>
>>   
> LMAO.  Dang it.  I am not suggesting or implying that you should
> remove the 'sdist_dsc' command.  I'm trying to illustrate that the
> commandA-opts are just that and nothing more: commandA-opts.  And
> whatever part of the build/install process that they apply to, then
> the commandA can use them for WHATEVER purpose.  Which means that
> since 'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all
> 'sdist_dsc' options to be passed into the 'bdist_deb' command which
> can then pass them along to 'sdist_dsc'.  'bdist_deb' is a SUPERSET of
> 'sdist_dsc'.
I see -- you want to pass-through the options to sdist_dsc. Fine,
implement this in a patch and I'll accept it.


>> For setting environment variables this way, they cannot be separated by
>> a semicolon
> The environment variables are not individually separated by a
> semicolon.  The WHOLE shell script environment variable declaration
> statement needs to be separated from the install line statement.
>
> Simple demonstration of the problem with the 'echo' statement
> simulating the 'install' statement:
> $ a='123' b='456' echo test $a $b
> test
> $ a='123' b='456'; echo test $a $b
> test 123 456

Passing to a subprocess is different. We're passing to a subprocess:

$ a='123' python -c "import os; print os.environ['a']"
123
$ a='123'; python -c "import os; print os.environ['a']"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
    raise KeyError(key)
KeyError: 'a'


From greno at verizon.net  Tue Sep 29 01:11:59 2009
From: greno at verizon.net (Gerry Reno)
Date: Mon, 28 Sep 2009 19:11:59 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC135B0.2060302@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
Message-ID: <4AC142BF.4000004@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Andrew Straw wrote:
>>     
>>> Gerry Reno wrote:
>>>  
>>>       
>>>> What if stdeb only had the command 'bdist_deb' and had no other
>>>> command.
>>>>     
>>>>         
>>> I will not remove the "sdist_dsc" command from stdeb. I believe that the
>>> ability to produce debian source packages is much more important that
>>> the ability to produce binary packages which only target a single
>>> architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
>>> add-on to that saving a couple lines of typing which may be helpful to
>>> people who aren't familiar with those lines. But I see the .dsc and
>>> associated files as much more useful as the compiled .deb files.
>>>
>>>
>>>   
>>>       
>> LMAO.  Dang it.  I am not suggesting or implying that you should
>> remove the 'sdist_dsc' command.  I'm trying to illustrate that the
>> commandA-opts are just that and nothing more: commandA-opts.  And
>> whatever part of the build/install process that they apply to, then
>> the commandA can use them for WHATEVER purpose.  Which means that
>> since 'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all
>> 'sdist_dsc' options to be passed into the 'bdist_deb' command which
>> can then pass them along to 'sdist_dsc'.  'bdist_deb' is a SUPERSET of
>> 'sdist_dsc'.
>>     
> I see -- you want to pass-through the options to sdist_dsc. Fine,
> implement this in a patch and I'll accept it.
>   
Oh sure, I get to have all the fun.


>
>   
>>> For setting environment variables this way, they cannot be separated by
>>> a semicolon
>>>       
>> The environment variables are not individually separated by a
>> semicolon.  The WHOLE shell script environment variable declaration
>> statement needs to be separated from the install line statement.
>>
>> Simple demonstration of the problem with the 'echo' statement
>> simulating the 'install' statement:
>> $ a='123' b='456' echo test $a $b
>> test
>> $ a='123' b='456'; echo test $a $b
>> test 123 456
>>     
>
> Passing to a subprocess is different. We're passing to a subprocess:
>
> $ a='123' python -c "import os; print os.environ['a']"
> 123
> $ a='123'; python -c "import os; print os.environ['a']"
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
>     raise KeyError(key)
> KeyError: 'a'
>   
Ok, I see what is happening.  In order for the env vars to be available 
to both the line itself AND to the subprocess it has to be declared as 
exported like this:

export a='123' b='456'; python -c "import os; print os.environ['a']" && 
echo $b
123
456


Now it will work both ways.

Regards,
Gerry


From olof.bjarnason at gmail.com  Tue Sep 29 07:50:26 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Tue, 29 Sep 2009 07:50:26 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC142BF.4000004@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AC0FF50.5020906@verizon.net>
	<4AC10622.5080807@astraw.com> <4AC109B8.7060807@verizon.net>
	<4AC115B9.6000307@astraw.com> <4AC12290.3040404@verizon.net>
	<4AC126F5.9040204@astraw.com> <4AC1329D.6060809@verizon.net>
	<4AC135B0.2060302@astraw.com> <4AC142BF.4000004@verizon.net>
Message-ID: <c3dfe1d0909282250p1d5be077gd33386e4310a4060@mail.gmail.com>

OK I'm sorry for starting some kind of "battle" here :)

I guess "sdist_*" stands for "source distribution", and likewise
"bdist_*" stands for "binary distribution"?

Tell a rookie like me: what is a binary distribution of a python
application? It feels like an awkward concept.


2009/9/29 Gerry Reno <greno at verizon.net>:
> Andrew Straw wrote:
>>
>> Gerry Reno wrote:
>>
>>>
>>> Andrew Straw wrote:
>>>
>>>>
>>>> Gerry Reno wrote:
>>>>
>>>>>
>>>>> What if stdeb only had the command 'bdist_deb' and had no other
>>>>> command.
>>>>>
>>>>
>>>> I will not remove the "sdist_dsc" command from stdeb. I believe that the
>>>> ability to produce debian source packages is much more important that
>>>> the ability to produce binary packages which only target a single
>>>> architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
>>>> add-on to that saving a couple lines of typing which may be helpful to
>>>> people who aren't familiar with those lines. But I see the .dsc and
>>>> associated files as much more useful as the compiled .deb files.
>>>>
>>>>
>>>>
>>>
>>> LMAO. ?Dang it. ?I am not suggesting or implying that you should
>>> remove the 'sdist_dsc' command. ?I'm trying to illustrate that the
>>> commandA-opts are just that and nothing more: commandA-opts. ?And
>>> whatever part of the build/install process that they apply to, then
>>> the commandA can use them for WHATEVER purpose. ?Which means that
>>> since 'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all
>>> 'sdist_dsc' options to be passed into the 'bdist_deb' command which
>>> can then pass them along to 'sdist_dsc'. ?'bdist_deb' is a SUPERSET of
>>> 'sdist_dsc'.
>>>
>>
>> I see -- you want to pass-through the options to sdist_dsc. Fine,
>> implement this in a patch and I'll accept it.
>>
>
> Oh sure, I get to have all the fun.
>
>
>>
>>
>>>>
>>>> For setting environment variables this way, they cannot be separated by
>>>> a semicolon
>>>>
>>>
>>> The environment variables are not individually separated by a
>>> semicolon. ?The WHOLE shell script environment variable declaration
>>> statement needs to be separated from the install line statement.
>>>
>>> Simple demonstration of the problem with the 'echo' statement
>>> simulating the 'install' statement:
>>> $ a='123' b='456' echo test $a $b
>>> test
>>> $ a='123' b='456'; echo test $a $b
>>> test 123 456
>>>
>>
>> Passing to a subprocess is different. We're passing to a subprocess:
>>
>> $ a='123' python -c "import os; print os.environ['a']"
>> 123
>> $ a='123'; python -c "import os; print os.environ['a']"
>> Traceback (most recent call last):
>> ?File "<string>", line 1, in <module>
>> ?File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
>> ? ?raise KeyError(key)
>> KeyError: 'a'
>>
>
> Ok, I see what is happening. ?In order for the env vars to be available to
> both the line itself AND to the subprocess it has to be declared as exported
> like this:
>
> export a='123' b='456'; python -c "import os; print os.environ['a']" && echo
> $b
> 123
> 456
>
>
> Now it will work both ways.
>
> Regards,
> Gerry
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From greno at verizon.net  Tue Sep 29 07:50:00 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 29 Sep 2009 01:50:00 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC142BF.4000004@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net>
Message-ID: <4AC1A008.7000100@verizon.net>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>> Andrew Straw wrote:
>>>> Gerry Reno wrote:
>>>>
>>>>> What if stdeb only had the command 'bdist_deb' and had no other
>>>>> command.
>>>> I will not remove the "sdist_dsc" command from stdeb. I believe 
>>>> that the
>>>> ability to produce debian source packages is much more important that
>>>> the ability to produce binary packages which only target a single
>>>> architecture and version of Debian/Ubuntu. "bdist_deb" is just a 
>>>> trivial
>>>> add-on to that saving a couple lines of typing which may be helpful to
>>>> people who aren't familiar with those lines. But I see the .dsc and
>>>> associated files as much more useful as the compiled .deb files.
>>>>
>>>>
>>> LMAO. Dang it. I am not suggesting or implying that you should
>>> remove the 'sdist_dsc' command. I'm trying to illustrate that the
>>> commandA-opts are just that and nothing more: commandA-opts. And
>>> whatever part of the build/install process that they apply to, then
>>> the commandA can use them for WHATEVER purpose. Which means that
>>> since 'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all
>>> 'sdist_dsc' options to be passed into the 'bdist_deb' command which
>>> can then pass them along to 'sdist_dsc'. 'bdist_deb' is a SUPERSET of
>>> 'sdist_dsc'.
>> I see -- you want to pass-through the options to sdist_dsc. Fine,
>> implement this in a patch and I'll accept it.
> Oh sure, I get to have all the fun.
>
>
>>
>>>> For setting environment variables this way, they cannot be 
>>>> separated by
>>>> a semicolon
>>> The environment variables are not individually separated by a
>>> semicolon. The WHOLE shell script environment variable declaration
>>> statement needs to be separated from the install line statement.
>>>
>>> Simple demonstration of the problem with the 'echo' statement
>>> simulating the 'install' statement:
>>> $ a='123' b='456' echo test $a $b
>>> test
>>> $ a='123' b='456'; echo test $a $b
>>> test 123 456
>>
>> Passing to a subprocess is different. We're passing to a subprocess:
>>
>> $ a='123' python -c "import os; print os.environ['a']"
>> 123
>> $ a='123'; python -c "import os; print os.environ['a']"
>> Traceback (most recent call last):
>> File "<string>", line 1, in <module>
>> File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
>> raise KeyError(key)
>> KeyError: 'a'
> Ok, I see what is happening. In order for the env vars to be available 
> to both the line itself AND to the subprocess it has to be declared as 
> exported like this:
>
> export a='123' b='456'; python -c "import os; print os.environ['a']" 
> && echo $b
> 123
> 456
>
>
> Now it will work both ways.
>
> Regards,
> Gerry

I have attached a replacement 'bdist_deb.py' file that permits passing 
arguments to bdist_deb which in turn passes them down to sdist_dsc.

and a util.py diff (made against the gerry-reno git branch) makes the 
setup_env_vars work for both the line statements as well as the 
subprocesses.

I have tested both on Ubuntu 8.0.4 Hardy with success.


Regards,
Gerry

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: util.py-0.3-gerry-reno-git
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090929/be609740/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdist_deb.py
Type: text/x-python
Size: 1156 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090929/be609740/attachment.py>

From greno at verizon.net  Tue Sep 29 07:56:56 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 29 Sep 2009 01:56:56 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <c3dfe1d0909282250p1d5be077gd33386e4310a4060@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4AC0FF50.5020906@verizon.net>
	<4AC10622.5080807@astraw.com> <4AC109B8.7060807@verizon.net>
	<4AC115B9.6000307@astraw.com> <4AC12290.3040404@verizon.net>
	<4AC126F5.9040204@astraw.com> <4AC1329D.6060809@verizon.net>
	<4AC135B0.2060302@astraw.com> <4AC142BF.4000004@verizon.net>
	<c3dfe1d0909282250p1d5be077gd33386e4310a4060@mail.gmail.com>
Message-ID: <4AC1A1A8.6090604@verizon.net>

Olof Bjarnason wrote:
> OK I'm sorry for starting some kind of "battle" here :)
>
> I guess "sdist_*" stands for "source distribution", and likewise
> "bdist_*" stands for "binary distribution"?
>
> Tell a rookie like me: what is a binary distribution of a python
> application? It feels like an awkward concept.
>
>   
It would be something like an .rpm or a .deb file or a windows installer 
file.

Regards,
Gerry


From regebro at gmail.com  Tue Sep 29 08:09:27 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 29 Sep 2009 08:09:27 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC1A1A8.6090604@verizon.net>
References: <4AB30240.8020807@verizon.net> <4AC109B8.7060807@verizon.net>
	<4AC115B9.6000307@astraw.com> <4AC12290.3040404@verizon.net>
	<4AC126F5.9040204@astraw.com> <4AC1329D.6060809@verizon.net>
	<4AC135B0.2060302@astraw.com> <4AC142BF.4000004@verizon.net>
	<c3dfe1d0909282250p1d5be077gd33386e4310a4060@mail.gmail.com>
	<4AC1A1A8.6090604@verizon.net>
Message-ID: <319e029f0909282309q495625beu5b570208028da2da@mail.gmail.com>

2009/9/29 Gerry Reno <greno at verizon.net>:
> It would be something like an .rpm or a .deb file or a windows installer
> file.

Or anything with a compiled c-extension. Or for that matter, pyc-files
(but then you don't need it).

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

From ben+python at benfinney.id.au  Tue Sep 29 09:10:41 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 29 Sep 2009 17:10:41 +1000
Subject: [Distutils] bdist_deb in stdeb
References: <4AB30240.8020807@verizon.net> <4AC0FF50.5020906@verizon.net>
	<4AC10622.5080807@astraw.com> <4AC109B8.7060807@verizon.net>
	<4AC115B9.6000307@astraw.com> <4AC12290.3040404@verizon.net>
	<4AC126F5.9040204@astraw.com> <4AC1329D.6060809@verizon.net>
	<4AC135B0.2060302@astraw.com> <4AC142BF.4000004@verizon.net>
	<c3dfe1d0909282250p1d5be077gd33386e4310a4060@mail.gmail.com>
Message-ID: <87iqf22pla.fsf@benfinney.id.au>

Olof Bjarnason <olof.bjarnason at gmail.com> writes:

> I guess "sdist_*" stands for "source distribution", and likewise
> "bdist_*" stands for "binary distribution"?

Why are you guessing? You've been researching Python's distutils since
several days ago, no? These terms are in the documentation you were
directed to very early on:

    <URL:http://docs.python.org/distutils/introduction.html>

Your questions about these commands and terms suggest you haven't yet
read the documentation that you acknowledged was a necessary first step.

-- 
 \         ?Money is always to be found when men are to be sent to the |
  `\   frontiers to be destroyed: when the object is to preserve them, |
_o__)     it is no longer so.? ?Voltaire, _Dictionnaire Philosophique_ |
Ben Finney


From olof.bjarnason at gmail.com  Tue Sep 29 09:22:51 2009
From: olof.bjarnason at gmail.com (Olof Bjarnason)
Date: Tue, 29 Sep 2009 09:22:51 +0200
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <87iqf22pla.fsf@benfinney.id.au>
References: <4AB30240.8020807@verizon.net> <4AC109B8.7060807@verizon.net>
	<4AC115B9.6000307@astraw.com> <4AC12290.3040404@verizon.net>
	<4AC126F5.9040204@astraw.com> <4AC1329D.6060809@verizon.net>
	<4AC135B0.2060302@astraw.com> <4AC142BF.4000004@verizon.net>
	<c3dfe1d0909282250p1d5be077gd33386e4310a4060@mail.gmail.com>
	<87iqf22pla.fsf@benfinney.id.au>
Message-ID: <c3dfe1d0909290022k59eaa5d9s1a5ea7e83585a449@mail.gmail.com>

2009/9/29 Ben Finney <ben+python at benfinney.id.au>:
> Olof Bjarnason <olof.bjarnason at gmail.com> writes:
>
>> I guess "sdist_*" stands for "source distribution", and likewise
>> "bdist_*" stands for "binary distribution"?
>
> Why are you guessing? You've been researching Python's distutils since
> several days ago, no? These terms are in the documentation you were
> directed to very early on:
>
> ? ?<URL:http://docs.python.org/distutils/introduction.html>
>
> Your questions about these commands and terms suggest you haven't yet
> read the documentation that you acknowledged was a necessary first step.

Yeah sorry about that. I was going through a lot of different tools;
and the clarification about bdist/sdist was not obvious from the first
few pages of distutils documentation.

>
> --
> ?\ ? ? ? ? ?Money is always to be found when men are to be sent to the |
> ?`\ ? frontiers to be destroyed: when the object is to preserve them, |
> _o__) ? ? it is no longer so.? ?Voltaire, _Dictionnaire Philosophique_ |
> Ben Finney
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

From strawman at astraw.com  Tue Sep 29 17:44:16 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 29 Sep 2009 08:44:16 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC1A008.7000100@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net> <4AC1A008.7000100@verizon.net>
Message-ID: <4AC22B50.7040106@astraw.com>

Gerry Reno wrote:
> I have attached a replacement 'bdist_deb.py' file that permits passing
> arguments to bdist_deb which in turn passes them down to sdist_dsc.
>
> and a util.py diff (made against the gerry-reno git branch) makes the
> setup_env_vars work for both the line statements as well as the
> subprocesses.
OK, I committed these to the old-stable branch and merged in the
bdist_deb changes to the master branch. I made some minor changes to
your option to disable --single-version..., the most significant of
which is the name, which is now "--disable..." instead of "--ignore...".
The other is that I'm not using env vars in the debian/rules file -- it
just clutters it up unnecessarily.

I still wonder if the (now named) --disable-single-version... option
actually solves your problem -- you _are_ importing setuptools in the
same line, so I am mystified by this. But anyhow it's now in there and I
don't think it'll cause anyone any harm because it's unlikely they'll
use the option.

I'll probably let this stuff settle for a day or two and then cut new
stdeb releases (0.3.2 and 0.4.1).

-Andrew

From strawman at astraw.com  Tue Sep 29 18:05:34 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 29 Sep 2009 09:05:34 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <c3dfe1d0909281256l2cac13d3wab55e51535073a9@mail.gmail.com>
References: <4AB30240.8020807@verizon.net> <4AC0D48F.90000@astraw.com>	
	<4AC0DEE9.5060800@verizon.net>	
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>	
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>	
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>	
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>	
	<c3dfe1d0909281244t7a3ce467y2e3e1fe65e3fdb10@mail.gmail.com>
	<c3dfe1d0909281256l2cac13d3wab55e51535073a9@mail.gmail.com>
Message-ID: <4AC2304E.20409@astraw.com>

Olof Bjarnason wrote:
> OK I came a little further apt-get:ing debhelper and python-all-dev,
> then issuing
>
> sudo python -c "import stdeb; execfile('setup.py')" bdist_deb
>
> .. but it ended with this:
> dpkg-deb - fel: (upstream) version ("dev") inneh?ller inga siffror
>   

The English translation of this is:

dpkg-deb - error: (upstream) version (`dev') doesn't contain any digits

I think that's your problem -- make the version specified in your
setup.py a legal Debian version, and it should work.

-Andrew

From greno at verizon.net  Tue Sep 29 18:28:35 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 29 Sep 2009 12:28:35 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC22B50.7040106@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net> <4AC1A008.7000100@verizon.net>
	<4AC22B50.7040106@astraw.com>
Message-ID: <4AC235B3.3080900@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>> I have attached a replacement 'bdist_deb.py' file that permits passing
>> arguments to bdist_deb which in turn passes them down to sdist_dsc.
>>
>> and a util.py diff (made against the gerry-reno git branch) makes the
>> setup_env_vars work for both the line statements as well as the
>> subprocesses.
> OK, I committed these to the old-stable branch and merged in the
> bdist_deb changes to the master branch. I made some minor changes to
> your option to disable --single-version..., the most significant of
> which is the name, which is now "--disable..." instead of "--ignore...".
> The other is that I'm not using env vars in the debian/rules file -- it
> just clutters it up unnecessarily.
Even so, it would still be more flexible if you leave in the 'export' 
statement. 
That allows you to use the env vars in both the line AND the 
subprocess.  I know you're not using them right now, but at least later 
people would have the option if they wanted.
And since you refactored the SVEM option you should make sure that there 
is at least ONE env var for the export statement and that can be 
anything, such as export HOME PATH DUMMY, etc. 
It's not absolutely critical but 'export' with no options will print all 
the exported env vars which might look strange in the log/output.


>
> I still wonder if the (now named) --disable-single-version... option
> actually solves your problem -- you _are_ importing setuptools in the
> same line, so I am mystified by this. 
Ok, here's what happens if I DON'T use the option (shown with the old 
code - same logic):

$ python setup.py  bdist_deb
...
running build_scripts
...
if test "2.5" = "2.5" -o "2.5" = "2.4"; then \
          export SVEMOPT="--single-version-externally-managed" ; 
python2.5 -c "import 
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
install \
            --no-compile ${SVEMOPT} \
...
error: option --single-version-externally-managed not recognized
...
<process stops on the error>

I can't explain it, but this is what happens.  This is on Ubuntu Hardy 
using python 2.5.2.


> But anyhow it's now in there and I
> don't think it'll cause anyone any harm because it's unlikely they'll
> use the option.
>
> I'll probably let this stuff settle for a day or two and then cut new
> stdeb releases (0.3.2 and 0.4.1).
>
> -Andrew
>

Regards,
Gerry


From strawman at astraw.com  Tue Sep 29 19:02:20 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 29 Sep 2009 10:02:20 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC235B3.3080900@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net> <4AC1A008.7000100@verizon.net>
	<4AC22B50.7040106@astraw.com> <4AC235B3.3080900@verizon.net>
Message-ID: <4AC23D9C.7090605@astraw.com>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>> I have attached a replacement 'bdist_deb.py' file that permits passing
>>> arguments to bdist_deb which in turn passes them down to sdist_dsc.
>>>
>>> and a util.py diff (made against the gerry-reno git branch) makes the
>>> setup_env_vars work for both the line statements as well as the
>>> subprocesses.
>> OK, I committed these to the old-stable branch and merged in the
>> bdist_deb changes to the master branch. I made some minor changes to
>> your option to disable --single-version..., the most significant of
>> which is the name, which is now "--disable..." instead of "--ignore...".
>> The other is that I'm not using env vars in the debian/rules file -- it
>> just clutters it up unnecessarily.
> Even so, it would still be more flexible if you leave in the 'export'
> statement.
More flexible, true -- but at a cost complexity and with no known use of
the flexibility. The complexity is that the auto-generated debian/rules
files are even less readable than they currently are in the old-stable
branch.

> That allows you to use the env vars in both the line AND the
> subprocess.  I know you're not using them right now, but at least
> later people would have the option if they wanted.
> And since you refactored the SVEM option you should make sure that
> there is at least ONE env var for the export statement and that can be
> anything, such as export HOME PATH DUMMY, etc. It's not absolutely
> critical but 'export' with no options will print all the exported env
> vars which might look strange in the log/output.

If you want to pass environment variables to your setup.py script, the
current method works fine. If one needs to modify the auto-generated
debian/rules, one will have to patch stdeb anyway, so I can't see why we
this should be added in now. It's just complexity with no gain, as far
as I can see. (That's why I removed it.)

>> I still wonder if the (now named) --disable-single-version... option
>> actually solves your problem -- you _are_ importing setuptools in the
>> same line, so I am mystified by this. 
>
> Ok, here's what happens if I DON'T use the option (shown with the old
> code - same logic):
>
> $ python setup.py  bdist_deb
> ...
> running build_scripts
> ...
> if test "2.5" = "2.5" -o "2.5" = "2.4"; then \
>          export SVEMOPT="--single-version-externally-managed" ;
> python2.5 -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> install \
>            --no-compile ${SVEMOPT} \
> ...
> error: option --single-version-externally-managed not recognized
> ...
> <process stops on the error>
>
> I can't explain it, but this is what happens.  This is on Ubuntu Hardy
> using python 2.5.2.
I see. I think it's because you're subclassing distutils.command.install
rather than setuptools.command.install for your install command.

Another idea is that you could also detect whether setuptools is
imported by doing something like "if 'setuptools' in sys.modules" and
then subclassing the appropriate install command based on that. Then you
wouldn't need to pass the --disable-single-version-externally-managed
argument at all.

-Andrew

From greno at verizon.net  Tue Sep 29 20:45:29 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 29 Sep 2009 14:45:29 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC23D9C.7090605@astraw.com>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net> <4AC1A008.7000100@verizon.net>
	<4AC22B50.7040106@astraw.com> <4AC235B3.3080900@verizon.net>
	<4AC23D9C.7090605@astraw.com>
Message-ID: <4AC255C9.70501@verizon.net>

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> Ok, here's what happens if I DON'T use the option (shown with the old
>> code - same logic):
>>
>> $ python setup.py  bdist_deb
>> ...
>> running build_scripts
>> ...
>> if test "2.5" = "2.5" -o "2.5" = "2.4"; then \
>>          export SVEMOPT="--single-version-externally-managed" ;
>> python2.5 -c "import
>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
>> install \
>>            --no-compile ${SVEMOPT} \
>> ...
>> error: option --single-version-externally-managed not recognized
>> ...
>> <process stops on the error>
>>
>> I can't explain it, but this is what happens.  This is on Ubuntu Hardy
>> using python 2.5.2.
>>     
> I see. I think it's because you're subclassing distutils.command.install
> rather than setuptools.command.install for your install command.
>
> Another idea is that you could also detect whether setuptools is
> imported by doing something like "if 'setuptools' in sys.modules" and
> then subclassing the appropriate install command based on that. Then you
> wouldn't need to pass the --disable-single-version-externally-managed
> argument at all.
>
> -Andrew
>   
Ok, a little guidance please.  As I understand it if I import setuptools 
into my app setup.py and I subclass my install from 
setuptools.command.install, then I can also use the option 
'--single-version-externally-managed' to make the install behave like 
the distutils style install.  Is that correct?
If this is true then what I would like to do is to force this option on 
in the code.  How can I do that?  I know I can probably put it into 
setup.cfg but I just think it would be better hardwired into the code.

Regards,
Gerry



From greno at verizon.net  Wed Sep 30 04:59:36 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 29 Sep 2009 22:59:36 -0400
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC255C9.70501@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net> <4AC1A008.7000100@verizon.net>
	<4AC22B50.7040106@astraw.com> <4AC235B3.3080900@verizon.net>
	<4AC23D9C.7090605@astraw.com> <4AC255C9.70501@verizon.net>
Message-ID: <4AC2C998.7020807@verizon.net>

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>> Ok, here's what happens if I DON'T use the option (shown with the old
>>> code - same logic):
>>>
>>> $ python setup.py bdist_deb
>>> ...
>>> running build_scripts
>>> ...
>>> if test "2.5" = "2.5" -o "2.5" = "2.4"; then \
>>> export SVEMOPT="--single-version-externally-managed" ;
>>> python2.5 -c "import
>>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})" 
>>>
>>> install \
>>> --no-compile ${SVEMOPT} \
>>> ...
>>> error: option --single-version-externally-managed not recognized
>>> ...
>>> <process stops on the error>
>>>
>>> I can't explain it, but this is what happens. This is on Ubuntu Hardy
>>> using python 2.5.2.
>> I see. I think it's because you're subclassing distutils.command.install
>> rather than setuptools.command.install for your install command.
>>
>> Another idea is that you could also detect whether setuptools is
>> imported by doing something like "if 'setuptools' in sys.modules" and
>> then subclassing the appropriate install command based on that. Then you
>> wouldn't need to pass the --disable-single-version-externally-managed
>> argument at all.
>>
>> -Andrew
> Ok, a little guidance please. As I understand it if I import 
> setuptools into my app setup.py and I subclass my install from 
> setuptools.command.install, then I can also use the option 
> '--single-version-externally-managed' to make the install behave like 
> the distutils style install. Is that correct?
> If this is true then what I would like to do is to force this option 
> on in the code. How can I do that? I know I can probably put it into 
> setup.cfg but I just think it would be better hardwired into the code.
>
>
No one?

Ok, I refactored my app install code and have it running with setuptools.

Andrew, how can I generate the .deb package without the leading 
'python-' in the name? Is this configurable?

Regards,
Gerry



From strawman at astraw.com  Wed Sep 30 07:14:35 2009
From: strawman at astraw.com (Andrew Straw)
Date: Tue, 29 Sep 2009 22:14:35 -0700
Subject: [Distutils] bdist_deb in stdeb
In-Reply-To: <4AC2C998.7020807@verizon.net>
References: <4AB30240.8020807@verizon.net> <4ABBE693.6050300@astraw.com>
	<4AC0BD37.1010507@verizon.net> <4AC0CCEA.5080509@astraw.com>
	<4AC0CDE6.2010604@verizon.net> <4AC0D48F.90000@astraw.com>
	<4AC0DEE9.5060800@verizon.net>
	<c3dfe1d0909280912p2e63412w6e202a98cf47a983@mail.gmail.com>
	<4AC0E572.4010401@astraw.com> <4AC0ED94.5050405@verizon.net>
	<c3dfe1d0909281112o54915372v606a26cbef2a2129@mail.gmail.com>
	<4AC0FF50.5020906@verizon.net> <4AC10622.5080807@astraw.com>
	<4AC109B8.7060807@verizon.net> <4AC115B9.6000307@astraw.com>
	<4AC12290.3040404@verizon.net> <4AC126F5.9040204@astraw.com>
	<4AC1329D.6060809@verizon.net> <4AC135B0.2060302@astraw.com>
	<4AC142BF.4000004@verizon.net> <4AC1A008.7000100@verizon.net>
	<4AC22B50.7040106@astraw.com> <4AC235B3.3080900@verizon.net>
	<4AC23D9C.7090605@astraw.com> <4AC255C9.70501@verizon.net>
	<4AC2C998.7020807@verizon.net>
Message-ID: <4AC2E93B.9020506@astraw.com>

Gerry Reno wrote:
> Gerry Reno wrote:
>> Andrew Straw wrote:
>>> Gerry Reno wrote:
>>>> Ok, here's what happens if I DON'T use the option (shown with the old
>>>> code - same logic):
>>>>
>>>> $ python setup.py bdist_deb
>>>> ...
>>>> running build_scripts
>>>> ...
>>>> if test "2.5" = "2.5" -o "2.5" = "2.4"; then \
>>>> export SVEMOPT="--single-version-externally-managed" ;
>>>> python2.5 -c "import
>>>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
>>>>
>>>> install \
>>>> --no-compile ${SVEMOPT} \
>>>> ...
>>>> error: option --single-version-externally-managed not recognized
>>>> ...
>>>> <process stops on the error>
>>>>
>>>> I can't explain it, but this is what happens. This is on Ubuntu Hardy
>>>> using python 2.5.2.
>>> I see. I think it's because you're subclassing
>>> distutils.command.install
>>> rather than setuptools.command.install for your install command.
>>>
>>> Another idea is that you could also detect whether setuptools is
>>> imported by doing something like "if 'setuptools' in sys.modules" and
>>> then subclassing the appropriate install command based on that. Then
>>> you
>>> wouldn't need to pass the --disable-single-version-externally-managed
>>> argument at all.
>>>
>>> -Andrew
>> Ok, a little guidance please. As I understand it if I import
>> setuptools into my app setup.py and I subclass my install from
>> setuptools.command.install, then I can also use the option
>> '--single-version-externally-managed' to make the install behave like
>> the distutils style install. Is that correct?
>> If this is true then what I would like to do is to force this option
>> on in the code. How can I do that? I know I can probably put it into
>> setup.cfg but I just think it would be better hardwired into the code.
>>
>>
> No one?
>
> Ok, I refactored my app install code and have it running with setuptools.
>
> Andrew, how can I generate the .deb package without the leading
> 'python-' in the name? Is this configurable?
Yes. The 'Package' option. Described in "Customizing the produced Debian
source package (config options)" in the README.rst.

-Andrew

From chris at simplistix.co.uk  Wed Sep 30 15:20:31 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 14:20:31 +0100
Subject: [Distutils] setup.cfg new format proposal
In-Reply-To: <h90otv$act$1@ger.gmane.org>
References: <94bdd2610909110733h5ae5430dq75be85a635f92ae@mail.gmail.com>	<20090911144711.7485.2003150086.divmod.xquotient.662@localhost.localdomain>	<94bdd2610909110814t79e234e9ldf83c4cc3b81b090@mail.gmail.com>	<1099b90b0909110836o37d4f425q6041ffe4dec7a478@mail.gmail.com>	<94bdd2610909110849r74df83a3wf8a29c0c5f1e9fbb@mail.gmail.com>	<1099b90b0909111040s546edebctfcccda44da06bec0@mail.gmail.com>	<d9047f780909140713p5bfea062w2c66f825b2d315dc@mail.gmail.com>	<op.u0bfy60w1q4jlt@whymac>	<4AB35DA8.9090004@simplistix.co.uk>
	<h90otv$act$1@ger.gmane.org>
Message-ID: <4AC35B1F.3010906@simplistix.co.uk>

Tres Seaver wrote:
> You bothering the goats again, Chris? ;)
> 
> pkginfo uses the standard information generated by the 'sdist',
> 'develop' and 'bdist_egg' commenads, and can even introspect installed
> packages on Python 2.6.x.  It is documented here:
> 
>   http://packages.python.org/pkginfo/

Yep, I know all this, I experienced some weirdness when working on dev 
packages with the right metadata not being used when I was generating 
sphinx docs using pkginfo to get version information.

I'll post again when/if I can reproduce this easily...

Chris

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

From chris at simplistix.co.uk  Wed Sep 30 15:27:17 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 14:27:17 +0100
Subject: [Distutils] [buildout] is there a way to force re-install of
 a	part?
In-Reply-To: <h9g9sb$6e3$1@ger.gmane.org>
References: <4ABA0F80.4010705@simplistix.co.uk> <h9g9sb$6e3$1@ger.gmane.org>
Message-ID: <4AC35CB5.2050509@simplistix.co.uk>

Tres Seaver wrote:
>> I have a part using the djangorecipe part that stubbornly refuses to 
>> notice that I've changed an eggs dependencies or changed the stuff in 
>> the develop line of the [buildout] section.
>>
>> I've tried "bin/buildout install djangopart" but this doesn't have any 
>> effect. The only way I've found to get the part to re-install is to 
>> change the options in the part, install, and then put the options back 
>> like I want them before re-installing :-(
> 
>  $ rm -rf parts/djangopart; bin/buildout

Does anyone know if this is a problem with djangorecipe or buildout?

I only *remember* experiencing this with djangorecipe. If it *is* 
djangorecipe, anyone know what it's doing wrong? ;-)

Chris

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

From chris at simplistix.co.uk  Wed Sep 30 15:29:03 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 14:29:03 +0100
Subject: [Distutils] Bug in setuptool's findall
In-Reply-To: <4ABCCBAA.2070604@picloud.net>
References: <4ABCCBAA.2070604@picloud.net>
Message-ID: <4AC35D1F.1040008@simplistix.co.uk>

Aaron Staley wrote:
> This unfortunately will not follow directory symlinks (as followlinks is 
> set to false in os.walk by default).  This is NOT the behavior of the 
> original findall; oddly enough, the new findall actually produces bugs 
> relative to distutil's.

You'll likely have more response if you try `distribute` and see if you 
can reproduce there. Tarek may actually fix it ;-)

Chris

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

From chris at simplistix.co.uk  Wed Sep 30 17:00:52 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 16:00:52 +0100
Subject: [Distutils] something else to throw into the static metadata mix
Message-ID: <4AC372A4.4080701@simplistix.co.uk>

Hi All,

Sorry to bring this up if it makes things more difficult, if it's been 
solved or is covered by existing proposals, please point me in the right 
way.

I've had a bit of a torrid time building psycopg2 from source of late, 
and in my dream world, being able to specify psycopg2 as a dependent egg 
would "just work" and pull down the right statically linked binary egg.

This raises a problem that I haven't seen covered anywhere: not only 
would these eggs have to be platform dependent, they'd also need to be 
dependent on the required version of postgres.

Does setuptools/buildout/any other existing or proposed packaging 
solution cater for this kind of requirement?

cheers,

Chris

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

From nathan at creativecommons.org  Wed Sep 30 17:24:04 2009
From: nathan at creativecommons.org (Nathan Yergler)
Date: Wed, 30 Sep 2009 08:24:04 -0700
Subject: [Distutils] [buildout] is there a way to force re-install of a
	part?
In-Reply-To: <4AC35CB5.2050509@simplistix.co.uk>
References: <4ABA0F80.4010705@simplistix.co.uk> <h9g9sb$6e3$1@ger.gmane.org> 
	<4AC35CB5.2050509@simplistix.co.uk>
Message-ID: <c1a864630909300824i125f758at794a276b36e7145a@mail.gmail.com>

My suspicion is that it's a djangorecipe issue (because I've run into
it myself).  I say this because I seem to recall that if I change the
installation dependencies, zc.recipe.egg:scripts will notice that and
regenerate the wrapper script.  djangorecipe definitely does not.  I
haven't dug into the recipe to see what they're doing differently (and
I haven't taken the time to actually confirm this so I could be
insane).

Nathan


On Wed, Sep 30, 2009 at 6:27 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tres Seaver wrote:
>>>
>>> I have a part using the djangorecipe part that stubbornly refuses to
>>> notice that I've changed an eggs dependencies or changed the stuff in the
>>> develop line of the [buildout] section.
>>>
>>> I've tried "bin/buildout install djangopart" but this doesn't have any
>>> effect. The only way I've found to get the part to re-install is to change
>>> the options in the part, install, and then put the options back like I want
>>> them before re-installing :-(
>>
>> ?$ rm -rf parts/djangopart; bin/buildout
>
> Does anyone know if this is a problem with djangorecipe or buildout?
>
> I only *remember* experiencing this with djangorecipe. If it *is*
> djangorecipe, anyone know what it's doing wrong? ;-)
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? - http://www.simplistix.co.uk
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From kiorky at cryptelium.net  Wed Sep 30 18:11:56 2009
From: kiorky at cryptelium.net (kiorky)
Date: Wed, 30 Sep 2009 18:11:56 +0200
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <4AC372A4.4080701@simplistix.co.uk>
References: <4AC372A4.4080701@simplistix.co.uk>
Message-ID: <4AC3834C.8040708@cryptelium.net>



Chris Withers a ?crit :
> Hi All,
> 
> Sorry to bring this up if it makes things more difficult, if it's been
> solved or is covered by existing proposals, please point me in the right
> way.
> 
> I've had a bit of a torrid time building psycopg2 from source of late,
> and in my dream world, being able to specify psycopg2 as a dependent egg
> would "just work" and pull down the right statically linked binary egg.
> 
> This raises a problem that I haven't seen covered anywhere: not only
> would these eggs have to be platform dependent, they'd also need to be
> dependent on the required version of postgres.
> 
> Does setuptools/buildout/any other existing or proposed packaging
> solution cater for this kind of requirement?
> 
You can with minitage [1].
If you are right into a minitage env. and you have specified that postgresql is
a dependency of your project (minitage section or minibuild) and you have built
it (eg: postgresql-8.4), the egg recipe (minitage.recipe.*) will know how to use
and to point to it (update PATH/LDFLAGS/CFLAGS/RPATH/PKGCONFIG and so on )

> cheers,
> 
> Chris
> 


[1] http://www.minitage.org
-- 
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090930/6532c065/attachment.pgp>

From chris at simplistix.co.uk  Wed Sep 30 18:12:26 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 17:12:26 +0100
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <4AC3834C.8040708@cryptelium.net>
References: <4AC372A4.4080701@simplistix.co.uk>
	<4AC3834C.8040708@cryptelium.net>
Message-ID: <4AC3836A.9040406@simplistix.co.uk>

kiorky wrote:
>> Does setuptools/buildout/any other existing or proposed packaging
>> solution cater for this kind of requirement?
>>
> You can with minitage [1].

I'm afraid I'm more interested in what will be the "standard python way" 
of doing this.

I might be wrong, but I get the impression Minitage tries to do too much 
to be interesting for me...

Chris

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

From kiorky at cryptelium.net  Wed Sep 30 18:23:41 2009
From: kiorky at cryptelium.net (kiorky)
Date: Wed, 30 Sep 2009 18:23:41 +0200
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <4AC3836A.9040406@simplistix.co.uk>
References: <4AC372A4.4080701@simplistix.co.uk>
	<4AC3834C.8040708@cryptelium.net>
	<4AC3836A.9040406@simplistix.co.uk>
Message-ID: <4AC3860D.7070509@cryptelium.net>



Chris Withers a ?crit :
> kiorky wrote:
>>> Does setuptools/buildout/any other existing or proposed packaging
>>> solution cater for this kind of requirement?
>>>
>> You can with minitage [1].
> 
> I'm afraid I'm more interested in what will be the "standard python way"
> of doing this.
> 
> I might be wrong, but I get the impression Minitage tries to do too much
> to be interesting for me...
Minitage recipes which deal with eggs use setuptools/buildout under the hood,
The goal is not to reinvent the wheel but to isolate, integrate and automate.
I'm afraid it use the python way to do and nothing else.
Its actions are just integrations betweens all components to make a real project
deployment complete in a nice way.
This include for example:
	- setting an egg cache somewhere to share between projects.
	- having a well known layout to install stuff inside
	- compiling with -rpath for dynamic libraries
	- having hook architecture to make easy scripting around each installation step
	- having a good patching facility (on the fly egg patching for example)
> 
> Chris
> 

-- 
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090930/940e52fd/attachment-0001.pgp>

From ziade.tarek at gmail.com  Wed Sep 30 18:27:54 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 30 Sep 2009 18:27:54 +0200
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <4AC372A4.4080701@simplistix.co.uk>
References: <4AC372A4.4080701@simplistix.co.uk>
Message-ID: <94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>

On Wed, Sep 30, 2009 at 5:00 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> Sorry to bring this up if it makes things more difficult, if it's been
> solved or is covered by existing proposals, please point me in the right
> way.
>
> I've had a bit of a torrid time building psycopg2 from source of late, and
> in my dream world, being able to specify psycopg2 as a dependent egg would
> "just work" and pull down the right statically linked binary egg.
>
> This raises a problem that I haven't seen covered anywhere: not only would
> these eggs have to be platform dependent, they'd also need to be dependent
> on the required version of postgres.
>

I think it's another issue, more related to the way easy_install or
pip works with PyPI
(using package_index.py)

once those scripts have a list of dependencies, they are looking for
it at PyPI using the simple index,
and download the "best pick", and binary releases for your platform
will come first.

So, for pyscopg, if this page : pypi.python.org/simple/psycopg

would contain the binary distribution for your platform, it would
work. but there's only the source release,
and the home url doesn't contain anything useful, so it grabs the
source version for your case.

zope.interface for example has binary releases for win32 so win32
users don't have to compile it:
pypi.python.org/simple/zope.interface


> Does setuptools/buildout/any other existing or proposed packaging solution
> cater for this kind of requirement?
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? - http://www.simplistix.co.uk
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From chris at simplistix.co.uk  Wed Sep 30 18:28:05 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 30 Sep 2009 17:28:05 +0100
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>
References: <4AC372A4.4080701@simplistix.co.uk>
	<94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>
Message-ID: <4AC38715.90909@simplistix.co.uk>

Tarek Ziad? wrote:
> I think it's another issue, more related to the way easy_install or
> pip works with PyPI
> (using package_index.py)

I think you're missing my point: how would the package be named and/or 
how would you express in static metadata, that a particular version of 
the package is for postgres 8 rather than postgres 7, or 8.4 rather than 
8.3?

cheers,

Chris

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

From ziade.tarek at gmail.com  Wed Sep 30 18:53:46 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 30 Sep 2009 18:53:46 +0200
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <4AC38715.90909@simplistix.co.uk>
References: <4AC372A4.4080701@simplistix.co.uk>
	<94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>
	<4AC38715.90909@simplistix.co.uk>
Message-ID: <94bdd2610909300953h146d871cm3fa134ecd2ff4761@mail.gmail.com>

On Wed, Sep 30, 2009 at 6:28 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> I think it's another issue, more related to the way easy_install or
>> pip works with PyPI
>> (using package_index.py)
>
> I think you're missing my point: how would the package be named and/or how
> would you express in static metadata, that a particular version of the
> package is for postgres 8 rather than postgres 7, or 8.4 rather than 8.3?

I am not sure to understand, you mean within the psycopg2 project metadata ?

Since it's a system requirement, it's out of the metadata scope.

So unless the project provides a binary version your system will have to
be able to compile source version.

I think psycopg2 deals like python-ldap for this :

they depend on system libraries, and a given source distribution is supposed to
compile against one given version of each of these libraries.

It's up to the project to have a name or a version that corresponds to the lib
it wraps. I think a good practice is to have a version number
partially synchronized with the
lib the project wraps. I know that python-ldap version numbers
have nothing to do with open ldap version, and that compilation might
fail if you
don't have the right open ldap, and it's hard to know which version matches.

Now for the static metadata, if you add 'pyscopg2' to the dependencies,
if this project provides binary releases with statically compiled libraries,
that matches your platform, it'll work.

lxml is a good example for this, it ships with libxml and libxslt in
binary releases now :  http://pypi.python.org/simple/lxml

But it's out of the scope of the static metadata  to describe these
system dependencies :
the dependencies are only *python* dependencies, so the micro-language
we will provide does only concerns the Python environment.

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



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

From cgalvan at mail.utexas.edu  Wed Sep 30 21:26:15 2009
From: cgalvan at mail.utexas.edu (cgalvan at mail.utexas.edu)
Date: Wed, 30 Sep 2009 14:26:15 -0500
Subject: [Distutils] something else to throw into the static metadata	mix
In-Reply-To: <94bdd2610909300953h146d871cm3fa134ecd2ff4761@mail.gmail.com>
References: <4AC372A4.4080701@simplistix.co.uk>
	<94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>
	<4AC38715.90909@simplistix.co.uk>
	<94bdd2610909300953h146d871cm3fa134ecd2ff4761@mail.gmail.com>
Message-ID: <20090930142615.9940expm804w4ko8@webmail.utexas.edu>

Quoting Tarek Ziad? <ziade.tarek at gmail.com>:

> On Wed, Sep 30, 2009 at 6:28 PM, Chris Withers   
> <chris at simplistix.co.uk> wrote:
>> Tarek Ziad? wrote:
>>>
>>> I think it's another issue, more related to the way easy_install or
>>> pip works with PyPI
>>> (using package_index.py)
>>
>> I think you're missing my point: how would the package be named and/or how
>> would you express in static metadata, that a particular version of the
>> package is for postgres 8 rather than postgres 7, or 8.4 rather than 8.3?
>
> But it's out of the scope of the static metadata  to describe these
> system dependencies :
> the dependencies are only *python* dependencies, so the micro-language
> we will provide does only concerns the Python environment.

I agree with Tarek that the system dependency handling is not  
something that should be dealt with in the python package metadata.   
The best thing that can be hoped for is that packages which rely on a  
specific version of a system dependency will throw a descriptive error  
indicating this particular problem.  The MySQL_python project is one  
example of a project that is already doing this, since they throw an  
ImportError with a descriptive title in this case.

-Chris

>
>>
>> cheers,
>>
>> Chris
>>
>> --
>> Simplistix - Content Management, Batch Processing & Python Consulting
>> ? ? ? ? ? - http://www.simplistix.co.uk
>>
>
>
>
> --
> Tarek Ziad? | http://ziade.org |????????????!
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



From sridharr at activestate.com  Wed Sep 30 22:26:38 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 13:26:38 -0700
Subject: [Distutils] something else to throw into the static metadata	mix
In-Reply-To: <20090930142615.9940expm804w4ko8@webmail.utexas.edu>
References: <4AC372A4.4080701@simplistix.co.uk>
	<94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>
	<4AC38715.90909@simplistix.co.uk>
	<94bdd2610909300953h146d871cm3fa134ecd2ff4761@mail.gmail.com>
	<20090930142615.9940expm804w4ko8@webmail.utexas.edu>
Message-ID: <op.u0262oak1q4jlt@whymac.activestate.com>

On Wed, 30 Sep 2009 12:26:15 -0700, <cgalvan at mail.utexas.edu> wrote:

> I agree with Tarek that the system dependency handling is not something  
> that should be dealt with in the python package metadata.  The best  
> thing that can be hoped for is that packages which rely on a specific  
> version of a system dependency will throw a descriptive error indicating  
> this particular problem.  The MySQL_python project is one example of a  
> project that is already doing this, since they throw an ImportError with  
> a descriptive title in this case.

The other option could be to enable support for static linking so as to  
make the egg a reasonably self-sufficient binary (eg: lxml's --static flag  
to setup.py)

-srid


From ianb at colorstudy.com  Wed Sep 30 22:58:56 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 30 Sep 2009 15:58:56 -0500
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <op.u0262oak1q4jlt@whymac.activestate.com>
References: <4AC372A4.4080701@simplistix.co.uk>
	<94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com> 
	<4AC38715.90909@simplistix.co.uk>
	<94bdd2610909300953h146d871cm3fa134ecd2ff4761@mail.gmail.com> 
	<20090930142615.9940expm804w4ko8@webmail.utexas.edu>
	<op.u0262oak1q4jlt@whymac.activestate.com>
Message-ID: <b654cd2e0909301358i54497d8cm9568d8e7cab3a82b@mail.gmail.com>

2009/9/30 Sridhar Ratnakumar <sridharr at activestate.com>

> On Wed, 30 Sep 2009 12:26:15 -0700, <cgalvan at mail.utexas.edu> wrote:
>
>  I agree with Tarek that the system dependency handling is not something
>> that should be dealt with in the python package metadata.  The best thing
>> that can be hoped for is that packages which rely on a specific version of a
>> system dependency will throw a descriptive error indicating this particular
>> problem.  The MySQL_python project is one example of a project that is
>> already doing this, since they throw an ImportError with a descriptive title
>> in this case.
>>
>
> The other option could be to enable support for static linking so as to
> make the egg a reasonably self-sufficient binary (eg: lxml's --static flag
> to setup.py)
>

Just to throw more in the mix -- this option is totally ad hoc in lxml,
which means it's hard to handle in an installer like easy_install or pip.
That is, there's no good way to do "easy_install --static lxml" (it's more
possible in pip, but still quite awkward).

-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090930/e3132c67/attachment-0001.htm>

From sridharr at activestate.com  Wed Sep 30 23:05:25 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 14:05:25 -0700
Subject: [Distutils] something else to throw into the static metadata mix
In-Reply-To: <b654cd2e0909301358i54497d8cm9568d8e7cab3a82b@mail.gmail.com>
References: <4AC372A4.4080701@simplistix.co.uk>
	<94bdd2610909300927l2a605af5x7c325e9aa0151799@mail.gmail.com>
	<4AC38715.90909@simplistix.co.uk>
	<94bdd2610909300953h146d871cm3fa134ecd2ff4761@mail.gmail.com>
	<20090930142615.9940expm804w4ko8@webmail.utexas.edu>
	<op.u0262oak1q4jlt@whymac.activestate.com>
	<b654cd2e0909301358i54497d8cm9568d8e7cab3a82b@mail.gmail.com>
Message-ID: <op.u028vbhp1q4jlt@whymac.activestate.com>

On Wed, 30 Sep 2009 13:58:56 -0700, Ian Bicking <ianb at colorstudy.com>  
wrote:

> The other option could be to enable support for static linking so as to  
> make the egg a reasonably self-sufficient binary (eg: lxml's --static  
> flag to setup.py)
> Just to throw more in the mix -- this option is totally ad hoc in lxml,  
> which means it's hard to handle in an installer like easy_install or  
> pip.  That is, there's no good way to do "easy_install --static lxml"  
> (it's more possible in pip, but still quite awkward).

Maybe we can standardize the ``--static`` flag for setup.py and  
installers? The benefit of this is that builders and installers can  
support a static build feature without having to hack build scripts for  
specific packages (Currently PyPM's backend maintains custom code for  
building such special packages).

Examples of usage::

   $ python setup.py build --static install
   $ easy_install --static lxml
   $ pip install --install-option="--static" pip

-srid