From ziade.tarek at gmail.com  Sun Aug  2 18:30:03 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 2 Aug 2009 18:30:03 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
Message-ID: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>

Hello

For http://bugs.python.org/issue6555, I was wondering if anyone recall
why we have two different names (pydistutils.cfg vs distutils.cfg)

As Zookoo pointed (and Google, if I search for "distutils.cfg
pydistutils.cfg" :) ) it brings a lot of confusion, and I would like
to deprecate pydistutils.cfg
and have ".distutils.cfg" and "distutils.cfg" for the user-level file
(unless someone finds a good reason it has to be different)

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

From ziade.tarek at gmail.com  Sun Aug  2 18:52:32 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 2 Aug 2009 18:52:32 +0200
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
	default)
In-Reply-To: <20090729044116.919B53A4099@sparrow.telecommunity.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
	<b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.com>
	<20090729023727.272FB3A4099@sparrow.telecommunity.com>
	<b654cd2e0907282035l336975f3udbca15c6233f929a@mail.gmail.com>
	<20090729044116.919B53A4099@sparrow.telecommunity.com>
Message-ID: <94bdd2610908020952n4784903dsfaeac2b39f6d6343@mail.gmail.com>

On Wed, Jul 29, 2009 at 6:44 AM, P.J. Eby<pje at telecommunity.com> wrote:
> At 10:35 PM 7/28/2009 -0500, Ian Bicking wrote:
>>
>> On Tue, Jul 28, 2009 at 9:40 PM, P.J. Eby<pje at telecommunity.com> wrote:
>> > At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
>> >>
>> >> I can see how this could go quite wrong, but maybe if installers touch
>> >> some file in the library directory anytime a package is
>> >> installed/reinstalled/removed/etc,
>> >
>> > You mean, like, the mtime of the directory itself? ? ;-)
>>
>> Do directory mtimes get recursively updated? ?I don't think they do.
>
> That's not necessary; if imports use a cached listdir, then the children
> will get handled recursively.
>
>> So if you have a layout:
>>
>> site-packages/
>> ?zope/
>> ? ?interface/
>> ? ? ?__init__.py
>>
>> And you update the package and update __init__.py, the mtime of
>> site-packages doesn't change, does it?
>
> Nope, but at the top level, the fact that 'zope' is present is unchanged, as
> is the presence of an 'interface' subdirectory.
>
>
>> I'm saying if there was a file in site-packages/last_updated that gets
>> touched everytime an installer does anything in site-packages, then
>> you could cache (between processes) the lookups.
>
> Since each invocation of the interpreter can have a different PYTHONPATH,
> the cache has to be per-directory, not global. ?If it's per-directory, then
> there's no real benefit over runtime caching, since you now have to open and
> read a file (instead of just reading the directory). ?And as I said, it's
> not realistic to think that opening and reading a file is going to beat
> opening and reading a directory for speed.

But opening and reading one file should beat opening hundreds of directories :

For instance, a plone 3 application will have +100 sys.path entries because
this zc.buildout (the Plone standard) adds one entry per egg in sys.path.

So being able to cache'em should speed things up.

In the PEP 376 prototype, after thinking about a per-directory cache
like you are
describing, I was thinking about having a global index file to replace
the global dictionnary that keeps track of the distributions per
directory (currently the directory path
is  the key in the dictionnary and the value the distribution objects).

That can even be a simple shelve of the dictionary, that become a
global index of directories
that [are/were once] in the path. This works as long as the index file
is per-user.
Or even better : per-application. I don't know how this could be
managed/done, but
a simple cache file created alongside the script the application is
launched with, could
speed up the lookups at the second launch.

Cheers
Tarek


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

From ziade.tarek at gmail.com  Sun Aug  2 19:01:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 2 Aug 2009 19:01:00 +0200
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <319e029f0907290051v4b5b040fvfae307996cbe5234@mail.gmail.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<1099b90b0907281038g1aeb2da3mf9d4059388ad816c@mail.gmail.com>
	<73626eec1144ff7907636d73538896db@preisshare.net>
	<A71FE44A-AD37-4621-8D64-54D80110F32A@gmail.com>
	<319e029f0907290051v4b5b040fvfae307996cbe5234@mail.gmail.com>
Message-ID: <94bdd2610908021001p638d780elf426d1c1be104801@mail.gmail.com>

On Wed, Jul 29, 2009 at 9:51 AM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/29 Leonardo Santagada <santagada at gmail.com>:
>> I think P.J. Eby is right, we need to test it before analising the results
>> we don't have.
>
> No we don't, because zipped eggs are such a pain that speed is
> irrelevant in comparison. Those who *do* care about minor improvements
> in startup speed can test. And then they can set their settings to
> install eggs zipped by default.

+1 for unzipped eggs by default.  I've accepted the #33 in our tracker
and I propose to fix it for 0.7

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

+1 for creating a performance test. If we can improve the lookup speed
of applications
that heavily rely on eggs, that would be nice. I think a Plone-based
application is a good
sandbox for this test, because it uses hundreds of eggs. If someone
wants to give it a shot.

Cheers
Tarek


>
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
> _______________________________________________
> 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  Sun Aug  2 19:54:18 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 02 Aug 2009 13:54:18 -0400
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
 default)
In-Reply-To: <94bdd2610908020952n4784903dsfaeac2b39f6d6343@mail.gmail.co
 m>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
	<b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.com>
	<20090729023727.272FB3A4099@sparrow.telecommunity.com>
	<b654cd2e0907282035l336975f3udbca15c6233f929a@mail.gmail.com>
	<20090729044116.919B53A4099@sparrow.telecommunity.com>
	<94bdd2610908020952n4784903dsfaeac2b39f6d6343@mail.gmail.com>
Message-ID: <20090802175109.EC1CA3A4093@sparrow.telecommunity.com>

At 06:52 PM 8/2/2009 +0200, Tarek Ziad? wrote:
>On Wed, Jul 29, 2009 at 6:44 AM, P.J. Eby<pje at telecommunity.com> wrote:
> > At 10:35 PM 7/28/2009 -0500, Ian Bicking wrote:
> >>
> >> On Tue, Jul 28, 2009 at 9:40 PM, P.J. Eby<pje at telecommunity.com> wrote:
> >> > At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
> >> >>
> >> >> I can see how this could go quite wrong, but maybe if installers touch
> >> >> some file in the library directory anytime a package is
> >> >> installed/reinstalled/removed/etc,
> >> >
> >> > You mean, like, the mtime of the directory itself? ? ;-)
> >>
> >> Do directory mtimes get recursively updated?  I don't think they do.
> >
> > That's not necessary; if imports use a cached listdir, then the children
> > will get handled recursively.
> >
> >> So if you have a layout:
> >>
> >> site-packages/
> >>  zope/
> >>    interface/
> >>      __init__.py
> >>
> >> And you update the package and update __init__.py, the mtime of
> >> site-packages doesn't change, does it?
> >
> > Nope, but at the top level, the fact that 'zope' is present is 
> unchanged, as
> > is the presence of an 'interface' subdirectory.
> >
> >
> >> I'm saying if there was a file in site-packages/last_updated that gets
> >> touched everytime an installer does anything in site-packages, then
> >> you could cache (between processes) the lookups.
> >
> > Since each invocation of the interpreter can have a different PYTHONPATH,
> > the cache has to be per-directory, not global.  If it's per-directory, then
> > there's no real benefit over runtime caching, since you now have 
> to open and
> > read a file (instead of just reading the directory).  And as I said, it's
> > not realistic to think that opening and reading a file is going to beat
> > opening and reading a directory for speed.
>
>But opening and reading one file should beat opening hundreds of directories :
>In the PEP 376 prototype, after thinking about a per-directory cache
>like you are
>describing, I was thinking about having a global index file to replace
>the global dictionnary that keeps track of the distributions per
>directory (currently the directory path
>is  the key in the dictionnary and the value the distribution objects).
>
>That can even be a simple shelve of the dictionary, that become a
>global index of directories
>that [are/were once] in the path. This works as long as the index file
>is per-user.
>Or even better : per-application. I don't know how this could be
>managed/done, but
>a simple cache file created alongside the script the application is
>launched with, could
>speed up the lookups at the second launch.

You'd still have to stat the directories to know if they changed - in 
which case the logic I've already laid out still applies.

I think, however, we are discussing different nominal scenarios.  I'm 
assuming a post-PEP 376 world where the only use for .egg files or 
directories are for *non-default* versions of packages, that only get 
added to sys.path for apps or libraries that need them, rather than 
being in a default .pth file.

However, if you're discussing speeding up an environment where we use 
.egg directories and they're on sys.path, then a per-user global 
cache might speed things up.  For security reasons, however, that 
cache would need to be ignored by Python when running secure 
scripts.  (e.g. -s and -E options, and definitely anything setuid.)

In contrast, directory stat caching with a modest number of (non-egg) 
PYTHONPATH entries would speed things nicely in the 
hopefully-future-default case.


From mal at egenix.com  Mon Aug  3 10:45:13 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 03 Aug 2009 10:45:13 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>
Message-ID: <4A76A399.4040003@egenix.com>

Tarek Ziad? wrote:
> Hello
> 
> For http://bugs.python.org/issue6555, I was wondering if anyone recall
> why we have two different names (pydistutils.cfg vs distutils.cfg)
> 
> As Zookoo pointed (and Google, if I search for "distutils.cfg
> pydistutils.cfg" :) ) it brings a lot of confusion, and I would like
> to deprecate pydistutils.cfg

.pydistutils.cfg is placed in the home dir of the user. In order
to establish some connection with Python, the "py" prefix was added.
All other location already have an implicit relationship with Python,
so the prefix is not needed.

It would be nice to have a user config *directory* for all Python
config things, e.g. ~/.python/. Then it'd be natural to drop
the ".py" prefix. Without the prefix, people would have a hard time
connecting a .distutils.cfg in their home dir with Python.

> and have ".distutils.cfg" and "distutils.cfg" for the user-level file
> (unless someone finds a good reason it has to be different)

-- 
Marc-Andre Lemburg
eGenix.com

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

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ben+python at benfinney.id.au  Mon Aug  3 10:40:31 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 03 Aug 2009 18:40:31 +1000
Subject: [Distutils] Update on recent distutils (and related projects)
	progress
Message-ID: <87my6hs328.fsf@benfinney.id.au>

Howdy all,

Second only to doing work on improvement is to *make it known* what
improvements are going on. So, thank you very much to Tarek Ziad? for
spending the time on status updates for recent distutils-related work
<URL:http://tarekziade.wordpress.com/2009/07/24/words-on-distribute-distutils-pep-376-pep-386-pep-345/>.

-- 
 \         ?I have the simplest tastes. I am always satisfied with the |
  `\                                               best.? ?Oscar Wilde |
_o__)                                                                  |
Ben Finney


From barry at python.org  Mon Aug  3 21:48:32 2009
From: barry at python.org (Barry Warsaw)
Date: Mon, 3 Aug 2009 15:48:32 -0400
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <4A76A399.4040003@egenix.com>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>
	<4A76A399.4040003@egenix.com>
Message-ID: <EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>

On Aug 3, 2009, at 4:45 AM, M.-A. Lemburg wrote:

> It would be nice to have a user config *directory* for all Python
> config things, e.g. ~/.python/. Then it'd be natural to drop
> the ".py" prefix. Without the prefix, people would have a hard time
> connecting a .distutils.cfg in their home dir with Python.

Python already uses ~/.local for stuff.  It should go in there.

-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/20090803/a88fa814/attachment.pgp>

From mal at egenix.com  Tue Aug  4 10:43:07 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 04 Aug 2009 10:43:07 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>	<4A76A399.4040003@egenix.com>
	<EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>
Message-ID: <4A77F49B.3000008@egenix.com>

Barry Warsaw wrote:
> On Aug 3, 2009, at 4:45 AM, M.-A. Lemburg wrote:
> 
>> It would be nice to have a user config *directory* for all Python
>> config things, e.g. ~/.python/. Then it'd be natural to drop
>> the ".py" prefix. Without the prefix, people would have a hard time
>> connecting a .distutils.cfg in their home dir with Python.
> 
> Python already uses ~/.local for stuff.  It should go in there.

You have a point there... we could put the user local config
files into ~/.local/lib/python2.6/ and then name it distutils.cfg
just like for the system-wide install.

-- 
Marc-Andre Lemburg
eGenix.com

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

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ziade.tarek at gmail.com  Tue Aug  4 10:52:27 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 10:52:27 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <4A77F49B.3000008@egenix.com>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>
	<4A76A399.4040003@egenix.com>
	<EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>
	<4A77F49B.3000008@egenix.com>
Message-ID: <94bdd2610908040152y329f1977ub3f2af872b056d94@mail.gmail.com>

2009/8/4 M.-A. Lemburg <mal at egenix.com>:
> Barry Warsaw wrote:
>> On Aug 3, 2009, at 4:45 AM, M.-A. Lemburg wrote:
>>
>>> It would be nice to have a user config *directory* for all Python
>>> config things, e.g. ~/.python/. Then it'd be natural to drop
>>> the ".py" prefix. Without the prefix, people would have a hard time
>>> connecting a .distutils.cfg in their home dir with Python.
>>
>> Python already uses ~/.local for stuff. ?It should go in there.
>
> You have a point there... we could put the user local config
> files into ~/.local/lib/python2.6/ and then name it distutils.cfg
> just like for the system-wide install.

So in that case I suppose I have to lookup at PYTHONUSERBASE as well,
as done on site.py.

I also propose if that's the case, to add a function in site.py that
returns USER_SITE and USER_BASE,
so it can be used by site.addusersitepackages *and* by distutils here

Regards
Tarek


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

From mal at egenix.com  Tue Aug  4 10:57:32 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 04 Aug 2009 10:57:32 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <94bdd2610908040152y329f1977ub3f2af872b056d94@mail.gmail.com>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>	<4A76A399.4040003@egenix.com>	<EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>	<4A77F49B.3000008@egenix.com>
	<94bdd2610908040152y329f1977ub3f2af872b056d94@mail.gmail.com>
Message-ID: <4A77F7FC.8060700@egenix.com>

Tarek Ziad? wrote:
> 2009/8/4 M.-A. Lemburg <mal at egenix.com>:
>> Barry Warsaw wrote:
>>> On Aug 3, 2009, at 4:45 AM, M.-A. Lemburg wrote:
>>>
>>>> It would be nice to have a user config *directory* for all Python
>>>> config things, e.g. ~/.python/. Then it'd be natural to drop
>>>> the ".py" prefix. Without the prefix, people would have a hard time
>>>> connecting a .distutils.cfg in their home dir with Python.
>>>
>>> Python already uses ~/.local for stuff.  It should go in there.
>>
>> You have a point there... we could put the user local config
>> files into ~/.local/lib/python2.6/ and then name it distutils.cfg
>> just like for the system-wide install.
> 
> So in that case I suppose I have to lookup at PYTHONUSERBASE as well,
> as done on site.py.
> 
> I also propose if that's the case, to add a function in site.py that
> returns USER_SITE and USER_BASE,
> so it can be used by site.addusersitepackages *and* by distutils here

+1

While you're at it, please also add a function that returns the
global site-packages dir(s).

-- 
Marc-Andre Lemburg
eGenix.com

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

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From syd at plug.ca  Tue Aug  4 18:29:59 2009
From: syd at plug.ca (Sydney Weidman)
Date: Tue, 4 Aug 2009 09:29:59 -0700 (PDT)
Subject: [Distutils] problem with zc.buildout download-cache setting
Message-ID: <e01c501c-ff37-4cb7-8afd-dd0c56848957@r25g2000vbn.googlegroups.com>

I have a buildout recipe (zc.buildout 1.3.0) for a Plone site I'm
building and it contains the line:

download-cache = downloads

but I find that when I run bin/buildout, the directory does not get
created and I get the following traceback:

[educommons at vrs OCWBuildout]$ bin/buildout -Uv
While:
  Initializing.
Error: The specified download cache:
'/home/educommons/OCWBuildout/downloads'
Doesn't exist.

The code from zc.buildout.buildout looks like:

        download_cache = options.get('download-cache')
        if download_cache:
            download_cache = os.path.join(options['directory'],
download_cache)
            if not os.path.isdir(download_cache):
                raise zc.buildout.UserError(
                    'The specified download cache:\n'
                    '%r\n'
                    "Doesn't exist.\n"
                    % download_cache)
            download_cache = os.path.join(download_cache, 'dist')
            if not os.path.isdir(download_cache):
                os.mkdir(download_cache)

            zc.buildout.easy_install.download_cache(download_cache)


It seems odd to me that if the download_cache directory doesn't exist,
that UserError is raised. Shouldn't the directory be created? What
would be the harm in that? Or am I missing something?

I realize that I could just mkdir downloads and it would work, but it
seems to defeat the simplicity of "python bootstrap.py; bin/buidout;
bin/instance start".

I'm sure this is some failure of understanding on my part, otherwise
I'm sure someone else would have encountered this issue before.

Regards,
Syd


From jim at zope.com  Tue Aug  4 19:22:45 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 4 Aug 2009 13:22:45 -0400
Subject: [Distutils] problem with zc.buildout download-cache setting
In-Reply-To: <e01c501c-ff37-4cb7-8afd-dd0c56848957@r25g2000vbn.googlegroups.com>
References: <e01c501c-ff37-4cb7-8afd-dd0c56848957@r25g2000vbn.googlegroups.com>
Message-ID: <1099b90b0908041022l17f58426g4f82cf59abb3c75e@mail.gmail.com>

On Tue, Aug 4, 2009 at 12:29 PM, Sydney Weidman<syd at plug.ca> wrote:
...
> It seems odd to me that if the download_cache directory doesn't exist,
> that UserError is raised. Shouldn't the directory be created? What
> would be the harm in that? Or am I missing something?
>
> I realize that I could just mkdir downloads and it would work, but it
> seems to defeat the simplicity of "python bootstrap.py; bin/buidout;
> bin/instance start".

Download caches intended to be shared between buildouts, so they
aren't considered part of the buildout and aren't created as part of
bootstrapping the buildout.

buildout doesn't create the download cache for fear of hiding a
configuration bug.

Jim

-- 
Jim Fulton

From ziade.tarek at gmail.com  Tue Aug  4 22:50:26 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 22:50:26 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file names +
	release/branches roadmap
Message-ID: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>

Hi,

I am working on the last bits to be able to release 0.6

1/ Distribute and zc.buildout

I started to work on the last bootstraping problem we have : make sure
zc.buildout users can use it.

I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
is a patched version of zc.buildout's bootstrap.py. This version makes
sure Distribute is installed
and activated in a buildout environment. It's also in the repo, in the
buildout directory.

Again, this requires a lot of real-world testing before we can ship
0.6. I've started to test various combinations on my side, but as I
did for the previous bootstraping
script, I wouldn't mind having some feedback of various people on this.

If you use zc.buildout, you can try it by replacing the bootstrap.py
file that comes with your buildout with the one I work on, then

a/ add "distribute" to the required eggs in your buildout cfg file

b/ run or re-run the bootstrap:

$ wget http://nightly.ziade.org/bootstrap.py
$ python bootstrap.py

If it worked, your buildout should build and work just fine, and the
scripts located in bin/ should have their sys.path augmented with
the distribute egg. Last, the setuptools egg is faked and you wil
notice that it's empty. This has to be done so zc.buildout and any
software
out there that has a hardcoded dependency on setuptools thinks it's present.

This is reversible, by running the original bootstrap and removing the
egg dependency added in the cfg file.

Please let me know if you try and get in any trouble. I was able to
run a plone buildout on my side with no problems.

2/ bootstraping file names

To avoid any confusion, I've changed distribute's bootstrap file name.
So we will have:

- ez_setup.py = setuptools bootstrap file
- bootstraping.py = distribute bootstrap file
- bootstrap.py = zc.buildout bootstrap file

If you think "bootstraping" is a silly name, or have a better
proposition, please let me know.

3/ release/branches roadmap

I'll probably release 0.6 before the end of this week and I expect
pushing a 0.6.1 one if we find big
issues with the bootstraping we didn't see before, when the release goes live.

As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
and we will be able to
work on 0.7 on the default branch, including the Python 3 work. Other
Py3k remaning branches
will be removed/stripped.  I think this is a simpler approach.

The 0.7 release will get ridd of the bootstraps script and create
several distributions, so a
massive refactoring is expected. I don't know if this will make it
harder for py3k work, Lennart, Ronald ?


Cheers
Tarek

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

From SridharR at activestate.com  Tue Aug  4 22:56:32 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 13:56:32 -0700
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
Message-ID: <op.ux5ogigxbrrvlq@double>

What if I already have setuptools installed in the Python installation?

sridharr at double:/tmp/tarek1$ apy bootstrap.py
Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
bootstrap.py:42: UserWarning: Module pkg_resources was already imported  
 from /tmp/tmpCH7Pdb/distribute-0.6-py2.6.egg/pkg_resources.py, but  
/opt/ActivePython-2.6/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg  
is being added to sys.path
   reload(pkg_resources)
bootstrap.py:42: UserWarning: Module setuptools was already imported from  
/tmp/tmpCH7Pdb/distribute-0.6-py2.6.egg/setuptools/__init__.py, but  
/opt/ActivePython-2.6/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg  
is being added to sys.path
   reload(pkg_resources)
bootstrap.py:42: UserWarning: Module site was already imported from  
/opt/ActivePython-2.6/lib/python2.6/site.pyc, but  
/opt/ActivePython-2.6/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg  
is being added to sys.path
   reload(pkg_resources)

-srid

On Tue, 04 Aug 2009 13:50:26 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> Hi,
>
> I am working on the last bits to be able to release 0.6
>
> 1/ Distribute and zc.buildout
>
> I started to work on the last bootstraping problem we have : make sure
> zc.buildout users can use it.
>
> I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
> is a patched version of zc.buildout's bootstrap.py. This version makes
> sure Distribute is installed
> and activated in a buildout environment. It's also in the repo, in the
> buildout directory.
>
> Again, this requires a lot of real-world testing before we can ship
> 0.6. I've started to test various combinations on my side, but as I
> did for the previous bootstraping
> script, I wouldn't mind having some feedback of various people on this.
>
> If you use zc.buildout, you can try it by replacing the bootstrap.py
> file that comes with your buildout with the one I work on, then
>
> a/ add "distribute" to the required eggs in your buildout cfg file
>
> b/ run or re-run the bootstrap:
>
> $ wget http://nightly.ziade.org/bootstrap.py
> $ python bootstrap.py
>
> If it worked, your buildout should build and work just fine, and the
> scripts located in bin/ should have their sys.path augmented with
> the distribute egg. Last, the setuptools egg is faked and you wil
> notice that it's empty. This has to be done so zc.buildout and any
> software
> out there that has a hardcoded dependency on setuptools thinks it's  
> present.
>
> This is reversible, by running the original bootstrap and removing the
> egg dependency added in the cfg file.
>
> Please let me know if you try and get in any trouble. I was able to
> run a plone buildout on my side with no problems.
>
> 2/ bootstraping file names
>
> To avoid any confusion, I've changed distribute's bootstrap file name.
> So we will have:
>
> - ez_setup.py = setuptools bootstrap file
> - bootstraping.py = distribute bootstrap file
> - bootstrap.py = zc.buildout bootstrap file
>
> If you think "bootstraping" is a silly name, or have a better
> proposition, please let me know.
>
> 3/ release/branches roadmap
>
> I'll probably release 0.6 before the end of this week and I expect
> pushing a 0.6.1 one if we find big
> issues with the bootstraping we didn't see before, when the release goes  
> live.
>
> As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
> and we will be able to
> work on 0.7 on the default branch, including the Python 3 work. Other
> Py3k remaning branches
> will be removed/stripped.  I think this is a simpler approach.
>
> The 0.7 release will get ridd of the bootstraps script and create
> several distributions, so a
> massive refactoring is expected. I don't know if this will make it
> harder for py3k work, Lennart, Ronald ?
>
>
> Cheers
> Tarek

From ziade.tarek at gmail.com  Tue Aug  4 22:59:12 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 22:59:12 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <op.ux5ogigxbrrvlq@double>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<op.ux5ogigxbrrvlq@double>
Message-ID: <94bdd2610908041359m72b3648l9fd3a55f85d40384@mail.gmail.com>

2009/8/4 Sridhar Ratnakumar <SridharR at activestate.com>:
> What if I already have setuptools installed in the Python installation?

besides the warnings, it should be OK

You can also install distribute over your setuptools by running bootstraping.py

$ wget http://nightly.ziade.org/bootstraping.py
$ python bootstraping.py

>
> sridharr at double:/tmp/tarek1$ apy bootstrap.py
> Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
> bootstrap.py:42: UserWarning: Module pkg_resources was already imported from
> /tmp/tmpCH7Pdb/distribute-0.6-py2.6.egg/pkg_resources.py, but
> /opt/ActivePython-2.6/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg
> is being added to sys.path
> ?reload(pkg_resources)
> bootstrap.py:42: UserWarning: Module setuptools was already imported from
> /tmp/tmpCH7Pdb/distribute-0.6-py2.6.egg/setuptools/__init__.py, but
> /opt/ActivePython-2.6/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg
> is being added to sys.path
> ?reload(pkg_resources)
> bootstrap.py:42: UserWarning: Module site was already imported from
> /opt/ActivePython-2.6/lib/python2.6/site.pyc, but
> /opt/ActivePython-2.6/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg
> is being added to sys.path
> ?reload(pkg_resources)
>
> -srid
>
> On Tue, 04 Aug 2009 13:50:26 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>> Hi,
>>
>> I am working on the last bits to be able to release 0.6
>>
>> 1/ Distribute and zc.buildout
>>
>> I started to work on the last bootstraping problem we have : make sure
>> zc.buildout users can use it.
>>
>> I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
>> is a patched version of zc.buildout's bootstrap.py. This version makes
>> sure Distribute is installed
>> and activated in a buildout environment. It's also in the repo, in the
>> buildout directory.
>>
>> Again, this requires a lot of real-world testing before we can ship
>> 0.6. I've started to test various combinations on my side, but as I
>> did for the previous bootstraping
>> script, I wouldn't mind having some feedback of various people on this.
>>
>> If you use zc.buildout, you can try it by replacing the bootstrap.py
>> file that comes with your buildout with the one I work on, then
>>
>> a/ add "distribute" to the required eggs in your buildout cfg file
>>
>> b/ run or re-run the bootstrap:
>>
>> $ wget http://nightly.ziade.org/bootstrap.py
>> $ python bootstrap.py
>>
>> If it worked, your buildout should build and work just fine, and the
>> scripts located in bin/ should have their sys.path augmented with
>> the distribute egg. Last, the setuptools egg is faked and you wil
>> notice that it's empty. This has to be done so zc.buildout and any
>> software
>> out there that has a hardcoded dependency on setuptools thinks it's
>> present.
>>
>> This is reversible, by running the original bootstrap and removing the
>> egg dependency added in the cfg file.
>>
>> Please let me know if you try and get in any trouble. I was able to
>> run a plone buildout on my side with no problems.
>>
>> 2/ bootstraping file names
>>
>> To avoid any confusion, I've changed distribute's bootstrap file name.
>> So we will have:
>>
>> - ez_setup.py = setuptools bootstrap file
>> - bootstraping.py = distribute bootstrap file
>> - bootstrap.py = zc.buildout bootstrap file
>>
>> If you think "bootstraping" is a silly name, or have a better
>> proposition, please let me know.
>>
>> 3/ release/branches roadmap
>>
>> I'll probably release 0.6 before the end of this week and I expect
>> pushing a 0.6.1 one if we find big
>> issues with the bootstraping we didn't see before, when the release goes
>> live.
>>
>> As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
>> and we will be able to
>> work on 0.7 on the default branch, including the Python 3 work. Other
>> Py3k remaning branches
>> will be removed/stripped. ?I think this is a simpler approach.
>>
>> The 0.7 release will get ridd of the bootstraps script and create
>> several distributions, so a
>> massive refactoring is expected. I don't know if this will make it
>> harder for py3k work, Lennart, Ronald ?
>>
>>
>> Cheers
>> Tarek
>



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

From SridharR at activestate.com  Tue Aug  4 22:59:41 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 13:59:41 -0700
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
Message-ID: <op.ux5olrgkbrrvlq@double>

Upon using a virtualenv:

$ virtualenv --no-site-packages env1
$ rm -rf env1/lib/python2.6/site-packages/* # remove previously installed  
setuptools
$ env1/bin/python bootstrap.py
Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
Traceback (most recent call last):
   File "bootstrap.py", line 41, in <module>
     if to_reload:
NameError: name 'to_reload' is not defined

This is because you haven't initialized `to_reload` *before* trying to run  
the code in the first try: block.

-srid

On Tue, 04 Aug 2009 13:50:26 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> Hi,
>
> I am working on the last bits to be able to release 0.6
>
> 1/ Distribute and zc.buildout
>
> I started to work on the last bootstraping problem we have : make sure
> zc.buildout users can use it.
>
> I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
> is a patched version of zc.buildout's bootstrap.py. This version makes
> sure Distribute is installed
> and activated in a buildout environment. It's also in the repo, in the
> buildout directory.
>
> Again, this requires a lot of real-world testing before we can ship
> 0.6. I've started to test various combinations on my side, but as I
> did for the previous bootstraping
> script, I wouldn't mind having some feedback of various people on this.
>
> If you use zc.buildout, you can try it by replacing the bootstrap.py
> file that comes with your buildout with the one I work on, then
>
> a/ add "distribute" to the required eggs in your buildout cfg file
>
> b/ run or re-run the bootstrap:
>
> $ wget http://nightly.ziade.org/bootstrap.py
> $ python bootstrap.py
>
> If it worked, your buildout should build and work just fine, and the
> scripts located in bin/ should have their sys.path augmented with
> the distribute egg. Last, the setuptools egg is faked and you wil
> notice that it's empty. This has to be done so zc.buildout and any
> software
> out there that has a hardcoded dependency on setuptools thinks it's  
> present.
>
> This is reversible, by running the original bootstrap and removing the
> egg dependency added in the cfg file.
>
> Please let me know if you try and get in any trouble. I was able to
> run a plone buildout on my side with no problems.
>
> 2/ bootstraping file names
>
> To avoid any confusion, I've changed distribute's bootstrap file name.
> So we will have:
>
> - ez_setup.py = setuptools bootstrap file
> - bootstraping.py = distribute bootstrap file
> - bootstrap.py = zc.buildout bootstrap file
>
> If you think "bootstraping" is a silly name, or have a better
> proposition, please let me know.
>
> 3/ release/branches roadmap
>
> I'll probably release 0.6 before the end of this week and I expect
> pushing a 0.6.1 one if we find big
> issues with the bootstraping we didn't see before, when the release goes  
> live.
>
> As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
> and we will be able to
> work on 0.7 on the default branch, including the Python 3 work. Other
> Py3k remaning branches
> will be removed/stripped.  I think this is a simpler approach.
>
> The 0.7 release will get ridd of the bootstraps script and create
> several distributions, so a
> massive refactoring is expected. I don't know if this will make it
> harder for py3k work, Lennart, Ronald ?
>
>
> Cheers
> Tarek

From jim at zope.com  Tue Aug  4 23:01:27 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 4 Aug 2009 17:01:27 -0400
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
Message-ID: <1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>

I'll be surprised if all that's needed to make buildout work with
Distribute is a new bootstrap script.

Note that my long term plan is to remove setuptools (or distribute) as
a dependency of buildout, although I don't know when I'll have time to
get to that.

Jim

On Tue, Aug 4, 2009 at 4:50 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> Hi,
>
> I am working on the last bits to be able to release 0.6
>
> 1/ Distribute and zc.buildout
>
> I started to work on the last bootstraping problem we have : make sure
> zc.buildout users can use it.
>
> I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
> is a patched version of zc.buildout's bootstrap.py. This version makes
> sure Distribute is installed
> and activated in a buildout environment. It's also in the repo, in the
> buildout directory.
>
> Again, this requires a lot of real-world testing before we can ship
> 0.6. I've started to test various combinations on my side, but as I
> did for the previous bootstraping
> script, I wouldn't mind having some feedback of various people on this.
>
> If you use zc.buildout, you can try it by replacing the bootstrap.py
> file that comes with your buildout with the one I work on, then
>
> a/ add "distribute" to the required eggs in your buildout cfg file
>
> b/ run or re-run the bootstrap:
>
> $ wget http://nightly.ziade.org/bootstrap.py
> $ python bootstrap.py
>
> If it worked, your buildout should build and work just fine, and the
> scripts located in bin/ should have their sys.path augmented with
> the distribute egg. Last, the setuptools egg is faked and you wil
> notice that it's empty. This has to be done so zc.buildout and any
> software
> out there that has a hardcoded dependency on setuptools thinks it's present.
>
> This is reversible, by running the original bootstrap and removing the
> egg dependency added in the cfg file.
>
> Please let me know if you try and get in any trouble. I was able to
> run a plone buildout on my side with no problems.
>
> 2/ bootstraping file names
>
> To avoid any confusion, I've changed distribute's bootstrap file name.
> So we will have:
>
> - ez_setup.py = setuptools bootstrap file
> - bootstraping.py = distribute bootstrap file
> - bootstrap.py = zc.buildout bootstrap file
>
> If you think "bootstraping" is a silly name, or have a better
> proposition, please let me know.
>
> 3/ release/branches roadmap
>
> I'll probably release 0.6 before the end of this week and I expect
> pushing a 0.6.1 one if we find big
> issues with the bootstraping we didn't see before, when the release goes live.
>
> As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
> and we will be able to
> work on 0.7 on the default branch, including the Python 3 work. Other
> Py3k remaning branches
> will be removed/stripped. ?I think this is a simpler approach.
>
> The 0.7 release will get ridd of the bootstraps script and create
> several distributions, so a
> massive refactoring is expected. I don't know if this will make it
> harder for py3k work, Lennart, Ronald ?
>
>
> Cheers
> Tarek
>
> --
> Tarek Ziad? | http://ziade.org
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Jim Fulton

From SridharR at activestate.com  Tue Aug  4 23:03:51 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 14:03:51 -0700
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908041359m72b3648l9fd3a55f85d40384@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<op.ux5ogigxbrrvlq@double>
	<94bdd2610908041359m72b3648l9fd3a55f85d40384@mail.gmail.com>
Message-ID: <op.ux5ospk4brrvlq@double>

On Tue, 04 Aug 2009 13:59:12 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> 2009/8/4 Sridhar Ratnakumar <SridharR at activestate.com>:
>> What if I already have setuptools installed in the Python installation?
> besides the warnings, it should be OK
> You can also install distribute over your setuptools by running  
> bootstraping.py
> $ wget http://nightly.ziade.org/bootstraping.py
> $ python bootstraping.py

Methinks for better transition (low switching cost) it would be better do  
this (which is currently done only by bootstrapping.py) in bootstrap.py  
itself. At least that's what the users expect zc.buildout's bootstrap.py  
to do (to wit: install setuptools if not already installed).

-srid

PS: The traceback I earlier reported about to_reload is solved by running  
bootstrapping.py prior to running bootstrap.py

From ziade.tarek at gmail.com  Tue Aug  4 23:04:21 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 23:04:21 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <op.ux5olrgkbrrvlq@double>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<op.ux5olrgkbrrvlq@double>
Message-ID: <94bdd2610908041404o42c8492fqdf72fc5841d7eb1@mail.gmail.com>

2009/8/4 Sridhar Ratnakumar <SridharR at activestate.com>:
> Upon using a virtualenv:
>
> $ virtualenv --no-site-packages env1
> $ rm -rf env1/lib/python2.6/site-packages/* # remove previously installed
> setuptools
> $ env1/bin/python bootstrap.py
> Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
> Traceback (most recent call last):
> ?File "bootstrap.py", line 41, in <module>
> ? ?if to_reload:
> NameError: name 'to_reload' is not defined
>
> This is because you haven't initialized `to_reload` *before* trying to run
> the code in the first try: block.

oups, I didn't upload the right version, it's now updated,
please get it back and try agin

>
> -srid
>
> On Tue, 04 Aug 2009 13:50:26 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>> Hi,
>>
>> I am working on the last bits to be able to release 0.6
>>
>> 1/ Distribute and zc.buildout
>>
>> I started to work on the last bootstraping problem we have : make sure
>> zc.buildout users can use it.
>>
>> I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
>> is a patched version of zc.buildout's bootstrap.py. This version makes
>> sure Distribute is installed
>> and activated in a buildout environment. It's also in the repo, in the
>> buildout directory.
>>
>> Again, this requires a lot of real-world testing before we can ship
>> 0.6. I've started to test various combinations on my side, but as I
>> did for the previous bootstraping
>> script, I wouldn't mind having some feedback of various people on this.
>>
>> If you use zc.buildout, you can try it by replacing the bootstrap.py
>> file that comes with your buildout with the one I work on, then
>>
>> a/ add "distribute" to the required eggs in your buildout cfg file
>>
>> b/ run or re-run the bootstrap:
>>
>> $ wget http://nightly.ziade.org/bootstrap.py
>> $ python bootstrap.py
>>
>> If it worked, your buildout should build and work just fine, and the
>> scripts located in bin/ should have their sys.path augmented with
>> the distribute egg. Last, the setuptools egg is faked and you wil
>> notice that it's empty. This has to be done so zc.buildout and any
>> software
>> out there that has a hardcoded dependency on setuptools thinks it's
>> present.
>>
>> This is reversible, by running the original bootstrap and removing the
>> egg dependency added in the cfg file.
>>
>> Please let me know if you try and get in any trouble. I was able to
>> run a plone buildout on my side with no problems.
>>
>> 2/ bootstraping file names
>>
>> To avoid any confusion, I've changed distribute's bootstrap file name.
>> So we will have:
>>
>> - ez_setup.py = setuptools bootstrap file
>> - bootstraping.py = distribute bootstrap file
>> - bootstrap.py = zc.buildout bootstrap file
>>
>> If you think "bootstraping" is a silly name, or have a better
>> proposition, please let me know.
>>
>> 3/ release/branches roadmap
>>
>> I'll probably release 0.6 before the end of this week and I expect
>> pushing a 0.6.1 one if we find big
>> issues with the bootstraping we didn't see before, when the release goes
>> live.
>>
>> As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
>> and we will be able to
>> work on 0.7 on the default branch, including the Python 3 work. Other
>> Py3k remaning branches
>> will be removed/stripped. ?I think this is a simpler approach.
>>
>> The 0.7 release will get ridd of the bootstraps script and create
>> several distributions, so a
>> massive refactoring is expected. I don't know if this will make it
>> harder for py3k work, Lennart, Ronald ?
>>
>>
>> Cheers
>> Tarek
>



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

From SridharR at activestate.com  Tue Aug  4 23:11:00 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 14:11:00 -0700
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908041404o42c8492fqdf72fc5841d7eb1@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<op.ux5olrgkbrrvlq@double>
	<94bdd2610908041404o42c8492fqdf72fc5841d7eb1@mail.gmail.com>
Message-ID: <op.ux5o4mldbrrvlq@double>

On Tue, 04 Aug 2009 14:04:21 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

>> $ virtualenv --no-site-packages env1
>> $ rm -rf env1/lib/python2.6/site-packages/* # remove previously  
>> installed
>> setuptools
>> $ env1/bin/python bootstrap.py
>> Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
>> Traceback (most recent call last):
>>  File "bootstrap.py", line 41, in <module>
>>    if to_reload:
>> NameError: name 'to_reload' is not defined
>>
>> This is because you haven't initialized `to_reload` *before* trying to  
>> run
>> the code in the first try: block.
> oups, I didn't upload the right version, it's now updated,
> please get it back and try agin

Ok, with the new bootstrap.py I have no need for bootstrapping.py.

bootstrap.py and the distribute egg it downloaded works fine here - all  
tests in pypm pass with s/setuptools/distribute.

So is Distribute going to be a 100% compatible replacement for setuptools?  
Suppose if some software ships with distribute and if the user later tries  
to install easy_install, what would happen? Cases like that.

-srid

From ziade.tarek at gmail.com  Tue Aug  4 23:11:23 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 23:11:23 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
Message-ID: <94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>

On Tue, Aug 4, 2009 at 11:01 PM, Jim Fulton<jim at zope.com> wrote:
> I'll be surprised if all that's needed to make buildout work with
> Distribute is a new bootstrap script.

well, after the bootstrap is over you end up with :

- a setuptools distribution still installed *but* empty
- a distribute distribution installed that provides the setuptools
package, the pkg_resources.py, site.py and easy_install.py files

which means that any code running afterwards will think setuptools is
installed and will import distrbute's files

at the moment I can see one case where it won't work: an __import__
done on the setuptools location
but so far my Plone works (this is the most complex use case I have so far)


>
> Note that my long term plan is to remove setuptools (or distribute) as
> a dependency of buildout, although I don't know when I'll have time to
> get to that.

until then I don't have a better plan to allow users to switch to the
fork, unless zc.buildout
is changed so setuptools installation it's not harcoded anymore in there

>
> Jim
>
> On Tue, Aug 4, 2009 at 4:50 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
>> Hi,
>>
>> I am working on the last bits to be able to release 0.6
>>
>> 1/ Distribute and zc.buildout
>>
>> I started to work on the last bootstraping problem we have : make sure
>> zc.buildout users can use it.
>>
>> I've uploaded at http://nightly.ziade.org/ a "bootstrap.py" file that
>> is a patched version of zc.buildout's bootstrap.py. This version makes
>> sure Distribute is installed
>> and activated in a buildout environment. It's also in the repo, in the
>> buildout directory.
>>
>> Again, this requires a lot of real-world testing before we can ship
>> 0.6. I've started to test various combinations on my side, but as I
>> did for the previous bootstraping
>> script, I wouldn't mind having some feedback of various people on this.
>>
>> If you use zc.buildout, you can try it by replacing the bootstrap.py
>> file that comes with your buildout with the one I work on, then
>>
>> a/ add "distribute" to the required eggs in your buildout cfg file
>>
>> b/ run or re-run the bootstrap:
>>
>> $ wget http://nightly.ziade.org/bootstrap.py
>> $ python bootstrap.py
>>
>> If it worked, your buildout should build and work just fine, and the
>> scripts located in bin/ should have their sys.path augmented with
>> the distribute egg. Last, the setuptools egg is faked and you wil
>> notice that it's empty. This has to be done so zc.buildout and any
>> software
>> out there that has a hardcoded dependency on setuptools thinks it's present.
>>
>> This is reversible, by running the original bootstrap and removing the
>> egg dependency added in the cfg file.
>>
>> Please let me know if you try and get in any trouble. I was able to
>> run a plone buildout on my side with no problems.
>>
>> 2/ bootstraping file names
>>
>> To avoid any confusion, I've changed distribute's bootstrap file name.
>> So we will have:
>>
>> - ez_setup.py = setuptools bootstrap file
>> - bootstraping.py = distribute bootstrap file
>> - bootstrap.py = zc.buildout bootstrap file
>>
>> If you think "bootstraping" is a silly name, or have a better
>> proposition, please let me know.
>>
>> 3/ release/branches roadmap
>>
>> I'll probably release 0.6 before the end of this week and I expect
>> pushing a 0.6.1 one if we find big
>> issues with the bootstraping we didn't see before, when the release goes live.
>>
>> As soon as 0.6 is tagged, I'll create a 0.6 branch for its maintenance
>> and we will be able to
>> work on 0.7 on the default branch, including the Python 3 work. Other
>> Py3k remaning branches
>> will be removed/stripped. ?I think this is a simpler approach.
>>
>> The 0.7 release will get ridd of the bootstraps script and create
>> several distributions, so a
>> massive refactoring is expected. I don't know if this will make it
>> harder for py3k work, Lennart, Ronald ?
>>
>>
>> Cheers
>> Tarek
>>
>> --
>> Tarek Ziad? | http://ziade.org
>> _______________________________________________
>> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
>
> --
> Jim Fulton
>



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

From ziade.tarek at gmail.com  Tue Aug  4 23:15:46 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 23:15:46 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <op.ux5o4mldbrrvlq@double>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<op.ux5olrgkbrrvlq@double>
	<94bdd2610908041404o42c8492fqdf72fc5841d7eb1@mail.gmail.com>
	<op.ux5o4mldbrrvlq@double>
Message-ID: <94bdd2610908041415j428b4acbn21aa83d31c73704e@mail.gmail.com>

On Tue, Aug 4, 2009 at 11:11 PM, Sridhar
Ratnakumar<SridharR at activestate.com> wrote:
> On Tue, 04 Aug 2009 14:04:21 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>>> $ virtualenv --no-site-packages env1
>>> $ rm -rf env1/lib/python2.6/site-packages/* # remove previously installed
>>> setuptools
>>> $ env1/bin/python bootstrap.py
>>> Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
>>> Traceback (most recent call last):
>>> ?File "bootstrap.py", line 41, in <module>
>>> ? if to_reload:
>>> NameError: name 'to_reload' is not defined
>>>
>>> This is because you haven't initialized `to_reload` *before* trying to
>>> run
>>> the code in the first try: block.
>>
>> oups, I didn't upload the right version, it's now updated,
>> please get it back and try agin
>
> Ok, with the new bootstrap.py I have no need for bootstrapping.py.
>
> bootstrap.py and the distribute egg it downloaded works fine here - all
> tests in pypm pass with s/setuptools/distribute.
>
> So is Distribute going to be a 100% compatible replacement for setuptools?

yes, only for the 0.6 release, to allow people to "gently" switch

> Suppose if some software ships with distribute and if the user later tries
> to install easy_install, what would happen? Cases like that.

if you try afterwards to install setuptools, it will tell you it's installed
if you force an upgrade, or use the original zc.buildout bootstrap,
you will get back to setuptools in your python *or* buildout
environment

notice that in any case third party apps should work fine, the only
difference is that DIstribute 0.6 fixes some bugs setuptools 0.6c9 has

>
> -srid
>



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

From jim at zope.com  Tue Aug  4 23:43:10 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 4 Aug 2009 17:43:10 -0400
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
Message-ID: <1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>

On Tue, Aug 4, 2009 at 5:11 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Tue, Aug 4, 2009 at 11:01 PM, Jim Fulton<jim at zope.com> wrote:
>> I'll be surprised if all that's needed to make buildout work with
>> Distribute is a new bootstrap script.
>
> well, after the bootstrap is over you end up with :
>
> - a setuptools distribution still installed *but* empty
> - a distribute distribution installed that provides the setuptools
> package, the pkg_resources.py, site.py and easy_install.py files
>
> which means that any code running afterwards will think setuptools is
> installed and will import distrbute's files
>
> at the moment I can see one case where it won't work: an __import__
> done on the setuptools location
> but so far my Plone works (this is the most complex use case I have so far)

Buildout will often reinstall setuptools, depending which version it
thinks it needs. I'd expect this to defeat whatever you've done.

>> Note that my long term plan is to remove setuptools (or distribute) as
>> a dependency of buildout, although I don't know when I'll have time to
>> get to that.
>
> until then I don't have a better plan to allow users to switch to the
> fork, unless zc.buildout
> is changed so setuptools installation it's not harcoded anymore in there

I guess I don't see an urgent need for buildout to use distribute.

If distribute is truly a setuptools clone, I suppose that the project
name to use could be configurable in buildout.  This would take some
work, but probably not that much.  That seems cleaner and less brittle
than hacking installed setuptools distributions.

Jim

-- 
Jim Fulton

From ziade.tarek at gmail.com  Tue Aug  4 23:57:21 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Aug 2009 23:57:21 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
Message-ID: <94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>

On Tue, Aug 4, 2009 at 11:43 PM, Jim Fulton<jim at zope.com> wrote:
>
> Buildout will often reinstall setuptools, depending which version it
> thinks it needs. I'd expect this to defeat whatever you've done.

Distribute "installs" setuptools 0.6c9, so unless buildout tries to
downgrade setuptools,
it should not defeat it,

Do you have a scenario in mind I can try ?

> If distribute is truly a setuptools clone,

it's the very same code, besides the bug fixes we applied, like the
svn 1.6 compatibility fix
and stuff like that.

> I suppose that the project
> name to use could be configurable in buildout. ?This would take some
> work, but probably not that much.

zc.buildout.Buildout class could be changed indeed, so methods like
boostrap() don't harcode
the setuptools distribution name anymore,

but how would you handle the install_requires field in zc.buildout ?

I mean, beside all the bootstrap, zc.buildout stills depends on the
'setuptools' dist, requiring
Distribute to fake it's installed, to avoid an "install battle" where
the last distribution installed wins.

Or, the setup.py script could try to import pkg_resources and decide
which value to put in
install_requires depending on what is installed, (choosing setuptools
by default if nothing is installed)

> ?That seems cleaner and less brittle
> than hacking installed setuptools distributions.
>

Unfortunalety, even outside zc.buildout, I don't see any other
solution than setting up a "fake" setuptools,
to avoid changes in third party softwares, like their "install_requires" field.

I see the 0.6 version of Distribute as a hack in any case, until
Distribute 0.7 change the package/modules names,

If anyone think about a better plan for the switch, speak up :)


Tarek

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

From m.van.rees at zestsoftware.nl  Wed Aug  5 12:33:52 2009
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 5 Aug 2009 10:33:52 +0000 (UTC)
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
Message-ID: <h5bn6g$v9p$1@ger.gmane.org>

Tarek Ziad?, on 2009-08-04:
> If you use zc.buildout, you can try it by replacing the bootstrap.py
> file that comes with your buildout with the one I work on, then
>
> a/ add "distribute" to the required eggs in your buildout cfg file
>
> b/ run or re-run the bootstrap:
>
> $ wget http://nightly.ziade.org/bootstrap.py
> $ python bootstrap.py

That seems to be working fine in a Plone buildout I tried it with.
Well, I tried this buildout:
http://svn.plone.org/svn/collective/Products.plonehrm/buildouts/trunk
and added the changes you mention above (not committed).

The bin/instance script has distribute in its path.  The bin/test file
does *not* contain distribute.  (Both have the normal setuptools egg
in their path.)  But since the bin/test script actually is a wrapper
around the bin/instance script this is probably okay.  At least when
running bin/test or bin/instance I get a few of these warnings:

/home/maurits/shared-eggs/plone.keyring-1.2-py2.4.egg/plone/__init__.py:3:
UserWarning: Module pkg_resources was already imported from
/home/maurits/shared-eggs/distribute-0.6-py2.4.egg/pkg_resources.pyc,
but /home/maurits/shared-eggs/setuptools-0.6c9-py2.4.egg is being
added to sys.path

It would be nice if those warnings could be avoided, but I assume this
is not possible.

All tests of my buildout pass and I can correctly create a Plone Site
with this and install the Plone HRM product.  So I would say this is
working fine, at least for this use case.

> 2/ bootstraping file names
>
> To avoid any confusion, I've changed distribute's bootstrap file name.
> So we will have:
>
> - ez_setup.py = setuptools bootstrap file
> - bootstraping.py = distribute bootstrap file
> - bootstrap.py = zc.buildout bootstrap file
>
> If you think "bootstraping" is a silly name, or have a better
> proposition, please let me know.

I would spell and pronounce it bootstrapping with a double 'p'.
googlefight.com sees 333,000 results for double 'p' and only 5,900 for
single 'p':
http://googlefight.com/index.php?lang=en_GB&word1=bootstrapping&word2=bootstraping

I know I would continuously spell it wrong if it was with a single
letter 'p'.


Thanks for your hard work!

-- 
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  Wed Aug  5 14:14:01 2009
From: jim at zope.com (Jim Fulton)
Date: Wed, 5 Aug 2009 08:14:01 -0400
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
Message-ID: <1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>

On Tue, Aug 4, 2009 at 5:57 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Tue, Aug 4, 2009 at 11:43 PM, Jim Fulton<jim at zope.com> wrote:
>>
>> Buildout will often reinstall setuptools, depending which version it
>> thinks it needs. I'd expect this to defeat whatever you've done.
>
> Distribute "installs" setuptools 0.6c9, so unless buildout tries to
> downgrade setuptools,
> it should not defeat it,

buildout will downgrade if an older version of setuptools is specified
in a versions section or in the setuptools-version option.

> Do you have a scenario in mind I can try ?

Read the tests for upgrading, which include downgrading.

...

> but how would you handle the install_requires field in zc.buildout ?

It would have to leave setuptools out of buildout's install_requires.
In general, if a package depends on any one of multiple dependencies,
I'd be inclined not to list the dependencies, but leave it up to the
installer to provide one.

...

>> ?That seems cleaner and less brittle
>> than hacking installed setuptools distributions.
>>
>
> Unfortunalety, even outside zc.buildout, I don't see any other
> solution than setting up a "fake" setuptools,
> to avoid changes in third party softwares, like their "install_requires" field.

I don't agree with this goal. Why not let 3rd-party developers add
support for distribute explicitly.

Can you explain why buildout *should* use distribute at this point?
What's in it for buildout users?

> I see the 0.6 version of Distribute as a hack in any case, until
> Distribute 0.7 change the package/modules names,

So Distribute 0.7 won't be backward compatible with 0.6?

> If anyone think about a better plan for the switch, speak up :)

If you think you can do better than setuptools, I think you should
come up with a different tool that has a different name.  You
shouldn't try to trick applications into running your tool.

My own view is that we shouldn't try to fork setuptools, but should do
something different and much smaller.  I think setuptools is far more
ambitious than it needs to be.

Here are some more specific thoughts:

Problems that I'd like to see solved:

- distutils doesn't currently provide a mechanism for tracking
distribution dependencies

- distutils doesn't allow extensible meta data.

- setuptools doesn't work with Python 3.

- setuptools has insane dependencies on revision control tools.

Here's how I'd solve these problems if I had enough time:

- I'd write a new tool to create packages.  This tool would only
create packages.  It would read static meta-data files and generate
setup.py and manifest files that don't depend on setuptools.  (It
might only be suitable for 97% of packages that need to be
distributed.) It would invoke the generated setup script to build
distributions.  It would cause egg-info directories to be included.
It would build on the egg-info "standard" established by setuptools.
It would not get involved with the distutils command framework in any
way. I'd work with Phillip and Ian to make sure these packages could
by consumed by easy_install and pip. Of course, I would make sure that
buildout could consume them.

- I'd (will) update buildout to not use setuptools.  It doesn;t use
much of setuptools now.  It would be great if we could come up with a
much smaller install library that multiple packages could share.

Jim

-- 
Jim Fulton

From ziade.tarek at gmail.com  Wed Aug  5 15:13:11 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 5 Aug 2009 15:13:11 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
Message-ID: <94bdd2610908050613i2350658ah74740cf4deecb09d@mail.gmail.com>

On Wed, Aug 5, 2009 at 2:14 PM, Jim Fulton<jim at zope.com> wrote:
> On Tue, Aug 4, 2009 at 5:57 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
>> On Tue, Aug 4, 2009 at 11:43 PM, Jim Fulton<jim at zope.com> wrote:
>>>
>>> Buildout will often reinstall setuptools, depending which version it
>>> thinks it needs. I'd expect this to defeat whatever you've done.
>>
>> Distribute "installs" setuptools 0.6c9, so unless buildout tries to
>> downgrade setuptools,
>> it should not defeat it,
>
> buildout will downgrade if an older version of setuptools is specified
> in a versions section or in the setuptools-version option.
>
>> Do you have a scenario in mind I can try ?
>
> Read the tests for upgrading, which include downgrading.

Then it means that the user explicitely downgraded setuptools in its buildout
cfg file, which is a case that I am not handling : if people want to
use distribute they'll have to fix their cfg.

>> Unfortunalety, even outside zc.buildout, I don't see any other
>> solution than setting up a "fake" setuptools,
>> to avoid changes in third party softwares, like their "install_requires" field.
>
> I don't agree with this goal. Why not let 3rd-party developers add
> support for distribute explicitly.
>
> Can you explain why buildout *should* use distribute at this point?
> What's in it for buildout users?

to benefit from all the bug fixes we did of course,

http://bitbucket.org/tarek/distribute/wiki/bug_listing

And I am not expecting +250 distributions and more to switch like that,
being able to switch without changing anything except the bootstrap and
the cfg file(s) and work on already existing distributions (plone.*, zope.*)
is a major win.

If we don't do this, it'll take months or more for all dependencies
to get released again.

We want to the fixes *now* then work on a better implementation.


>
>> I see the 0.6 version of Distribute as a hack in any case, until
>> Distribute 0.7 change the package/modules names,
>
> So Distribute 0.7 won't be backward compatible with 0.6?
>
>> If anyone think about a better plan for the switch, speak up :)
>
> If you think you can do better than setuptools, I think you should
> come up with a different tool that has a different name. ?You
> shouldn't try to trick applications into running your tool.

Distribute 0.6 is the will-never-be-released setuptols 0.6
I don't want  people to have these two only choices:

- stick with setuptools that has not changed for +9 months
  and wait for an hypotetical release
- wait for a distribute completely rethaught 0.7 version
  wait for zope, plone and al to switch on it

With distribute 0.6 it allows people to have an upgraded setuptools-like
distribution that allows them to use the existing, release softwares.

So unless someone else strongly opposes to this plan, this version
will be released nevertheless.

I believe the Plone community waits for it.

>
> My own view is that we shouldn't try to fork setuptools, but should do
> something different and much smaller. ?I think setuptools is far more
> ambitious than it needs to be.

That's the plan for Distrtibute 0.7 too (having several ditinct distributions)

> Here's how I'd solve these problems if I had enough time:
> [...]
> ... I'd work with Phillip ...

As you might have noticed, Phillip doesn't have the time anymore to work
on setuptools code base. This was why we started this fork: to unlock the
community from this bottleneck situation.

So I don't see how we could solve anything if we work with a project
that doesn't
make anymore change, and that is owned by someone who doesn't have
the time and who is not willing to let us work in it.

With all respect to PJE, my opinion is that this locked situation demonstrates
that the community needs to move away as soon as possible from the setuptools
project because it's not community-driven neither in the spirit of open source.

What I mean by "open source spirit" is :

It's ok (and probably a good idea) to have a dictator in a open source
project, but it's not OK when the dictator
is AWOL, which is the case right here. When it happens, a fork is needed,
unless the dictator gives the key of the locker to other people (that
have some time in turn of course)

For instance, you are the zc.buildout dictator, but you have unlocked
its maintenance to
the community because (that's what I have understood) you don't have
the time anymore
to work on it, and you think it's stable and advanced enough, and
because you *trust* the zope community
will eventually do a good job.

I am disappointed this scenario didn't happen with setuptools, because
that's what I'd have expected.


>
> - I'd (will) update buildout to not use setuptools. ?It doesn;t use
> much of setuptools now. ?It would be great if we could come up with a
> much smaller install library that multiple packages could share.
>
> Jim
>
> --
> Jim Fulton
>



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

From pje at telecommunity.com  Wed Aug  5 19:36:05 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 05 Aug 2009 13:36:05 -0400
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.co
 m>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
Message-ID: <20090805173611.869683A406B@sparrow.telecommunity.com>

At 08:14 AM 8/5/2009 -0400, Jim Fulton wrote:
>It would be great if we could come up with a
>much smaller install library that multiple packages could share.

I've previously proposed to split out installation stuff (plus 
pkg_resources) to such a library, leaving just the 
setup.py/easy_install aspects in setuptools proper.  This is 
currently still a vaporware proposal, but I've at least done a bit 
more specific code sketching since then.  The original concept notes 
can be found here:

http://mail.python.org/pipermail/distutils-sig/2009-July/012685.html

I don't know if this is exactly what you had in mind, but I expect 
it's at least somewhat similar; your previous request for 
"easy_install as a set of independent functions" was not forgotten.  ;-)


From ziade.tarek at gmail.com  Wed Aug  5 22:46:33 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 5 Aug 2009 22:46:33 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <h5bn6g$v9p$1@ger.gmane.org>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<h5bn6g$v9p$1@ger.gmane.org>
Message-ID: <94bdd2610908051346n40c8dba0mb9f9185a049f7258@mail.gmail.com>

On Wed, Aug 5, 2009 at 12:33 PM, Maurits van
Rees<m.van.rees at zestsoftware.nl> wrote:
>
> It would be nice if those warnings could be avoided, but I assume this
> is not possible.

They should not pop for now on (if you get the freshest nightly build)

>>
>> If you think "bootstraping" is a silly name, or have a better
>> proposition, please let me know.
>
> I would spell and pronounce it bootstrapping with a double 'p'.

Done.

> googlefight.com sees 333,000 results for double 'p' and only 5,900 for
> single 'p':
> http://googlefight.com/index.php?lang=en_GB&word1=bootstrapping&word2=bootstraping
>
> I know I would continuously spell it wrong if it was with a single
> letter 'p'.
>
>
> Thanks for your hard work!

Thanks for cheering. I am done now with the bootstra*p*ping work and
ready to publish 0.6

0.6.1 will contain more bugfixes but at least, people will be able to
upgrade and contributors
to work on patches in a friendly DVCS environment, while we
concentrate on splitting the
distribution, and on py3k.

I will also switch back on my side on PEP 376 work and distutils, and
hope some other
people will start to contribute in Distribute.

I'll wait for any other feedback and for Hanno feedback (they are
sprinting in Bristol/UK)
and I'll push a release Thirsday or Friday unless some bad feedback occurs.

Cheers
Tarek

From regebro at gmail.com  Thu Aug  6 08:23:21 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 6 Aug 2009 08:23:21 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
Message-ID: <319e029f0908052323s3dac24f1s849d8322539f2a07@mail.gmail.com>

2009/8/4 Tarek Ziad? <ziade.tarek at gmail.com>:
> If you think "bootstraping" is a silly name, or have a better
> proposition, please let me know.

Well, bootstrapping with two p's, otherwise it's  fine.

> The 0.7 release will get ridd of the bootstraps script and create
> several distributions, so a
> massive refactoring is expected. I don't know if this will make it
> harder for py3k work, Lennart, Ronald ?

No, I can't come up with a reason why it would.

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

From regebro at gmail.com  Thu Aug  6 08:38:51 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 6 Aug 2009 08:38:51 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
Message-ID: <319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>

2009/8/5 Jim Fulton <jim at zope.com>:
>> Unfortunalety, even outside zc.buildout, I don't see any other
>> solution than setting up a "fake" setuptools,
>> to avoid changes in third party softwares, like their "install_requires" field.
>
> I don't agree with this goal. Why not let 3rd-party developers add
> support for distribute explicitly.

Hmm. Are there any serious bugs in setuptools that raises their head
when you *install* something?
I know of the svn bugs, etc, but they are when you create the package.
If the serious bugs are just when distributing, then we don't actually
need to replace setuptools when installing.

But faking it may not be needed. Distribute should reasonably itself
know that it replaces setuptools and not install it just because it's
in install_requires. And for buildout, it would in that case be better
if a new release of buildout uses distribute instead of setuptools.

> My own view is that we shouldn't try to fork setuptools, but should do
> something different and much smaller. ?I think setuptools is far more
> ambitious than it needs to be.

This is true, but the fork is necessary to get something working, now.

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

From ziade.tarek at gmail.com  Thu Aug  6 09:05:33 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 09:05:33 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
Message-ID: <94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>

2009/8/6 Lennart Regebro <regebro at gmail.com>:
> But faking it may not be needed.

Yes it's needed. Even if some people switch to Distribute in their
projects, as soon as you install
a project that is still on Setuptools, it will overwrite Distribute
files with no warning.
You can't have both installed unless we rename all packages and "top" modules

From regebro at gmail.com  Thu Aug  6 09:24:34 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 6 Aug 2009 09:24:34 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
	<94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
Message-ID: <319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>

2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
> Yes it's needed. Even if some people switch to Distribute in their
> projects, as soon as you install
> a project that is still on Setuptools, it will overwrite Distribute
> files with no warning.

But wait... if you install distribute, and you then install a project
that depends on setuptools, you say it will be installed.

But... isn't it distribute doing that installation? In that case, we
could just not install setuptools? :-)

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

From ziade.tarek at gmail.com  Thu Aug  6 09:46:20 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 09:46:20 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
	<94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
	<319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>
	<94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>
Message-ID: <94bdd2610908060046t1a41d131p580325537b3f03cd@mail.gmail.com>

On Thu, Aug 6, 2009 at 9:45 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
>
> no, it will be faked. meaning that just the PKG-INFO will be presented,
> thus detected by pkg_resources. But at the end the setuptools *package*,
> the pkg_resources.py and site.py files will be the one installed by setuptools.

s/setuptools/distribute

From ziade.tarek at gmail.com  Thu Aug  6 09:45:40 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 09:45:40 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
	<94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
	<319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>
Message-ID: <94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>

On Thu, Aug 6, 2009 at 9:24 AM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
>> Yes it's needed. Even if some people switch to Distribute in their
>> projects, as soon as you install
>> a project that is still on Setuptools, it will overwrite Distribute
>> files with no warning.
>
> But wait... if you install distribute, and you then install a project
> that depends on setuptools, you say it will be installed.

no, it will be faked. meaning that just the PKG-INFO will be presented,
thus detected by pkg_resources. But at the end the setuptools *package*,
the pkg_resources.py and site.py files will be the one installed by setuptools.

>
> But... isn't it distribute doing that installation? In that case, we
> could just not install setuptools? :-)

Not sure what you mean here.

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



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

From regebro at gmail.com  Thu Aug  6 09:53:26 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 6 Aug 2009 09:53:26 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
	<94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
	<319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>
	<94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>
Message-ID: <319e029f0908060053k433d07e3wc6ef42e3a3fa64cb@mail.gmail.com>

2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Thu, Aug 6, 2009 at 9:24 AM, Lennart Regebro<regebro at gmail.com> wrote:
>> 2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
>>> Yes it's needed. Even if some people switch to Distribute in their
>>> projects, as soon as you install
>>> a project that is still on Setuptools, it will overwrite Distribute
>>> files with no warning.
>>
>> But wait... if you install distribute, and you then install a project
>> that depends on setuptools, you say it will be installed.
>
> no, it will be faked. meaning that just the PKG-INFO will be presented,
> thus detected by pkg_resources. But at the end the setuptools *package*,
> the pkg_resources.py and site.py files will be the one installed by <distribute>.

I'm confused. You said that if a project is still on setuptools it
will overwrite distribute. Now you said it wouldn't.

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

From ziade.tarek at gmail.com  Thu Aug  6 10:10:28 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 10:10:28 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <319e029f0908060053k433d07e3wc6ef42e3a3fa64cb@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
	<94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
	<319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>
	<94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>
	<319e029f0908060053k433d07e3wc6ef42e3a3fa64cb@mail.gmail.com>
Message-ID: <94bdd2610908060110m6028def9udb135bd388cd2ef7@mail.gmail.com>

On Thu, Aug 6, 2009 at 9:53 AM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
>> On Thu, Aug 6, 2009 at 9:24 AM, Lennart Regebro<regebro at gmail.com> wrote:
>>> 2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
>>>> Yes it's needed. Even if some people switch to Distribute in their
>>>> projects, as soon as you install
>>>> a project that is still on Setuptools, it will overwrite Distribute
>>>> files with no warning.
>>>
>>> But wait... if you install distribute, and you then install a project
>>> that depends on setuptools, you say it will be installed.
>>
>> no, it will be faked. meaning that just the PKG-INFO will be presented,
>> thus detected by pkg_resources. But at the end the setuptools *package*,
>> the pkg_resources.py and site.py files will be the one installed by <distribute>.
>
> I'm confused. You said that if a project is still on setuptools it
> will overwrite distribute. Now you said it wouldn't.
>

No I didn't say that. Let me re-explain (also this is explained in
DIstrbute readme) :

A - An installed distribution of "Distribute" 0.6 is composed of :
 - the setuptools package
 - the pkg_resource module
 - the site module
 - the easy_install script
 - a PKG-INFO file specific to the project

B - An installed distribution of "Setuptools" 0.6c9 is composed of :
 - the setuptools package
 - the pkg_resource module
 - the site module
 - the easy_install script
 - a PKG-INFO file specific to the project

If you install A, then B, you are not using Distribute code, but
Setuptools, right ?
Because B is installed in the same place than A, or is reached before
A in the path.

So how does a script like pip or easy_install knows if Setuptools is installed ?

-> by looking for the PKG-INFO of the project named "Setuptools" if it
finds it, it "knows" it's installed.
and tell you "setuptools 0.6c9 is installed"

Ok so, "faking" setuptools means, setting up a PKG-INFO so
easy_install, pip, zc.buildout, etc
thinks Setuptools 0.6c9 is installed. *but not letting the setuptools
package, the pkg_resources module, etc of
the Setuptools project in the path.

If we don't fake setuptools, and just install Distribute if someone
installs setuptools again, which
is highly possible because with easy_install and pip, fields like
install_requires will install it and therefore
overwrite Distribute

If we do fake it, and if you install a project that requires
Setuptools, this requirement will be met and this package will use
Distribute code.

Of course people (as explained in the README.txt) have ways to get
back to setuptools.

at the end, this process means: "don't let a third party package chose
for you to use *globally* setuptools,
make it use Distribute without having to change this third party
package, because their APIS are perfect clones "


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

From chris at simplistix.co.uk  Thu Aug  6 16:13:01 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 15:13:01 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names +	release/branches roadmap
In-Reply-To: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
Message-ID: <4A7AE4ED.9090103@simplistix.co.uk>

Tarek Ziad? wrote:
> If you use zc.buildout, you can try it by replacing the bootstrap.py
> file that comes with your buildout with the one I work on, then
> 
> a/ add "distribute" to the required eggs in your buildout cfg file

Why is this needed? No one has needed to specify setuptools as a 
dependency previously, so why should they have to specify distribute now?

> b/ run or re-run the bootstrap:
> 
> $ wget http://nightly.ziade.org/bootstrap.py
> $ python bootstrap.py

So, this is a drop-in replacement for the bootstrap.py provided by buildout?

> the distribute egg. Last, the setuptools egg is faked and you wil
> notice that it's empty. This has to be done so zc.buildout and any
> software
> out there that has a hardcoded dependency on setuptools thinks it's present.

I think this is a bad idea. It can't be that hard to patch buildout to 
use distribute instead of setuptools. Running s/setuptools/distribute 
should do it...

> 2/ bootstraping file names
> 
> To avoid any confusion, I've changed distribute's bootstrap file name.
> So we will have:
> 
> - ez_setup.py = setuptools bootstrap file
> - bootstraping.py = distribute bootstrap file
> - bootstrap.py = zc.buildout bootstrap file

Now you've lost me... What is bootstrap[p]ing.py versus the bootstrap.py 
that comes with distribute?

Chris

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

From chris at simplistix.co.uk  Thu Aug  6 16:14:19 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 15:14:19 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping
 file	names + release/branches roadmap
In-Reply-To: <1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	<1099b90b0908041401xa819a1t89cebf677f39fc@mail.gmail.com>	<94bdd2610908041411r79139f3fkae6f2b2d54b7e47a@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
Message-ID: <4A7AE53B.7090706@simplistix.co.uk>

Jim Fulton wrote:
> If distribute is truly a setuptools clone, I suppose that the project
> name to use could be configurable in buildout.  This would take some
> work, but probably not that much.  That seems cleaner and less brittle
> than hacking installed setuptools distributions.

This seems like more work than it needs to be.

Jim, what would it take to convince you to just switch buildout to using 
distribute over setuptools in the next buildout release?

cheers,

Chris

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

From ziade.tarek at gmail.com  Thu Aug  6 16:22:05 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 16:22:05 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <4A7AE4ED.9090103@simplistix.co.uk>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<4A7AE4ED.9090103@simplistix.co.uk>
Message-ID: <94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>

On Thu, Aug 6, 2009 at 4:13 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> If you use zc.buildout, you can try it by replacing the bootstrap.py
>> file that comes with your buildout with the one I work on, then
>>
>> a/ add "distribute" to the required eggs in your buildout cfg file
>
> Why is this needed? No one has needed to specify setuptools as a dependency
> previously, so why should they have to specify distribute now?

for the scripts created in zc.recipe.egg sections, so distribute is
included in the sys.path
since this recipe re-creates it.

>
>> b/ run or re-run the bootstrap:
>>
>> $ wget http://nightly.ziade.org/bootstrap.py
>> $ python bootstrap.py
>
> So, this is a drop-in replacement for the bootstrap.py provided by buildout?
>

yes

>> the distribute egg. Last, the setuptools egg is faked and you wil
>> notice that it's empty. This has to be done so zc.buildout and any
>> software
>> out there that has a hardcoded dependency on setuptools thinks it's
>> present.
>
> I think this is a bad idea. It can't be that hard to patch buildout to use
> distribute instead of setuptools. Running s/setuptools/distribute should do
> it...

but as I explained earlier, even if buildout uses distribute, you
can't prevent an egg
out there to have an install_requires with setuptools, leading to the
mentionned problem
(the install battle)

>
>> 2/ bootstraping file names
>>
>> To avoid any confusion, I've changed distribute's bootstrap file name.
>> So we will have:
>>
>> - ez_setup.py = setuptools bootstrap file
>> - bootstraping.py = distribute bootstrap file
>> - bootstrap.py = zc.buildout bootstrap file
>
> Now you've lost me... What is bootstrap[p]ing.py versus the bootstrap.py
> that comes with distribute?

bootstraping.py replaces ez_setup.py

it's to Distribute what ez_setup.py is to setuptools

bootstrap.py is the replacement for buildout's bootstrap.py script

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



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

From chris at simplistix.co.uk  Thu Aug  6 16:29:30 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 15:29:30 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	
	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
Message-ID: <4A7AE8CA.8060403@simplistix.co.uk>

Tarek Ziad? wrote:
>>> a/ add "distribute" to the required eggs in your buildout cfg file
>> Why is this needed? No one has needed to specify setuptools as a dependency
>> previously, so why should they have to specify distribute now?
> 
> for the scripts created in zc.recipe.egg sections, so distribute is
> included in the sys.path
> since this recipe re-creates it.

Am I right in thinking this wouldn't be needed if zc.buildout and 
zc.recipe.egg both depended on distribute rather than setuptools?

>>> the distribute egg. Last, the setuptools egg is faked and you wil
>>> notice that it's empty. This has to be done so zc.buildout and any
>>> software
>>> out there that has a hardcoded dependency on setuptools thinks it's
>>> present.
>> I think this is a bad idea. It can't be that hard to patch buildout to use
>> distribute instead of setuptools. Running s/setuptools/distribute should do
>> it...
> 
> but as I explained earlier, even if buildout uses distribute, you
> can't prevent an egg
> out there to have an install_requires with setuptools, leading to the
> mentionned problem
> (the install battle)

Would it be possible for distribute to raise an error if a package 
relied on setuptools? I don't see why a third party egg would have 
install_requires contain setuptools if it's already running from 
buildout, but it feels better to me to be explicit and raise an error 
than lie by creating a fake egg. I know fake eggs are popular in the 
plohn community, but I'd prefer not to drag that abomination in the 
wider python world.

To recap: I think it makes sense for distribute to complain if something 
explicitly asks for setuptools since, by definition, both the distribute 
and setuptools distributions can't be made available at the same time.

>>> 2/ bootstraping file names
>>>
>>> To avoid any confusion, I've changed distribute's bootstrap file name.
>>> So we will have:
>>>
>>> - ez_setup.py = setuptools bootstrap file
>>> - bootstraping.py = distribute bootstrap file
>>> - bootstrap.py = zc.buildout bootstrap file
>> Now you've lost me... What is bootstrap[p]ing.py versus the bootstrap.py
>> that comes with distribute?
> 
> bootstraping.py replaces ez_setup.py

Oh Tarek, you really do know how to pick names...

Any chance you could switch this to distribute_setup.py or maybe 
d_setup.py to avoid dumb people like me constantly confusing the two?

Chris

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

From ziade.tarek at gmail.com  Thu Aug  6 16:43:30 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 16:43:30 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <4A7AE8CA.8060403@simplistix.co.uk>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
	<4A7AE8CA.8060403@simplistix.co.uk>
Message-ID: <94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>

On Thu, Aug 6, 2009 at 4:29 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>> for the scripts created in zc.recipe.egg sections, so distribute is
>> included in the sys.path
>> since this recipe re-creates it.
>
> Am I right in thinking this wouldn't be needed if zc.buildout and
> zc.recipe.egg both depended on distribute rather than setuptools?

Yes, but I think this takes more energy and more time to convince Jim, then
work in zc.buildout, etc.. than a single line in a cfg file, which I
find acceptable
from a project PoV like plone for example.

With the custom bootstrap, and a slight change in the cfg file, buildout
users can switch if they whish, and get to use *instantly* the 0.6 release,
while we work at a completely changed 0.7 one.

People in the community will also be able to fix remaning bugs we can
release in the 0.6.x branch while we work hard in 0.7.x for py3k support, etc..

> Would it be possible for distribute to raise an error if a package relied on
> setuptools? I don't see why a third party egg would have install_requires
> contain setuptools if it's already running from buildout, but it feels
> better to me to be explicit and raise an error than lie by creating a fake
> egg. I know fake eggs are popular in the plohn community, but I'd prefer not
> to drag that abomination in the wider python world.

Unfortunately, we have hunderds of packages out there with
"setuptools" in the install_requires.

If we take the plone example, every single egg has it (because it's in
the zopeskel skeleton)

which means plone applications won't work unless *every egg of the
community* is changed.

I'd rather be able to run already released eggs in my buildout today
rather than waiting for
the crowd to adopt it.

Plus, people wont adopt it if they can't taste it,

>


>> bootstraping.py replaces ez_setup.py
>
> Oh Tarek, you really do know how to pick names...
>
> Any chance you could switch this to distribute_setup.py or maybe d_setup.py
> to avoid dumb people like me constantly confusing the two?

Sure. distribute_setup.py sounds good, I can change.  That will be the
name, no further
change :)



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

From chris at simplistix.co.uk  Thu Aug  6 16:57:04 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 15:57:04 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	
	<4A7AE4ED.9090103@simplistix.co.uk>	
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>	
	<4A7AE8CA.8060403@simplistix.co.uk>
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>
Message-ID: <4A7AEF40.4010503@simplistix.co.uk>

Tarek Ziad? wrote:
> On Thu, Aug 6, 2009 at 4:29 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>>> for the scripts created in zc.recipe.egg sections, so distribute is
>>> included in the sys.path
>>> since this recipe re-creates it.
>> Am I right in thinking this wouldn't be needed if zc.buildout and
>> zc.recipe.egg both depended on distribute rather than setuptools?
> 
> Yes, but I think this takes more energy and more time to convince Jim, then
> work in zc.buildout

It really doesn't look like a lot of work, in fact I knocked up a branch 
that shows just that:

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

The changeset required was actually pretty small:

http://zope3.pov.lt/trac/changeset/102544

When a distribute egg gets released, I'll try running these tests and 
see what happens...

> If we take the plone example, every single egg has it (because it's in
> the zopeskel skeleton)

*sigh* Plone suck strikes again :-(

> I'd rather be able to run already released eggs in my buildout today
> rather than waiting for
> the crowd to adopt it.
> 
> Plus, people wont adopt it if they can't taste it,

I guess that's the way it needs to be, and all for the stubbornness of 
Phil Eby...

>>> bootstraping.py replaces ez_setup.py
>> Oh Tarek, you really do know how to pick names...
>>
>> Any chance you could switch this to distribute_setup.py or maybe d_setup.py
>> to avoid dumb people like me constantly confusing the two?
> 
> Sure. distribute_setup.py sounds good, I can change.  That will be the
> name, no further
> change :)

Thanks.

Chris

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

From ziade.tarek at gmail.com  Thu Aug  6 17:06:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 17:06:59 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <4A7AEF40.4010503@simplistix.co.uk>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
	<4A7AE8CA.8060403@simplistix.co.uk>
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>
	<4A7AEF40.4010503@simplistix.co.uk>
Message-ID: <94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>

On Thu, Aug 6, 2009 at 4:57 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> On Thu, Aug 6, 2009 at 4:29 PM, Chris Withers<chris at simplistix.co.uk>
>> wrote:
>>>>
>>>> for the scripts created in zc.recipe.egg sections, so distribute is
>>>> included in the sys.path
>>>> since this recipe re-creates it.
>>>
>>> Am I right in thinking this wouldn't be needed if zc.buildout and
>>> zc.recipe.egg both depended on distribute rather than setuptools?
>>
>> Yes, but I think this takes more energy and more time to convince Jim,
>> then
>> work in zc.buildout
>
> It really doesn't look like a lot of work, in fact I knocked up a branch
> that shows just that:
>
> http://svn.zope.org/zc.buildout/branches/use_distribute/
>
> The changeset required was actually pretty small:
>
> http://zope3.pov.lt/trac/changeset/102544

You also need to patch zc.buildout.Buildout class, that has some harcoded calls
to setuptools installation (like in the bootstrap method)

look at my patched bootstrap.py file

>
> When a distribute egg gets released, I'll try running these tests and see
> what happens...

You should be able to use nightly.ziade.org/ as an egg source in the
test fixture

In any case, like Jim proposed, being able to pick setuptools *or* distribute
eg removing the hardcoded installation sounds like a good idea

From tseaver at palladion.com  Thu Aug  6 17:19:16 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 06 Aug 2009 11:19:16 -0400
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
Message-ID: <4A7AF474.7030008@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:

>>> the distribute egg. Last, the setuptools egg is faked and you wil
>>> notice that it's empty. This has to be done so zc.buildout and any
>>> software
>>> out there that has a hardcoded dependency on setuptools thinks it's
>>> present.
>> I think this is a bad idea. It can't be that hard to patch buildout to use
>> distribute instead of setuptools. Running s/setuptools/distribute should do
>> it...
> 
> but as I explained earlier, even if buildout uses distribute, you
> can't prevent an egg
> out there to have an install_requires with setuptools, leading to the
> mentionned problem
> (the install battle)

Why would an egg depending on setuptools cause setuptools to be
installed:  distribute's "PKG-INFO" will convince the system that
setuptools is already present?  Or are you defending the use of the
"faked" PKG-INFO (which seems like an absolute requirement to me)?



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

iD8DBQFKevR0+gerLs4ltQ4RAtqjAKC9gxXUkymnGI/apLHKHI4S8BbBVQCfdnar
nYV9px/IExgIZbjcex60GuU=
=ckuR
-----END PGP SIGNATURE-----


From chris at simplistix.co.uk  Thu Aug  6 17:25:14 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 16:25:14 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	
	<4A7AE4ED.9090103@simplistix.co.uk>	
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>	
	<4A7AE8CA.8060403@simplistix.co.uk>	
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>	
	<4A7AEF40.4010503@simplistix.co.uk>
	<94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>
Message-ID: <4A7AF5DA.3020601@simplistix.co.uk>

Tarek Ziad? wrote:
>> http://zope3.pov.lt/trac/changeset/102544
> 
> You also need to patch zc.buildout.Buildout class, that has some harcoded calls
> to setuptools installation (like in the bootstrap method)

I've jsut made a bunch of changes to easy_install.py, buildout.py and 
egg.pyin r102547, can you see anything I missed?

>> When a distribute egg gets released, I'll try running these tests and see
>> what happens...
> 
> You should be able to use nightly.ziade.org/ as an egg source in the
> test fixture

How do I do that?

> In any case, like Jim proposed, being able to pick setuptools *or* distribute
> eg removing the hardcoded installation sounds like a good idea

...but it's a lot more work.

Chris

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

From ziade.tarek at gmail.com  Thu Aug  6 17:26:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 17:26:01 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <4A7AF474.7030008@palladion.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
	<4A7AF474.7030008@palladion.com>
Message-ID: <94bdd2610908060826h57d6cda1h7aafe9aad256eace@mail.gmail.com>

On Thu, Aug 6, 2009 at 5:19 PM, Tres Seaver<tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>
>>>> the distribute egg. Last, the setuptools egg is faked and you wil
>>>> notice that it's empty. This has to be done so zc.buildout and any
>>>> software
>>>> out there that has a hardcoded dependency on setuptools thinks it's
>>>> present.
>>> I think this is a bad idea. It can't be that hard to patch buildout to use
>>> distribute instead of setuptools. Running s/setuptools/distribute should do
>>> it...
>>
>> but as I explained earlier, even if buildout uses distribute, you
>> can't prevent an egg
>> out there to have an install_requires with setuptools, leading to the
>> mentionned problem
>> (the install battle)
>
> Why would an egg depending on setuptools cause setuptools to be
> installed: ?distribute's "PKG-INFO" will convince the system that
> setuptools is already present?

distribute's "PKG-INFO" doesn't mention setuptools, since its fields are:

...
name: Distribute
version: 0.6
...

So when pip or easy_install are asked to install "setuptools" they
will both look for a PKG-INFO
containing:

...
name: setuptools
...


> Or are you defending the use of the
> "faked" PKG-INFO (which seems like an absolute requirement to me)?

Yes I am defending the faked PKG-INFO which contains "setuptools" in
the name field,
and 0.6c9 in the version one. For practical reasons its' not a
PKG-INFO I am installing
when Distribute is installed. But in a bootstrap process.

So distribute setup.py file looks like ths:

before_install()
setup(...)
after_install()

and the same code is used by the boostrapping module that replaces ez_setup.py
(which is going to be named in something else after chris feedback)



>
>
>
> 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
>
> iD8DBQFKevR0+gerLs4ltQ4RAtqjAKC9gxXUkymnGI/apLHKHI4S8BbBVQCfdnar
> nYV9px/IExgIZbjcex60GuU=
> =ckuR
> -----END PGP SIGNATURE-----
>



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

From ziade.tarek at gmail.com  Thu Aug  6 17:28:54 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 17:28:54 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <4A7AF5DA.3020601@simplistix.co.uk>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
	<4A7AE8CA.8060403@simplistix.co.uk>
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>
	<4A7AEF40.4010503@simplistix.co.uk>
	<94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>
	<4A7AF5DA.3020601@simplistix.co.uk>
Message-ID: <94bdd2610908060828ob0065c7pcd5f740d1580a271@mail.gmail.com>

On Thu, Aug 6, 2009 at 5:25 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>>
>>> http://zope3.pov.lt/trac/changeset/102544
>>
>> You also need to patch zc.buildout.Buildout class, that has some harcoded
>> calls
>> to setuptools installation (like in the bootstrap method)
>
> I've jsut made a bunch of changes to easy_install.py, buildout.py and
> egg.pyin r102547, can you see anything I missed?

I'll take a look asap

>
>>> When a distribute egg gets released, I'll try running these tests and see
>>> what happens...
>>
>> You should be able to use nightly.ziade.org/ as an egg source in the
>> test fixture
>
> How do I do that?

I am not sure :) depends on how zc.buildout test fixture works

but nightly.ziade.org is a placeholder for eggs so it should be doable.


>> In any case, like Jim proposed, being able to pick setuptools *or*
>> distribute
>> eg removing the hardcoded installation sounds like a good idea
>
> ...but it's a lot more work.

I am pretty sure Jim will not want a simple s/setuptools/distribute/ switch
but if you can convince him, I am all +1

From chris at simplistix.co.uk  Thu Aug  6 17:31:20 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 16:31:20 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908060828ob0065c7pcd5f740d1580a271@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	
	<4A7AE4ED.9090103@simplistix.co.uk>	
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>	
	<4A7AE8CA.8060403@simplistix.co.uk>	
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>	
	<4A7AEF40.4010503@simplistix.co.uk>	
	<94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>	
	<4A7AF5DA.3020601@simplistix.co.uk>
	<94bdd2610908060828ob0065c7pcd5f740d1580a271@mail.gmail.com>
Message-ID: <4A7AF748.4050905@simplistix.co.uk>

Tarek Ziad? wrote:
> I am pretty sure Jim will not want a simple s/setuptools/distribute/ switch
> but if you can convince him, I am all +1

Why would he not?

"distribute" is simply a relabelling of "setuptools" because PJE is too 
stubborn to let anyone else move the project forward.

I see you can release buildout eggs, so if the community backs us, you 
could just release the buildout egg that did the trick ;-)

Chris

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

From ziade.tarek at gmail.com  Thu Aug  6 18:07:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 6 Aug 2009 18:07:59 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <4A7AF748.4050905@simplistix.co.uk>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<4A7AE4ED.9090103@simplistix.co.uk>
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>
	<4A7AE8CA.8060403@simplistix.co.uk>
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>
	<4A7AEF40.4010503@simplistix.co.uk>
	<94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>
	<4A7AF5DA.3020601@simplistix.co.uk>
	<94bdd2610908060828ob0065c7pcd5f740d1580a271@mail.gmail.com>
	<4A7AF748.4050905@simplistix.co.uk>
Message-ID: <94bdd2610908060907k4a4f6f3are7bad7ce585c49b@mail.gmail.com>

On Thu, Aug 6, 2009 at 5:31 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> I am pretty sure Jim will not want a simple s/setuptools/distribute/
>> switch
>> but if you can convince him, I am all +1
>
> Why would he not?

Because he said in that very same thread he'd rather see a change
where buildout can pick,
rather than a replacement.

From chris at simplistix.co.uk  Thu Aug  6 18:09:46 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 06 Aug 2009 17:09:46 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
 names + release/branches roadmap
In-Reply-To: <94bdd2610908060907k4a4f6f3are7bad7ce585c49b@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>	
	<4A7AE4ED.9090103@simplistix.co.uk>	
	<94bdd2610908060722h27a3cefcy64b9c19f6808837c@mail.gmail.com>	
	<4A7AE8CA.8060403@simplistix.co.uk>	
	<94bdd2610908060743u3b7a0235n815d17bd8c593378@mail.gmail.com>	
	<4A7AEF40.4010503@simplistix.co.uk>	
	<94bdd2610908060806k2e76a716l2f8474b49f22f6f9@mail.gmail.com>	
	<4A7AF5DA.3020601@simplistix.co.uk>	
	<94bdd2610908060828ob0065c7pcd5f740d1580a271@mail.gmail.com>	
	<4A7AF748.4050905@simplistix.co.uk>
	<94bdd2610908060907k4a4f6f3are7bad7ce585c49b@mail.gmail.com>
Message-ID: <4A7B004A.70706@simplistix.co.uk>

Tarek Ziad? wrote:
> On Thu, Aug 6, 2009 at 5:31 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>> Tarek Ziad? wrote:
>>> I am pretty sure Jim will not want a simple s/setuptools/distribute/
>>> switch
>>> but if you can convince him, I am all +1
>> Why would he not?
> 
> Because he said in that very same thread he'd rather see a change
> where buildout can pick,
> rather than a replacement.

It seems unfair to set an unnecessarily high bar to improvement like 
that. Hopefully he can be persuaded otherwise when he sees the branch...

Chris

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

From regebro at gmail.com  Thu Aug  6 22:21:55 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 6 Aug 2009 22:21:55 +0200
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908060110m6028def9udb135bd388cd2ef7@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<1099b90b0908041443g3db761a2j238368003b1df446@mail.gmail.com>
	<94bdd2610908041457g7434d78fq3f4fd8dd19ea1c6a@mail.gmail.com>
	<1099b90b0908050514v35994dc5ua5b2c3be1e40e840@mail.gmail.com>
	<319e029f0908052338v42307d5fk4eb96738386f3820@mail.gmail.com>
	<94bdd2610908060005k4a047f11qca067f99a8fb9d29@mail.gmail.com>
	<319e029f0908060024x2661d2dai24811f670c0e5a41@mail.gmail.com>
	<94bdd2610908060045q5173db42y1e7a4d6700ad6264@mail.gmail.com>
	<319e029f0908060053k433d07e3wc6ef42e3a3fa64cb@mail.gmail.com>
	<94bdd2610908060110m6028def9udb135bd388cd2ef7@mail.gmail.com>
Message-ID: <319e029f0908061321s37654a4dic42c3a43d074a406@mail.gmail.com>

2009/8/6 Tarek Ziad? <ziade.tarek at gmail.com>:
> So how does a script like pip or easy_install knows if Setuptools is installed ?

Ah, right, pip.

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

From jrh at joshh.co.uk  Fri Aug  7 19:21:34 2009
From: jrh at joshh.co.uk (Josh Holland)
Date: Fri, 7 Aug 2009 18:21:34 +0100
Subject: [Distutils] Bizarre behaviour with --prefix
Message-ID: <20090807172134.GD28893@joshh.co.uk>

I am encountering some interesting behaviour with python setup.py
install.
$ python setup.py -n install
running install
running build
running build_py
running build_ext
building 'suvatext' extension
creating build/temp.linux-i686-2.6
creating build/temp.linux-i686-2.6/suvatlib
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c
suvatlib/suvatext.c -o build/temp.linux-i686-2.6/suvatlib/suvatext.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-i686-2.6/suvatlib/suvatext.o -o
build/lib.linux-i686-2.6/suvatext.so
running build_scripts
changing mode of build/scripts-2.6/suvat
running install_lib
copying build/lib.linux-i686-2.6/suvatext.so ->
/usr/local/lib/python2.6/dist-packages
copying build/lib.linux-i686-2.6/suvatlib/__init__.py ->
/usr/local/lib/python2.6/dist-packages/suvatlib
copying build/lib.linux-i686-2.6/suvatlib/suvatwin.py ->
/usr/local/lib/python2.6/dist-packages/suvatlib
copying build/lib.linux-i686-2.6/suvatlib/suvatcalc.py ->
/usr/local/lib/python2.6/dist-packages/suvatlib
error: file
'/usr/local/lib/python2.6/dist-packages/suvatlib/__init__.py' does not
exist
$ python setup.py -n install --prefix=/usr
running install
running build
running build_py
running build_ext
building 'suvatext' extension
creating build/temp.linux-i686-2.6
creating build/temp.linux-i686-2.6/suvatlib
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c
suvatlib/suvatext.c -o build/temp.linux-i686-2.6/suvatlib/suvatext.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-i686-2.6/suvatlib/suvatext.o -o
build/lib.linux-i686-2.6/suvatext.so
running build_scripts
changing mode of build/scripts-2.6/suvat
running install_lib
copying build/lib.linux-i686-2.6/suvatext.so ->
/usr/lib/python2.6/site-packages
copying build/lib.linux-i686-2.6/suvatlib/__init__.py ->
/usr/lib/python2.6/site-packages/suvatlib
copying build/lib.linux-i686-2.6/suvatlib/suvatwin.py ->
/usr/lib/python2.6/site-packages/suvatlib
copying build/lib.linux-i686-2.6/suvatlib/suvatcalc.py ->
/usr/lib/python2.6/site-packages/suvatlib
error: file '/usr/lib/python2.6/site-packages/suvatlib/__init__.py' does
not exist

It seems that, without the --prefix option, the package suvatlib is
being installed into dist-packages, while with --prefix=/usr, the
package is going into site-packages.
This is with python 2.6.2 on Ubuntu Karmic.

-- 
Josh Holland <jrh at joshh.co.uk> (key F6067C12)
http://joshh.co.uk dutchie on irc.freenode.net
http://twitter.com/jshholland
http://identi.ca/jshholland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 927 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090807/6c20a420/attachment.py>

From floris.bruynooghe at gmail.com  Fri Aug  7 21:02:52 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Fri, 7 Aug 2009 20:02:52 +0100
Subject: [Distutils] Bizarre behaviour with --prefix
In-Reply-To: <20090807172134.GD28893@joshh.co.uk>
References: <20090807172134.GD28893@joshh.co.uk>
Message-ID: <20090807190252.GA21271@laurie.devork>

On Fri, Aug 07, 2009 at 06:21:34PM +0100, Josh Holland wrote:
> It seems that, without the --prefix option, the package suvatlib is
> being installed into dist-packages, while with --prefix=/usr, the
> package is going into site-packages.
> This is with python 2.6.2 on Ubuntu Karmic.

dist-packages is a Ubuntu/Debian extension.  The idea is that without
--prefix it installs in the sysadmin location.  And --prefix=/usr
should only be used when building a .dep package.

Regards
Floris

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

From hanno at hannosch.eu  Sat Aug  8 13:34:22 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 8 Aug 2009 12:34:22 +0100
Subject: [Distutils] Distribute and zc.buildout + bootstraping file
	names + release/branches roadmap
In-Reply-To: <94bdd2610908051346n40c8dba0mb9f9185a049f7258@mail.gmail.com>
References: <94bdd2610908041350k21d50e83t8126d2795d6dc6f8@mail.gmail.com>
	<h5bn6g$v9p$1@ger.gmane.org>
	<94bdd2610908051346n40c8dba0mb9f9185a049f7258@mail.gmail.com>
Message-ID: <5cae42b20908080434y45e03ef9t44bd3853e8c8b70b@mail.gmail.com>

On Wed, Aug 5, 2009 at 9:46 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> I'll wait for any other feedback and for Hanno feedback (they are
> sprinting in Bristol/UK)
> and I'll push a release Thirsday or Friday unless some bad feedback occurs.

I had some problems, which were all due to the fact that I had various
"unofficial" setuptools installations all over the place claiming to
be newer setuptools versions, like
http://dist.jarn.com/public/setuptools-0.6c9-1.zip. I just removed all
traces of setuptools from my various site-packages and buildout egg
caches and bootstrapped everything again. After that it worked fine.

I also changed a couple of references of ez_setup with pointers to
bootstrapping in the code. bootstrapping was suggesting to me to
upgrade to a newer version by running ez_setup, which would obviously
be a bad idea ;)

Hanno

From ziade.tarek at gmail.com  Sun Aug  9 01:57:05 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 9 Aug 2009 01:57:05 +0200
Subject: [Distutils] Distribute 0.6 released
Message-ID: <94bdd2610908081657k117cdb19vf6d2ff210a0dc22f@mail.gmail.com>

Hi all,

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

---

CHANGES (compared to setuptools 0.6c9) :

setuptools

    * Packages required at build time where not fully present at
install time. This closes
http://bitbucket.org/tarek/distribute/issue/12.
    * Protected against failures in tarfile extraction. This closes
http://bitbucket.org/tarek/distribute/issue/10.
    * Made Jython api_tests.txt doctest compatible. This closes
http://bitbucket.org/tarek/distribute/issue/7.
    * sandbox.py replaced builtin type file with builtin function
open. This closes http://bitbucket.org/tarek/distribute/issue/6.
    * Immediately close all file handles. This closes
http://bitbucket.org/tarek/distribute/issue/3.
    * Added compatibility with Subversion 1.6. This references
http://bitbucket.org/tarek/distribute/issue/1.

pkg_resources

    * Avoid a call to /usr/bin/sw_vers on OSX and use the official
platform API instead. Based on a patch from ronaldoussoren. This
closes http://bitbucket.org/tarek/distribute/issue/5.
    * Fixed a SandboxViolation for mkdir that could occur in certain
cases. This closes http://bitbucket.org/tarek/distribute/issue/13.
    * Allow to find_on_path on systems with tight permissions to fail
gracefully. This closes http://bitbucket.org/tarek/distribute/issue/9.
    * Corrected inconsistency between documentation and code of
add_entry. This closes http://bitbucket.org/tarek/distribute/issue/8.
    * Immediately close all file handles. This closes
http://bitbucket.org/tarek/distribute/issue/3.

easy_install

    * Immediately close all file handles. This closes
http://bitbucket.org/tarek/distribute/issue/3.


Cheers
Tarek

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

From ziade.tarek at gmail.com  Sun Aug  9 02:36:43 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 9 Aug 2009 02:36:43 +0200
Subject: [Distutils] Distribute 0.7 development + 0.6 maint.
Message-ID: <94bdd2610908081736w3acd79c2t66f0b1a648a7614@mail.gmail.com>

Hi,

I've created a branch for the 0.6 maintenance. and the default is now for 0.7.

0.6
----

The plan is to continue the bugfixes for the 0.6.x series there. If
you want to work on this branch,
you need to switch to it like this :

$ hg update -C 0.6-maintenance

(see http://mercurial.selenic.com/wiki/Branch)

Then you can work with this wiki page here:
http://bitbucket.org/tarek/distribute/wiki/bug_listing
Basically, all issues from the setuptools tracker can be mirrored and
fixed on our side, as long as
it's a real bug fix (no API/behavior change)

Patches are welcome !

0.7
----

The plan is to start the refactoring:

- py3k support
- split the code in several distributions
- think about new features / behaviors, we need

Help is welcome !

(of course we need to backport bugfixes from 0.6 to 0.7)

Cheers
Tarek



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

From sridharr at activestate.com  Mon Aug 10 21:26:47 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 10 Aug 2009 12:26:47 -0700
Subject: [Distutils] Distribute 0.7 development + 0.6 maint.
In-Reply-To: <94bdd2610908081736w3acd79c2t66f0b1a648a7614@mail.gmail.com>
References: <94bdd2610908081736w3acd79c2t66f0b1a648a7614@mail.gmail.com>
Message-ID: <op.uygoaxuh1q4jlt@whymac.activestate.com>

On Sat, 08 Aug 2009 17:36:43 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> 0.7
> ----
> The plan is to start the refactoring:
> - py3k support
> - split the code in several distributions
> - think about new features / behaviors, we need

And 0.7 will have different package namespace (thus not conflicting with  
an existing setuptools installation), correct?

A while ago, PJE reported what he had in his mind regarding the package  
split. With that in mind, something like distribute.download,  
distribute.sandbox, distribute.metadata, distribute.installer, etc.. would  
be nice. PyPM already uses setuptools.package_index for downloading  
packages .. and might move to distribute if it provides a clean and  
separate API for doing this.

-srid

From alsuren at gmail.com  Mon Aug 10 22:49:49 2009
From: alsuren at gmail.com (David Laban)
Date: Mon, 10 Aug 2009 21:49:49 +0100
Subject: [Distutils] Installing config files into specific directories,
	even with setuptools?
Message-ID: <4A8087ED.301@gmail.com>

Basically, I can install files into:

$HOME/.local/share/dbus-1/services
or
/usr/local/share/dbus-1/services
or
/usr/share/dbus-1/services
(or anywhere in xdg.BaseDirectory.xdg_data_dirs really)

but I want to pick the most appropriate place, taking into account the
--prefix option to setup.py, or the root of the virtualenv/whatever.

What is the most portable way to to this?



David.

From sridharr at activestate.com  Tue Aug 11 04:49:23 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 10 Aug 2009 19:49:23 -0700
Subject: [Distutils] Installing config files into specific directories,
 even with setuptools?
In-Reply-To: <4A8087ED.301@gmail.com>
References: <4A8087ED.301@gmail.com>
Message-ID: <op.uyg8slrx1q4jlt@whymac.activestate.com>

For applications needing user config files at a new location (not sure  
about /dbus-1/services), what I currently find suitable is this:

1. Store the default config files at myapp.module.conf namespace (==  
site-packages/myapp/module/conf/foo.conf,bar/baz.conf,etc..)

2. When the application is first run, check for ~/.local (or APPDATA on  
Windows) - and if user config directory-or-files is not present, copy them  
 from the namespace location to ~/.local.

3. Next time the app is run, the copied config files can be used; the user  
can also edit them.

-srid

On Mon, 10 Aug 2009 13:49:49 -0700, David Laban <alsuren at gmail.com> wrote:

> Basically, I can install files into:
>
> $HOME/.local/share/dbus-1/services
> or
> /usr/local/share/dbus-1/services
> or
> /usr/share/dbus-1/services
> (or anywhere in xdg.BaseDirectory.xdg_data_dirs really)
>
> but I want to pick the most appropriate place, taking into account the
> --prefix option to setup.py, or the root of the virtualenv/whatever.
>
> What is the most portable way to to this?
>
>
>
> David.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From chris at simplistix.co.uk  Tue Aug 11 12:06:59 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 11 Aug 2009 11:06:59 +0100
Subject: [Distutils] bootstrapping virtualenv?
Message-ID: <4A8142C3.2000708@simplistix.co.uk>

Hi All,

Am I right in thinking the correct way to get a virtualenv without 
installing virtualenv into your site-packages is:

- download a source distro of virtualenv

- unpack it and copy virtualenv.py somewhere

- use that virtualenv.py with whatever python you want to create your 
virtualenvs?

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Aug 11 12:08:01 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 11 Aug 2009 11:08:01 +0100
Subject: [Distutils] virtualenv with distribute
Message-ID: <4A814301.1050204@simplistix.co.uk>

Hi Tarek,

Any idea how I'd go about getting virtualenv to use distribute instead 
of setuptools?

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Aug 11 12:35:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 11 Aug 2009 12:35:00 +0200
Subject: [Distutils] virtualenv with distribute
In-Reply-To: <4A814301.1050204@simplistix.co.uk>
References: <4A814301.1050204@simplistix.co.uk>
Message-ID: <94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com>

On Tue, Aug 11, 2009 at 12:08 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Hi Tarek,
>
> Any idea how I'd go about getting virtualenv to use distribute instead of
> setuptools?
>

Hi,

I've added some explanation on the pypi page/readme for that :
http://pypi.python.org/pypi/distribute#install-faq

basically, once you've created your virtualenv, you have to
(re)install distribute in it


Cheers
Tarek

From chris at simplistix.co.uk  Tue Aug 11 12:36:48 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 11 Aug 2009 11:36:48 +0100
Subject: [Distutils] virtualenv with distribute
In-Reply-To: <94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com>
References: <4A814301.1050204@simplistix.co.uk>
	<94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com>
Message-ID: <4A8149C0.2010507@simplistix.co.uk>

Tarek Ziad? wrote:
> I've added some explanation on the pypi page/readme for that :
> http://pypi.python.org/pypi/distribute#install-faq
> 
> basically, once you've created your virtualenv, you have to
> (re)install distribute in it

Okay, that's clunky...

What do we need to make this not suck?
My guess is get Ian to do a release of virtualenv that switches from 
setuptools to distribute? Am I right?

cheers,

Chris

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

From ziade.tarek at gmail.com  Tue Aug 11 12:40:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 11 Aug 2009 12:40:08 +0200
Subject: [Distutils] virtualenv with distribute
In-Reply-To: <4A8149C0.2010507@simplistix.co.uk>
References: <4A814301.1050204@simplistix.co.uk>
	<94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com>
	<4A8149C0.2010507@simplistix.co.uk>
Message-ID: <94bdd2610908110340k2fbf2c38g57d83e5f28458773@mail.gmail.com>

On Tue, Aug 11, 2009 at 12:36 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> I've added some explanation on the pypi page/readme for that :
>> http://pypi.python.org/pypi/distribute#install-faq
>>
>> basically, once you've created your virtualenv, you have to
>> (re)install distribute in it
>
> Okay, that's clunky...
>

Why that ? if you want to use a software in a virtualenv, you have to
(re)install it in there...

From chris at simplistix.co.uk  Tue Aug 11 12:43:45 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 11 Aug 2009 11:43:45 +0100
Subject: [Distutils] virtualenv with distribute
In-Reply-To: <94bdd2610908110340k2fbf2c38g57d83e5f28458773@mail.gmail.com>
References: <4A814301.1050204@simplistix.co.uk>	
	<94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com>	
	<4A8149C0.2010507@simplistix.co.uk>
	<94bdd2610908110340k2fbf2c38g57d83e5f28458773@mail.gmail.com>
Message-ID: <4A814B61.2030905@simplistix.co.uk>

Tarek Ziad? wrote:
> 
> Why that ? if you want to use a software in a virtualenv, you have to
> (re)install it in there...

Yeah, but the process of setting up a virtualenv installs setuptools and 
makes it available to the virtualenv.

Rather than installing setuptools, I'd like it to install distribute and 
use that instead.

I don't want to install distribute over setuptools in the virtualenv and 
wondering if that worked like it should...

Chris

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

From ziade.tarek at gmail.com  Tue Aug 11 12:53:19 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 11 Aug 2009 12:53:19 +0200
Subject: [Distutils] virtualenv with distribute
In-Reply-To: <4A814B61.2030905@simplistix.co.uk>
References: <4A814301.1050204@simplistix.co.uk>
	<94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com>
	<4A8149C0.2010507@simplistix.co.uk>
	<94bdd2610908110340k2fbf2c38g57d83e5f28458773@mail.gmail.com>
	<4A814B61.2030905@simplistix.co.uk>
Message-ID: <94bdd2610908110353l16e2c190q352c92d81ebec67@mail.gmail.com>

On Tue, Aug 11, 2009 at 12:43 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> Why that ? if you want to use a software in a virtualenv, you have to
>> (re)install it in there...
>
> Yeah, but the process of setting up a virtualenv installs setuptools and
> makes it available to the virtualenv.
>
> Rather than installing setuptools, I'd like it to install distribute and use
> that instead.
>

Sure, maybe you could suggest that on the virtual env mailing list,
but maybe Ian will want to wait for Distribute 0.7
(that's what I'd do but I am not 100% sure of the best strategy for that)

> I don't want to install distribute over setuptools in the virtualenv and
> wondering if that worked like it should...
>

It should work. Before I did the release, I have successfully tested
installing in a venv, and provided a script for
people to try on their side: http://nightly.ziade.org/install_test.py

Beside, virtualenv or not, installing over setuptools and preventing
setuptools to install itself over distribute
is something I took care of by faking a setuptools installation when
distribute is installed.

Cheers
Tarek

From ronaldoussoren at mac.com  Tue Aug 11 15:31:11 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 11 Aug 2009 15:31:11 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort -
 plans	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
Message-ID: <E522697F-0E9D-4007-88AE-A00CBAB43CD8@mac.com>


On 23 Jul, 2009, at 16:29, Tarek Ziad? wrote:

> On Thu, Jul 23, 2009 at 4:17 PM, Lennart Regebro<regebro at gmail.com>  
> wrote:
>> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>>> - Let's then backport the 0.8 version into a 0.7 version, compatbile
>>> with Python 2.x and with the required bootstraping
>>>  so it works in 2.x environments
>>
>> There is no reason to have different version numbers for that. In
>> fact, I think that would only be confusing. The Python 3 version
>> should work for Python 2 as well.
>
> I think you don't see my point : making a pure Python 3 version,  
> without
> any backward compatibility issues / bootstraping , fight against  
> setuptools
> distribution. Then backporting it in 0.7
>
> But 0.8 would not be 2.x compatible.

At PyCon09 there was some talk about a "3to2" tool, specially for  
issue: allow package maintainers to work in Python 3 and automaticly  
generate a Python 2 version.  I have no idea if anyone is actually  
working on such a tool though.

Ronald

P.S. Sorry about the late answers, I've been travelling and was  
offline for a while.

-------------- 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/20090811/1a519654/attachment-0001.bin>

From ianb at colorstudy.com  Tue Aug 11 19:40:39 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 11 Aug 2009 12:40:39 -0500
Subject: [Distutils] bootstrapping virtualenv?
In-Reply-To: <4A8142C3.2000708@simplistix.co.uk>
References: <4A8142C3.2000708@simplistix.co.uk>
Message-ID: <b654cd2e0908111040k1972d0dbh6a11ac9281c23101@mail.gmail.com>

On Tue, Aug 11, 2009 at 5:06 AM, Chris Withers <chris at simplistix.co.uk>wrote:

> Am I right in thinking the correct way to get a virtualenv without
> installing virtualenv into your site-packages is:
>
> - download a source distro of virtualenv
>
> - unpack it and copy virtualenv.py somewhere
>
> - use that virtualenv.py with whatever python you want to create your
> virtualenvs?
>

You don't actually have to install virtualenv, just grab virtualenv.py
(e.g., directly from svn) and run it.  (Ditto pip)


-- 
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/20090811/9d16f3ae/attachment.htm>

From jim at zope.com  Tue Aug 11 20:27:08 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 11 Aug 2009 14:27:08 -0400
Subject: [Distutils] bootstrapping virtualenv?
In-Reply-To: <b654cd2e0908111040k1972d0dbh6a11ac9281c23101@mail.gmail.com>
References: <4A8142C3.2000708@simplistix.co.uk>
	<b654cd2e0908111040k1972d0dbh6a11ac9281c23101@mail.gmail.com>
Message-ID: <1099b90b0908111127u2c7f08b9rd685124cea91107a@mail.gmail.com>

On Tue, Aug 11, 2009 at 1:40 PM, Ian Bicking<ianb at colorstudy.com> wrote:
> On Tue, Aug 11, 2009 at 5:06 AM, Chris Withers <chris at simplistix.co.uk>
> wrote:
>>
>> Am I right in thinking the correct way to get a virtualenv without
>> installing virtualenv into your site-packages is:
>>
>> - download a source distro of virtualenv
>>
>> - unpack it and copy virtualenv.py somewhere
>>
>> - use that virtualenv.py with whatever python you want to create your
>> virtualenvs?
>
> You don't actually have to install virtualenv, just grab virtualenv.py
> (e.g., directly from svn) and run it. ?(Ditto pip)

Ah. That's cool.

Jim

-- 
Jim Fulton

From ianb at colorstudy.com  Tue Aug 11 22:58:43 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 11 Aug 2009 15:58:43 -0500
Subject: [Distutils]  virtualenv with distribute
In-Reply-To: <b654cd2e0908111045i1223556fiba3965ca8296e301@mail.gmail.com>
References: <4A814301.1050204@simplistix.co.uk>
	<94bdd2610908110335w57b4f519q58c546b15249658b@mail.gmail.com> 
	<4A8149C0.2010507@simplistix.co.uk>
	<94bdd2610908110340k2fbf2c38g57d83e5f28458773@mail.gmail.com> 
	<4A814B61.2030905@simplistix.co.uk>
	<94bdd2610908110353l16e2c190q352c92d81ebec67@mail.gmail.com> 
	<b654cd2e0908111045i1223556fiba3965ca8296e301@mail.gmail.com>
Message-ID: <b654cd2e0908111358m35c9ee9dkf2937074b98dc1ac@mail.gmail.com>

Philip Jenvey started a fork of virtualenv with Distribute support:
http://bitbucket.org/pjenvey/virtualenv-distribute/
Right now there's some other higher priority things for virtualenv (i.e.,
straight up bug fixes and long requested features), and I want to get pip
into environments (avoiding easy_install pip, which feels too ironic), and
once pip is in then it would be necessary that Distribute be compatible with
pip before this work could get merged.

It would be ideal from my perspective if virtualenv could install Distribute
in addition to Setuptools, not instead of Setuptools.  This would be the
least likely to cause backward compatibility issues for users, and people
could transition at their own pace.  I'm not really clear how compatible the
two are.  Also it would be advantageous to just have one line of
development, so the newest virtualenv always installs the newest Distribute,
and it's clear what that is (no different branches, no
backward-compatible-breaking releases, etc).

Of course, you will always be able to install Distribute into a virtualenv
after creating it -- virtualenv's relationship to Setuptools is purely to
bootstrap an environment to a useful state, and even if it installs pip you
can always uninstall pip (or just mess with the environment so as to break
pip, and then just not use pip).

-- 
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/20090811/87fc0e69/attachment.htm>

From ziade.tarek at gmail.com  Wed Aug 12 00:30:47 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 12 Aug 2009 00:30:47 +0200
Subject: [Distutils] Splitting distribute in several distributions
Message-ID: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>

Hey,

I've started to work on splitting Distribute into several distributions for 0.7

Here's the organization  I was thinking about:

- Distribution Name  = "Distribute"
- Content: setuptools package renamed to distribute (minus some
elements). root modules in setuptools will be moved to the
distribute.core package so the
  root namespace stays empty.

- Distribution Name  = "DistributeResources"
- Content: the part of pkg_resources.py that handles installed
distribution querying +  renamed to "distribute.resources"

- Distribution Name  = "DistributeEntryPoints"
- Content: the part of pkg_resources.py that handles entry points +
renamed to "distribute.entry_points"

- Distribution Name  = "DistributeInstaller"
- Content: the part of pkg_resources.py that handles version
comparison + package_index, that gets files at pypi + easy_install.py
+ easy_install command extracted from setuptools package +  renamed
into a "distribute.installer" package

I am not sure yet how the distribute namespace will be handled,
because (maybe ala PEP 382)

I am not sure either if "setuptools.sandbox" should get its own
distribution. I'd keep it in Distribute

Any thoughts ?

Cheers
Tarek

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

From ziade.tarek at gmail.com  Wed Aug 12 00:37:42 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 12 Aug 2009 00:37:42 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <4A77F7FC.8060700@egenix.com>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>
	<4A76A399.4040003@egenix.com>
	<EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>
	<4A77F49B.3000008@egenix.com>
	<94bdd2610908040152y329f1977ub3f2af872b056d94@mail.gmail.com>
	<4A77F7FC.8060700@egenix.com>
Message-ID: <94bdd2610908111537k21404bf2jec4bcb35c592a2ad@mail.gmail.com>

On Tue, Aug 4, 2009 at 10:57 AM, M.-A. Lemburg<mal at egenix.com> wrote:
> Tarek Ziad? wrote:
>> 2009/8/4 M.-A. Lemburg <mal at egenix.com>:
>>> Barry Warsaw wrote:
>>>> On Aug 3, 2009, at 4:45 AM, M.-A. Lemburg wrote:
>>>>
>>>>> It would be nice to have a user config *directory* for all Python
>>>>> config things, e.g. ~/.python/. Then it'd be natural to drop
>>>>> the ".py" prefix. Without the prefix, people would have a hard time
>>>>> connecting a .distutils.cfg in their home dir with Python.
>>>>
>>>> Python already uses ~/.local for stuff. ?It should go in there.
>>>
>>> You have a point there... we could put the user local config
>>> files into ~/.local/lib/python2.6/ and then name it distutils.cfg
>>> just like for the system-wide install.
>>
>> So in that case I suppose I have to lookup at PYTHONUSERBASE as well,
>> as done on site.py.
>>
>> I also propose if that's the case, to add a function in site.py that
>> returns USER_SITE and USER_BASE,
>> so it can be used by site.addusersitepackages *and* by distutils here
>
> +1
>
> While you're at it, please also add a function that returns the
> global site-packages dir(s).
>

it's done, I'll just wait for svn to come back and post a clean diff
at bugs.python.org for your reviews
guys before I commit it.

btw I don't like too much site.py's function names, they are not
readable with no "_" at all to separate words:

- addbuilddir
- removeduppaths
- addusersitepackages
- ...

I would love seeing new names there with underscore separated words
while we're at it, and deprecate those,

in any case, i've followed that file convention for now and I have
added three functions:

- getsitepackages
- getusersitepackages
- getuserbase

Cheers
Tarek


> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source ?(#1, Aug 04 2009)
>>>> Python/Zope Consulting and Support ... ? ? ? ?http://www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... ? ? ? ? ? ? http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... ? ? ? ?http://python.egenix.com/
> ________________________________________________________________________
>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
>
>
> ? eGenix.com Software, Skills and Services GmbH ?Pastor-Loeh-Str.48
> ? ?D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> ? ? ? ? ? Registered at Amtsgericht Duesseldorf: HRB 46611
> ? ? ? ? ? ? ? http://www.egenix.com/company/contact/
>



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

From SridharR at activestate.com  Wed Aug 12 02:33:26 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 11 Aug 2009 17:33:26 -0700
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
Message-ID: <op.uyiw50r1brrvlq@double>

I am glad that you have started thinking about the module split.

1) Why are the distributions named in CamelCase? Why not  
'distribute.resources' instead of 'DistributeResources' (like, for  
instance, zope.interface instead of ZopeInterface).

2) In your proposal below, version comparison is part of  
distribute.installer; this means distribute.resources (and other modules  
needing version comparison) will be depending on distribute.installer,  
correct? Is this intended, or should version comparison go to something  
like distribute.core?

3) PyPM's backend uses a) pkg_resources' version comparison, b)  
package_index's download logic (not API-friendly). I'd be interested to  
see distribute.installer provide this download logic (finding URLs,  
tarballs and fetching them) as an API. I believe pip and zc.buildout too  
relies on this download logic.

4) How about distribute.pypi that interfaces with pypi?

-srid

On Tue, 11 Aug 2009 15:30:47 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> Hey,
>
> I've started to work on splitting Distribute into several distributions  
> for 0.7
>
> Here's the organization  I was thinking about:
>
> - Distribution Name  = "Distribute"
> - Content: setuptools package renamed to distribute (minus some
> elements). root modules in setuptools will be moved to the
> distribute.core package so the
>   root namespace stays empty.
>
> - Distribution Name  = "DistributeResources"
> - Content: the part of pkg_resources.py that handles installed
> distribution querying +  renamed to "distribute.resources"
>
> - Distribution Name  = "DistributeEntryPoints"
> - Content: the part of pkg_resources.py that handles entry points +
> renamed to "distribute.entry_points"
>
> - Distribution Name  = "DistributeInstaller"
> - Content: the part of pkg_resources.py that handles version
> comparison + package_index, that gets files at pypi + easy_install.py
> + easy_install command extracted from setuptools package +  renamed
> into a "distribute.installer" package
>
> I am not sure yet how the distribute namespace will be handled,
> because (maybe ala PEP 382)
>
> I am not sure either if "setuptools.sandbox" should get its own
> distribution. I'd keep it in Distribute
>
> Any thoughts ?
>
> Cheers
> Tarek
>


From ziade.tarek at gmail.com  Wed Aug 12 02:44:01 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 12 Aug 2009 02:44:01 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <op.uyiw50r1brrvlq@double>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
Message-ID: <94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>

2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
> I am glad that you have started thinking about the module split.
>
> 1) Why are the distributions named in CamelCase? Why not
> 'distribute.resources' instead of 'DistributeResources' (like, for instance,
> zope.interface instead of ZopeInterface).

Because the distribution name is not the packages names.
See for instance the Paste project : PasteScript, Paste, PasteDeploy.

>
> 2) In your proposal below, version comparison is part of
> distribute.installer; this means distribute.resources (and other modules
> needing version comparison) will be depending on distribute.installer,
> correct? Is this intended, or should version comparison go to something like
> distribute.core?

When would distribute.resources need version comparisons if its sole
role is to provide query APIs
for installed packages ? (pre-PEP 376, then PEP 376-compliant)

>
> 3) PyPM's backend uses a) pkg_resources' version comparison, b)
> package_index's download logic (not API-friendly). I'd be interested to see
> distribute.installer provide this download logic (finding URLs, tarballs and
> fetching them) as an API. I believe pip and zc.buildout too relies on this
> download logic.

pakage_index would be included in distribute.installer, and we could probably
add simpler APIs to use it to drive a download

>
> 4) How about distribute.pypi that interfaces with pypi?
>

So, like a subpart of package_index ? this is a nice idea, so tools
like yolk or z3c.pypimirror could browse pypi index with it,

It could also have a full xmlrpc client implementation for PyPI xml-rpc APIs,

> -srid
>
> On Tue, 11 Aug 2009 15:30:47 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>> Hey,
>>
>> I've started to work on splitting Distribute into several distributions
>> for 0.7
>>
>> Here's the organization ?I was thinking about:
>>
>> - Distribution Name ?= "Distribute"
>> - Content: setuptools package renamed to distribute (minus some
>> elements). root modules in setuptools will be moved to the
>> distribute.core package so the
>> ?root namespace stays empty.
>>
>> - Distribution Name ?= "DistributeResources"
>> - Content: the part of pkg_resources.py that handles installed
>> distribution querying + ?renamed to "distribute.resources"
>>
>> - Distribution Name ?= "DistributeEntryPoints"
>> - Content: the part of pkg_resources.py that handles entry points +
>> renamed to "distribute.entry_points"
>>
>> - Distribution Name ?= "DistributeInstaller"
>> - Content: the part of pkg_resources.py that handles version
>> comparison + package_index, that gets files at pypi + easy_install.py
>> + easy_install command extracted from setuptools package + ?renamed
>> into a "distribute.installer" package
>>
>> I am not sure yet how the distribute namespace will be handled,
>> because (maybe ala PEP 382)
>>
>> I am not sure either if "setuptools.sandbox" should get its own
>> distribution. I'd keep it in Distribute
>>
>> Any thoughts ?
>>
>> Cheers
>> Tarek
>>
>
>



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

From SridharR at activestate.com  Wed Aug 12 03:00:36 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 11 Aug 2009 18:00:36 -0700
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
Message-ID: <op.uyiye7xibrrvlq@double>

On Tue, 11 Aug 2009 17:44:01 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:

> 2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
>> I am glad that you have started thinking about the module split.
>>
>> 1) Why are the distributions named in CamelCase? Why not
>> 'distribute.resources' instead of 'DistributeResources' (like, for  
>> instance,
>> zope.interface instead of ZopeInterface).
> Because the distribution name is not the packages names.
> See for instance the Paste project : PasteScript, Paste, PasteDeploy.

Ok. So there are apparently two conventions for naming distributions.
However, zope.*, zc.*, z3c.* fall under more wide-namespaces (zope is a
large namespace with many sub-packages).


>> 2) In your proposal below, version comparison is part of
>> distribute.installer; this means distribute.resources (and other modules
>> needing version comparison) will be depending on distribute.installer,
>> correct? Is this intended, or should version comparison go to something  
>> like
>> distribute.core?
> When would distribute.resources need version comparisons if its sole
> role is to provide query APIs
> for installed packages ? (pre-PEP 376, then PEP 376-compliant)

When multiple versions of a same package are installed, then perhaps
distribute.resources might have to return them in sorted order .. but,
well, I am not aware about the querying API yet .. so cannot say for sure.

Further, if you implement distribute.pypi .. then that too would require
version comparison, would it not? In that case, distribute.pypi would
depend upon distribute.installer .. and vice versa, I suppose, leading to
circular dependencies.  Eg:
distribute.pypi.Distribution.find('PasteScript').get_releases() may have
to return the releases in sorted order (by version number).

There must be a reason why PJE kept parts of setuptools in
pkg_resources.py. What is it? We may have to consider it before splitting
pkg_resources.py itself.


>> 3) PyPM's backend uses a) pkg_resources' version comparison, b)
>> package_index's download logic (not API-friendly). I'd be interested to  
>> see
>> distribute.installer provide this download logic (finding URLs,  
>> tarballs and
>> fetching them) as an API. I believe pip and zc.buildout too relies on  
>> this
>> download logic.
> pakage_index would be included in distribute.installer, and we could  
> probably
> add simpler APIs to use it to drive a download

Note that package_index is not API-friendly. A few violations I can
think of: 1) it prints warning messages to stderr without programmer
control, 2) throws random network exceptions that should be handled in a  
custom exception (see the issues I reported in distribute tracker) 3) no  
ability to control URL types (eg: I want to fetch only tarballs/zipfiles,  
not svn/hg/etc..) and so on.

This is roughly the code I currently use in PyPM (that uses setuptools):

(...)
class PackageIndex2(PackageIndex):
     def _download_svn(self, url, filename):
         raise SVNDisabled, 'svn not allowed at the moment'
(...)
def download_latest_sdist(req, directory):
     (...)
     # TODO: we need timeout on network operations (not just socket  
timeouts)
     try:
         sdist = pi.fetch_distribution(req, directory, source=True)
     except (DistutilsError, httplib.BadStatusLine, socket.timeout), e:
         # catch BadStatusLine:  
http://bitbucket.org/tarek/distribute/issue/18/
         raise PackageError, e
     if sdist == None:
         raise SdistMissing, 'cannot find a sdist for %s' % req
     if not exists(sdist.location):
         raise SdistLocationMissing, 'downloaded sdist <%s> missing' %  
sdist.location
     return sdist

-srid

From regebro at gmail.com  Wed Aug 12 07:48:05 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 12 Aug 2009 07:48:05 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <op.uyiw50r1brrvlq@double>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
Message-ID: <319e029f0908112248p337b7f3ep1889f4c8d6525cc2@mail.gmail.com>

2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
> I am glad that you have started thinking about the module split.
>
> 1) Why are the distributions named in CamelCase? Why not
> 'distribute.resources' instead of 'DistributeResources' (like, for instance,
> zope.interface instead of ZopeInterface).

+1 for that.

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

From alex.gronholm at nextday.fi  Wed Aug 12 07:51:52 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 12 Aug 2009 08:51:52 +0300
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <319e029f0908112248p337b7f3ep1889f4c8d6525cc2@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>
	<319e029f0908112248p337b7f3ep1889f4c8d6525cc2@mail.gmail.com>
Message-ID: <4A825878.6060707@nextday.fi>

Lennart Regebro kirjoitti:
> 2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
>   
>> I am glad that you have started thinking about the module split.
>>
>> 1) Why are the distributions named in CamelCase? Why not
>> 'distribute.resources' instead of 'DistributeResources' (like, for instance,
>> zope.interface instead of ZopeInterface).
>>     
>
> +1 for that.
>
>   
Looking at PyPI, there seems to be no clear standard on this, though I 
would say 60% of distribution names are in lower case. Is there a PEP 
that makes any recommendations either way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090812/dab42a79/attachment.htm>
-------------- 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/20090812/dab42a79/attachment.vcf>

From ziade.tarek at gmail.com  Wed Aug 12 10:35:17 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 12 Aug 2009 10:35:17 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <op.uyiye7xibrrvlq@double>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
Message-ID: <94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>

On Wed, Aug 12, 2009 at 3:00 AM, Sridhar
Ratnakumar<SridharR at activestate.com> wrote:
> On Tue, 11 Aug 2009 17:44:01 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>> 2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
>>>
>>> I am glad that you have started thinking about the module split.
>>>
>>> 1) Why are the distributions named in CamelCase? Why not
>>> 'distribute.resources' instead of 'DistributeResources' (like, for
>>> instance,
>>> zope.interface instead of ZopeInterface).
>>
>> Because the distribution name is not the packages names.
>> See for instance the Paste project : PasteScript, Paste, PasteDeploy.
>
> Ok. So there are apparently two conventions for naming distributions.
> However, zope.*, zc.*, z3c.* fall under more wide-namespaces (zope is a
> large namespace with many sub-packages).

Well, when Zope and Plone got splitted in multiple distributions, the convention
was : distribution name == package name because every distribution has
one single package.

The Zope community eventually followed, for the worse and the better (sometimes
it's better to distribute several packages in one distribution, or to
have modules
rathers than packages)


>
>
>>> 2) In your proposal below, version comparison is part of
>>> distribute.installer; this means distribute.resources (and other modules
>>> needing version comparison) will be depending on distribute.installer,
>>> correct? Is this intended, or should version comparison go to something
>>> like
>>> distribute.core?
>>
>> When would distribute.resources need version comparisons if its sole
>> role is to provide query APIs
>> for installed packages ? (pre-PEP 376, then PEP 376-compliant)
>
> When multiple versions of a same package are installed, then perhaps
> distribute.resources might have to return them in sorted order .. but,
> well, I am not aware about the querying API yet .. so cannot say for sure.
>
> Further, if you implement distribute.pypi .. then that too would require
> version comparison, would it not? In that case, distribute.pypi would
> depend upon distribute.installer .. and vice versa, I suppose, leading to
> circular dependencies. ?Eg:

I am not sure because the only use case I have in mind is comparing versions
when you install, update or check installed distributions. What I propose
is to leave the version stuff in installer, and as soon as we realize
it's needed
elsewhere (that will happen if it's the case before 0.7 is out), we
split it on its own.

> distribute.pypi.Distribution.find('PasteScript').get_releases() may have
> to return the releases in sorted order (by version number).
>
> There must be a reason why PJE kept parts of setuptools in
> pkg_resources.py. What is it? We may have to consider it before splitting
> pkg_resources.py itself.

Sure. I would tend to think it has grown too quickly.

>
>
>>> 3) PyPM's backend uses a) pkg_resources' version comparison, b)
>>> package_index's download logic (not API-friendly). I'd be interested to
>>> see
>>> distribute.installer provide this download logic (finding URLs, tarballs
>>> and
>>> fetching them) as an API. I believe pip and zc.buildout too relies on
>>> this
>>> download logic.
>>
>> pakage_index would be included in distribute.installer, and we could
>> probably
>> add simpler APIs to use it to drive a download
>
> Note that package_index is not API-friendly. A few violations I can
> think of: 1) it prints warning messages to stderr without programmer
> control, 2) throws random network exceptions that should be handled in a
> custom exception (see the issues I reported in distribute tracker) 3) no
> ability to control URL types (eg: I want to fetch only tarballs/zipfiles,
> not svn/hg/etc..) and so on.

Yes there are a lot of stuff to improve there,


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

From ziade.tarek at gmail.com  Wed Aug 12 10:45:04 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 12 Aug 2009 10:45:04 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <4A825878.6060707@nextday.fi>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<319e029f0908112248p337b7f3ep1889f4c8d6525cc2@mail.gmail.com>
	<4A825878.6060707@nextday.fi>
Message-ID: <94bdd2610908120145v3291068bt6c9c902bae897539@mail.gmail.com>

2009/8/12 Alex Gr?nholm <alex.gronholm at nextday.fi>:
> Lennart Regebro kirjoitti:
>
> 2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
>
>
> I am glad that you have started thinking about the module split.
>
> 1) Why are the distributions named in CamelCase? Why not
> 'distribute.resources' instead of 'DistributeResources' (like, for instance,
> zope.interface instead of ZopeInterface).
>
>
> +1 for that.
>
>
>
> Looking at PyPI, there seems to be no clear standard on this, though I would
> say 60% of distribution names are in lower case. Is there a PEP that makes
> any recommendations either way?

I don't think so but when you pip-install or easy-install a package,
PyPI provides
an alias for a lower case version of the name, meaning that these two
lines are equal:

easy_install FooBar == easy_install foobar

The problem is, IIRC, the XML-RPC Apis don't provide this case insensivity.

Last, why would we have a dot (.) in the distribution name ?
Suppose that 'distribute.resources' contains more than the
'distribute.resources' package.

Let's say :

- distribute.resources (package)
- distribute.util (package)
- run_me.py (script)

How would you call in that case the distribution ?

the "one package=one distribution" rule sounds very Java-ish to me.

In the meantime, one may consider that the first namespace is the brand or
the company rather than the packaged namespace it contains.

for the stats at PyPI, when you say 60%, do you count all zope and
Plone distributions (whatever
the namespace is) as a single count ? Because beside them, I don't
think lower, namespaced distribution
names are really frequent. I would tend to think that people use the
name of the project rather
than the namespaces.

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

From h.goebel at goebel-consult.de  Wed Aug 12 11:23:58 2009
From: h.goebel at goebel-consult.de (Hartmut Goebel)
Date: Wed, 12 Aug 2009 11:23:58 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <op.uyiye7xibrrvlq@double>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
Message-ID: <4A828A2E.1080107@goebel-consult.de>

Sridhar Ratnakumar schrieb:

> Note that package_index is not API-friendly. A few violations I can
> think of: 1) it prints warning messages to stderr without programmer
> control, 2) throws random network exceptions that should be handled in a
> custom exception (see the issues I reported in distribute tracker) 3) no
> ability to control URL types (eg: I want to fetch only
> tarballs/zipfiles, not svn/hg/etc..) and so on.

+1

Also missing:
4) No easy way to change priorities for filetypes (eggs are always
preferred) 5) No easy way to fetch other filetypes (eg. .msi or
installer-exe, esp. important on Windows) 6) No easy way to change the
URL-Scanner (if sourceforge changes URLs again)

When distribute evolves, I may contribute some code / patches for this.

-- 
Sch?nen Gru? - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP

Goebel Consult
Spezialist f?r IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Monatliche Kolumne:
<http://www.all-about-security.de/kolumnen/cissp-gefluester/>

Goebel Consult mit Mitglied bei <http://www.7-it.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4732 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090812/2515f3ca/attachment.bin>

From alex.gronholm at nextday.fi  Wed Aug 12 11:25:49 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Wed, 12 Aug 2009 12:25:49 +0300
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <4A828A2E.1080107@goebel-consult.de>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>
	<4A828A2E.1080107@goebel-consult.de>
Message-ID: <4A828A9D.3010406@nextday.fi>

Hartmut Goebel kirjoitti:
> Sridhar Ratnakumar schrieb:
>
>   
>> Note that package_index is not API-friendly. A few violations I can
>> think of: 1) it prints warning messages to stderr without programmer
>> control, 2) throws random network exceptions that should be handled in a
>> custom exception (see the issues I reported in distribute tracker) 3) no
>> ability to control URL types (eg: I want to fetch only
>> tarballs/zipfiles, not svn/hg/etc..) and so on.
>>     
>
> +1
>
> Also missing:
> 4) No easy way to change priorities for filetypes (eggs are always
> preferred) 5) No easy way to fetch other filetypes (eg. .msi or
> installer-exe, esp. important on Windows) 6) No easy way to change the
> URL-Scanner (if sourceforge changes URLs again)
>
> When distribute evolves, I may contribute some code / patches for this.
>
>   
Make sure you add an issue for this in the bug tracker, so it won't be 
forgotten by the time the code gets an overhaul.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090812/f4fc17c2/attachment.htm>

From chris at simplistix.co.uk  Wed Aug 12 11:33:17 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 12 Aug 2009 10:33:17 +0100
Subject: [Distutils] bootstrapping virtualenv?
In-Reply-To: <b654cd2e0908111040k1972d0dbh6a11ac9281c23101@mail.gmail.com>
References: <4A8142C3.2000708@simplistix.co.uk>
	<b654cd2e0908111040k1972d0dbh6a11ac9281c23101@mail.gmail.com>
Message-ID: <4A828C5D.2070702@simplistix.co.uk>

Ian Bicking wrote:
> You don't actually have to install virtualenv, just grab virtualenv.py 
> (e.g., directly from svn) and run it.  (Ditto pip)

Any chance this could be made (much) clearer on:

http://pypi.python.org/pypi/virtualenv

Maybe an Installation section with text that contains the url to 
virutalenv.py?

If you tell me where the svn is and give me access, I'd be happy to have 
a go at tidying up whatever is used to generate the PyPI page...

cheers,

Chris

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

From barry at python.org  Wed Aug 12 14:14:26 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 12 Aug 2009 08:14:26 -0400
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <4A825878.6060707@nextday.fi>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>
	<319e029f0908112248p337b7f3ep1889f4c8d6525cc2@mail.gmail.com>
	<4A825878.6060707@nextday.fi>
Message-ID: <D9407A49-3201-447E-9D34-1FDCD77349A2@python.org>

On Aug 12, 2009, at 1:51 AM, Alex Gr?nholm wrote:

> Looking at PyPI, there seems to be no clear standard on this, though  
> I would say 60% of distribution names are in lower case. Is there a  
> PEP that makes any recommendations either way?

I don't think so, but clearly PEP 8 recommends package names be  
lowercase and it just seems easier to name the distribution the same  
way.  Actually, I'm not even sure what "distribution name" means  
otherwise <wink>.

-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/20090812/22dc1df2/attachment.pgp>

From barry at python.org  Wed Aug 12 14:18:30 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 12 Aug 2009 08:18:30 -0400
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
Message-ID: <7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>

On Aug 12, 2009, at 4:35 AM, Tarek Ziad? wrote:

> I am not sure because the only use case I have in mind is comparing  
> versions
> when you install, update or check installed distributions. What I  
> propose
> is to leave the version stuff in installer, and as soon as we realize
> it's needed
> elsewhere (that will happen if it's the case before 0.7 is out), we
> split it on its own.

One feature I would love to see make standard is the ability to import  
a package and check its __version__.  Version information must be  
available from Python, and it seems like __version__ is the standard  
place to put it.  Too many times I've had to figure out the version of  
foo.bar that I'm using.  When I can do

 >>> import foo.bar
 >>> foo.bar.__version__
3.2.1

I am a much happier camper.

Right now this is largely left to the library developer, but I think  
distribute has some influence here.  People want to describe version  
numbers in only one place and if that's in the metadata, they'll tend  
not to also include it in the package namespace.  In that case,  
providing for a recommended standard way of doing it is essential.

-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/20090812/bd274dbd/attachment.pgp>

From alex.gronholm at nextday.fi  Wed Aug 12 14:21:00 2009
From: alex.gronholm at nextday.fi (=?ISO-8859-1?Q?Alex_Gr=F6nholm?=)
Date: Wed, 12 Aug 2009 15:21:00 +0300
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <D9407A49-3201-447E-9D34-1FDCD77349A2@python.org>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>
	<319e029f0908112248p337b7f3ep1889f4c8d6525cc2@mail.gmail.com>
	<4A825878.6060707@nextday.fi>
	<D9407A49-3201-447E-9D34-1FDCD77349A2@python.org>
Message-ID: <4A82B3AC.90400@nextday.fi>

Barry Warsaw kirjoitti:
> On Aug 12, 2009, at 1:51 AM, Alex Gr?nholm wrote:
>
>> Looking at PyPI, there seems to be no clear standard on this, though 
>> I would say 60% of distribution names are in lower case. Is there a 
>> PEP that makes any recommendations either way?
>
> I don't think so, but clearly PEP 8 recommends package names be 
> lowercase and it just seems easier to name the distribution the same 
> way.  Actually, I'm not even sure what "distribution name" means 
> otherwise <wink>.
>
I don't see any connection between conventions for package names and 
conventions for distribution names. As for what "distribution name" 
means, the distutils documentation explains the difference between 
distributions and packages:
http://docs.python.org/distutils/introduction.html#distutils-specific-terminology
Note that all referenced distributions there have camelCase names.
> -Barry
>


From hanno at hannosch.eu  Wed Aug 12 14:31:46 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Wed, 12 Aug 2009 14:31:46 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
Message-ID: <5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>

On Wed, Aug 12, 2009 at 2:18 PM, Barry Warsaw<barry at python.org> wrote:
> On Aug 12, 2009, at 4:35 AM, Tarek Ziad? wrote:
>
> One feature I would love to see make standard is the ability to import a
> package and check its __version__. ?Version information must be available
> from Python, and it seems like __version__ is the standard place to put it.
> Too many times I've had to figure out the version of foo.bar that I'm
> using. ?When I can do
>
>>>> import foo.bar
>>>> foo.bar.__version__
> 3.2.1
>
> I am a much happier camper.

The easiest way I could find right now seems to be:

>>> import pkg_resources
>>> dist = pkg_resources.get_distribution('foo')
>>> dist.version
3.2.1

Which isn't too bad and could be simplified into an even simpler API call.

If the package author doesn't set a __version__ attribute in his own
code, I'd be hesitant to magically make it available from the
accompanying metadata. If it's part of the metadata, an explicit API
that makes it clear that you are querying the package metadata seems
cleaner to me.

Hanno

From ianb at colorstudy.com  Wed Aug 12 19:59:33 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 12 Aug 2009 12:59:33 -0500
Subject: [Distutils]  Splitting distribute in several distributions
In-Reply-To: <b654cd2e0908121005t23c7e59csb68863eff9cf5a57@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com> 
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com> 
	<b654cd2e0908121005t23c7e59csb68863eff9cf5a57@mail.gmail.com>
Message-ID: <b654cd2e0908121059u24b1186dj511219112a1b5262@mail.gmail.com>

On Tue, Aug 11, 2009 at 7:44 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> 2009/8/12 Sridhar Ratnakumar <SridharR at activestate.com>:
> > I am glad that you have started thinking about the module split.
> >
> > 1) Why are the distributions named in CamelCase? Why not
> > 'distribute.resources' instead of 'DistributeResources' (like, for
> instance,
> > zope.interface instead of ZopeInterface).
>
> Because the distribution name is not the packages names.
> See for instance the Paste project : PasteScript, Paste, PasteDeploy.
>

Incidentally, when I named these Setuptools had a bug with certain
characters in the package names, like ".".  So there wasn't much of a choice
at the time.

-- 
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/20090812/b6702e6f/attachment.htm>

From ziade.tarek at gmail.com  Wed Aug 12 23:58:09 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 12 Aug 2009 23:58:09 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
Message-ID: <94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>

On Wed, Aug 12, 2009 at 2:31 PM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> On Wed, Aug 12, 2009 at 2:18 PM, Barry Warsaw<barry at python.org> wrote:
>> On Aug 12, 2009, at 4:35 AM, Tarek Ziad? wrote:
>>
>> One feature I would love to see make standard is the ability to import a
>> package and check its __version__. ?Version information must be available
>> from Python, and it seems like __version__ is the standard place to put it.
>> Too many times I've had to figure out the version of foo.bar that I'm
>> using. ?When I can do
>>
>>>>> import foo.bar
>>>>> foo.bar.__version__
>> 3.2.1
>>
>> I am a much happier camper.
>
> The easiest way I could find right now seems to be:
>
>>>> import pkg_resources
>>>> dist = pkg_resources.get_distribution('foo')
>>>> dist.version
> 3.2.1
>
> Which isn't too bad and could be simplified into an even simpler API call.
>
> If the package author doesn't set a __version__ attribute in his own
> code, I'd be hesitant to magically make it available from the
> accompanying metadata. If it's part of the metadata, an explicit API
> that makes it clear that you are querying the package metadata seems
> cleaner to me.

yes, and with PEP 376 (which I need to work back in asap), it will be
similar and we will
have that explicit, clean, get_metadata api.

Notice that I think it's better to use pkg_resources (and PEP 376)
tehcnique because it grabs the version
number in the PKG-INFO file which is static, and doesn't forces you to
import a module
in the execution context just to get the version. You never know what
gets executed when you import a module

Cheers
Tarek


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



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

From barry at python.org  Thu Aug 13 00:01:19 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 12 Aug 2009 18:01:19 -0400
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
Message-ID: <212BF589-C56E-4C55-BB70-B545B41441BD@python.org>

On Aug 12, 2009, at 5:58 PM, Tarek Ziad? wrote:

> yes, and with PEP 376 (which I need to work back in asap), it will be
> similar and we will
> have that explicit, clean, get_metadata api.
>
> Notice that I think it's better to use pkg_resources (and PEP 376)
> tehcnique because it grabs the version
> number in the PKG-INFO file which is static, and doesn't forces you to
> import a module
> in the execution context just to get the version. You never know what
> gets executed when you import a module

Right, but sometimes all you know is the execution context.

Do you see any reason why a library author couldn't write this in  
their __init__.py?

import pkg_resources
__version__ = pkg_resources.get_distribution('foo.bar').version

?
-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/20090812/b2e42fc9/attachment.pgp>

From ziade.tarek at gmail.com  Thu Aug 13 00:13:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 13 Aug 2009 00:13:59 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
Message-ID: <94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>

On Thu, Aug 13, 2009 at 12:01 AM, Barry Warsaw<barry at python.org> wrote:
> On Aug 12, 2009, at 5:58 PM, Tarek Ziad? wrote:
>
>> yes, and with PEP 376 (which I need to work back in asap), it will be
>> similar and we will
>> have that explicit, clean, get_metadata api.
>>
>> Notice that I think it's better to use pkg_resources (and PEP 376)
>> tehcnique because it grabs the version
>> number in the PKG-INFO file which is static, and doesn't forces you to
>> import a module
>> in the execution context just to get the version. You never know what
>> gets executed when you import a module
>
> Right, but sometimes all you know is the execution context.
>
> Do you see any reason why a library author couldn't write this in their
> __init__.py?
>
> import pkg_resources
> __version__ = pkg_resources.get_distribution('foo.bar').version
>

If we make the assumption the module is called only when it's
installed in Python, not at all.
But then, the real version number has to be somewhere, eg setup.py,
which is less nice that having it in __version__ ... :)

I think things will look better the day we remove setup.py in favor of
a static metadata file.


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

From david.lyon at preisshare.net  Thu Aug 13 01:09:04 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 12 Aug 2009 19:09:04 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
Message-ID: <0eea566be7aff928cdae23beea7ca043@preisshare.net>

On Thu, 13 Aug 2009 00:13:59 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:

> I think things will look better the day we remove setup.py in favor of
> a static metadata file.

It's good to see that you have your progressive thinking hat on Tarek
but given the history that surrounds setup.py, I suggest that removing 
"setup.py" is "unrealistic". 

You're far better off to add the functionality so that setup.py can
pick up it's metadata from an external file at runtime.

For example, add the ability for setup.py to interact with a new
file called, say "setup.xml".

To use the metadata, we'd need a function to load the metadata. Which
shouldn't be so hard to do. Perphaps, self.loadmetadata()

Avoid the temptation to use a heavyweight xml processor.

Surely doing this cannot be that hard....? even I would volunteer
to help out with this. Tell me how?

David

From barry at python.org  Thu Aug 13 01:21:45 2009
From: barry at python.org (Barry Warsaw)
Date: Wed, 12 Aug 2009 19:21:45 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <0eea566be7aff928cdae23beea7ca043@preisshare.net>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
Message-ID: <079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>

On Aug 12, 2009, at 7:09 PM, David Lyon wrote:

> For example, add the ability for setup.py to interact with a new
> file called, say "setup.xml".

Oh for Guido's sake, can we please not use XML?  I'd much prefer a  
human-friendly format ;)

-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/20090812/15fd9563/attachment.pgp>

From david.lyon at preisshare.net  Thu Aug 13 01:34:21 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 12 Aug 2009 19:34:21 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
Message-ID: <1a2c3e8f083149271705f2cfe20af6e9@preisshare.net>

On Wed, 12 Aug 2009 19:21:45 -0400, Barry Warsaw <barry at python.org> wrote:
> Oh for Guido's sake, can we please not use XML?  I'd much prefer a  
> human-friendly format ;)

xml is a human friendly format providing that it stays 'simple'. 

The advantage of xml in this instance is that the purpose of the file
is immediately obvious to newcomers ie "setup.py + setup.xml". Whereas
other extensions are less clear.

Choosing another extension and rolling your own format just adds
another level of complexity for other people to deal with.

Having said that, we already have a .EGG_INFO file with the metadata
already in it (a funny twist of fate...) so having a "setup.EGG_INFO"
or "setup.INFO" file would seem to me to be the shortest route to 
accomplishing what we have here...

Still... I prefer setup.xml over setup.INFO.. but I could
live with either...

David









From ziade.tarek at gmail.com  Thu Aug 13 10:34:07 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 13 Aug 2009 10:34:07 +0200
Subject: [Distutils] distutils.cfg vs pydistutils.cfg
In-Reply-To: <94bdd2610908111537k21404bf2jec4bcb35c592a2ad@mail.gmail.com>
References: <94bdd2610908020930h7c6ea65fo3941d9cb42ad3571@mail.gmail.com>
	<4A76A399.4040003@egenix.com>
	<EE91D64F-40E4-4CFA-8036-F522876277CD@python.org>
	<4A77F49B.3000008@egenix.com>
	<94bdd2610908040152y329f1977ub3f2af872b056d94@mail.gmail.com>
	<4A77F7FC.8060700@egenix.com>
	<94bdd2610908111537k21404bf2jec4bcb35c592a2ad@mail.gmail.com>
Message-ID: <94bdd2610908130134v3e6e418du2097c738ada041da@mail.gmail.com>

On Wed, Aug 12, 2009
>>> I also propose if that's the case, to add a function in site.py that
>>> returns USER_SITE and USER_BASE,
>>> so it can be used by site.addusersitepackages *and* by distutils here
>>
>> +1
>>
>> While you're at it, please also add a function that returns the
>> global site-packages dir(s).
>>

It's ready waiting for your review(s)

http://bugs.python.org/issue6693

Cheers
Tarek

From david.lyon at preisshare.net  Fri Aug 14 04:07:06 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 13 Aug 2009 22:07:06 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <200908130919.06054.binet@cern.ch>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<1a2c3e8f083149271705f2cfe20af6e9@preisshare.net>
	<200908130919.06054.binet@cern.ch>
Message-ID: <54c28b8496626bcef10324804ea3c6a8@preisshare.net>

On Thu, 13 Aug 2009 09:19:05 +0200, Sebastien Binet <seb.binet at gmail.com>
wrote:
> what's wrong with setup.json ?
> that's a tad friendlier than setup.xml.

Probably nothing..

So check with Tarek.... He's in charge with distutils.. not me.

The very one person that has the authority to actually *fix* the
problem is complaining about the problem. If he can't do anything
about it - there's certainly no hope for anybody else.

It just seems that if it isn't a plone/zope problem, then it
won't be looked at or even considered.

I would have thought that improving setup.py, as Tarek himself
pointed out.. would have been something that he could do.

What's happened here, is that all the political baggage of
of setuptools (management style) has also been forked...... it 
would seem...

No changes for 9 months... hmmmm.... setup.py has stayed the
same for way... way... longer than that...

David


From ziade.tarek at gmail.com  Fri Aug 14 10:02:03 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 14 Aug 2009 10:02:03 +0200
Subject: [Distutils] [Python-Dev] request for comments - standardization
	of python's purelib and platlib
In-Reply-To: <bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
References: <h61lmi$m3v$1@ger.gmane.org>
	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
Message-ID: <94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>

On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett at python.org> wrote:
>
>
> On Thu, Aug 13, 2009 at 11:23, Jan Matejek <jan.matejek at novell.com> wrote:
>>
>> Hello,
>>
>> I'm cross-posting this to distributions at freedesktop and python-dev,
>> because the topic is relevant to both groups and should be solved in
>> cooperation.
>>
>> The issue:
>>
>> In Python's default configuration (on linux), both purelib (location for
>> pure python modules) and platlib (location for platform-dependent binary
>> extensions) point to $prefix/lib/pythonX.Y/site-packages.
>> That is no good for two main reasons.
>>
>> One, python depends on the "lib" directory. (from distro's point of
>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
>> impossible to install python under /usr/lib64 without heavy patching.
>> Repeated attempts to bring python developers to acknowledge and rectify
>> the situation have all failed (common argument here is "that would mean
>> redesign of distutils and huge parts of whatnot").
>
> This is now Tarek's call, so this may or may not have changed in terms of
> what the (now) distutils maintainer thinks.
>

I don't recall those repeated attempts , but I've been around for less
than two years.

You are very welcome to come in the Distutils-SIG ML to discuss these matters.
I'm moving the discussion there.

Among the proposals you have detailed, the sharedir way seems like the
most simple/interesting
one (depending on you answer to Brett's question )


Regards
Tarek

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

From jan.matejek at novell.com  Fri Aug 14 18:11:07 2009
From: jan.matejek at novell.com (Jan Matejek)
Date: Fri, 14 Aug 2009 18:11:07 +0200
Subject: [Distutils] request for comments - standardization of python's
 purelib and platlib
In-Reply-To: <bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
References: <h61lmi$m3v$1@ger.gmane.org>
	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
Message-ID: <4A858C9B.70900@novell.com>

Dne 13.8.2009 21:22, Brett Cannon napsal(a):
> On Thu, Aug 13, 2009 at 11:23, Jan Matejek <jan.matejek at novell.com> wrote:
>> 1 - the traditional way
>> purelib = /usr/lib/pythonX.Y/site-packages
>> platlib = /usr/lib(64)/pythonX.Y/site-packages
>>
> 
> Why can't pure libraries go into lib64 as well? There is nothing saying that
> a pure Python package won't have a setup.py that installs different files
> based on whether it is for a 32-bit or 64-bit CPython install.

What i'd like to accomplish is to have pure "noarch" package that can be
installed unchanged into 32bit or 64bit (or 256bit) system, and the
respective python would still find the files.
Or, to put it another way, a package that can be installed into a
multiarch system and be recognized by pythons of all architectures
(assuming they are the same version, of course).

If the distutils package installs different pure files for 32bit and
64bit python, then it can't be "noarch", so it doesn't matter if it goes
into lib64.

Also, such package would break this particular scheme - in the situation
where the user installs only 32bit version of such package and tries to
run it with 64bit python, it will probably break in some weird way.

Last but not least, i'd argue that if a python-only package installs
different files for different platforms, it is platform-dependent and
therefore not pure ;)


>> 2 - the sharedir way
>> purelib = /usr/share/python/X.Y
>> platlib = /usr/lib(64)/pythonX.Y/site-packages
> 
> 
> Now are you proposing that packages that have both Python source and
> extensions be split based on the type of files, or that only pure Python
> packages go to /usr/share/python and any packages that are mixed go into
> lib(64)? If you are proposing the latter this is more reasonable as the
> former will require using .pth files to get import to search both locations
> for files in the same package and that just feels icky to me.

The latter. Assume no change to "normal" distutils mechanism, only
setting the default paths. (for now anyway)

regards
m.


From jan.matejek at novell.com  Fri Aug 14 18:32:08 2009
From: jan.matejek at novell.com (Jan Matejek)
Date: Fri, 14 Aug 2009 18:32:08 +0200
Subject: [Distutils] [Python-Dev] request for comments - standardization
 of python's purelib and platlib
In-Reply-To: <94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
References: <h61lmi$m3v$1@ger.gmane.org>	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
	<94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
Message-ID: <4A859188.8070506@novell.com>

Dne 14.8.2009 10:02, Tarek Ziad? napsal(a):
>>> One, python depends on the "lib" directory. (from distro's point of
>>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
>>> impossible to install python under /usr/lib64 without heavy patching.
>>> Repeated attempts to bring python developers to acknowledge and rectify
>>> the situation have all failed (common argument here is "that would mean
>>> redesign of distutils and huge parts of whatnot").
>>
>> This is now Tarek's call, so this may or may not have changed in terms of
>> what the (now) distutils maintainer thinks.
>>
> 
> I don't recall those repeated attempts , but I've been around for less
> than two years.

then please have a look at those:

http://bugs.python.org/issue858809
http://bugs.python.org/issue1294959
http://mail.python.org/pipermail/python-dev/2007-April/072653.html

> 
> You are very welcome to come in the Distutils-SIG ML to discuss these matters.
> I'm moving the discussion there.

Thank you. I stopped reposting to python-dev for now.

>
> Among the proposals you have detailed, the sharedir way seems like the
> most simple/interesting
> one (depending on you answer to Brett's question )
> 
> 
> Regards
> Tarek
> 



From david.lyon at preisshare.net  Sat Aug 15 02:59:02 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 14 Aug 2009 20:59:02 -0400
Subject: [Distutils] [Python-Dev] request for comments - standardization
 of python's purelib and platlib
In-Reply-To: <94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
References: <h61lmi$m3v$1@ger.gmane.org>
	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
	<94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
Message-ID: <6a4baa9f0299a6bb347536d01ddae126@preisshare.net>


Hi Tarek,

What is needed is to remove/refactor the hardcoding of paths that
currently exists within distutils and replace it with the ability to 
override the defaults via configuration files. (distutils.cfg?)

If there's one thing that's certain for the future, its that
python will go onto more platforms. Using different paths.

When people are complaining about paths being hard-coded into
distutils and it causing angst, I think that their complaints are
valid.

I can find posts going back to 2004 for windows users complaining
about exactly the same thing. So it isn't a new issue. The problem
applies to both linux and windows.

Anyway.. do you know the code that we're talking about?

David


On Fri, 14 Aug 2009 10:02:03 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett at python.org> wrote:
>>
>>
>> On Thu, Aug 13, 2009 at 11:23, Jan Matejek <jan.matejek at novell.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm cross-posting this to distributions at freedesktop and python-dev,
>>> because the topic is relevant to both groups and should be solved in
>>> cooperation.
>>>
>>> The issue:
>>>
>>> In Python's default configuration (on linux), both purelib (location
for
>>> pure python modules) and platlib (location for platform-dependent
binary
>>> extensions) point to $prefix/lib/pythonX.Y/site-packages.
>>> That is no good for two main reasons.
>>>
>>> One, python depends on the "lib" directory. (from distro's point of
>>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
>>> impossible to install python under /usr/lib64 without heavy patching.
>>> Repeated attempts to bring python developers to acknowledge and rectify
>>> the situation have all failed (common argument here is "that would mean
>>> redesign of distutils and huge parts of whatnot").
>>
>> This is now Tarek's call, so this may or may not have changed in terms
of
>> what the (now) distutils maintainer thinks.
>>
> 
> I don't recall those repeated attempts , but I've been around for less
> than two years.
> 
> You are very welcome to come in the Distutils-SIG ML to discuss these
> matters.
> I'm moving the discussion there.
> 
> Among the proposals you have detailed, the sharedir way seems like the
> most simple/interesting
> one (depending on you answer to Brett's question )
> 
> 
> Regards
> Tarek

From chris at simplistix.co.uk  Sat Aug 15 13:01:30 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 12:01:30 +0100
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't support -m
Message-ID: <4A86958A.4040507@simplistix.co.uk>

With a buildout.cfg section that looks like:

[py]
recipe = zc.recipe.egg
eggs = ...
interpreter = py

If I try and do:

bin/py -m some.moldule

...I get:

Traceback (most recent call last):
   File "bin/py", line 28, in <module>
     _options, _args = getopt.getopt(sys.argv[1:], 'ic:')
   File "/usr/local/lib/python2.6/getopt.py", line 91, in getopt
     opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
   File "/usr/local/lib/python2.6/getopt.py", line 191, in do_shorts
     if short_has_arg(opt, shortopts):
   File "/usr/local/lib/python2.6/getopt.py", line 207, in short_has_arg
     raise GetoptError('option -%s not recognized' % opt, opt)

How should whatever generates bin/py be changed to enable -m to work?

Chris

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

From gary.poster at canonical.com  Sat Aug 15 13:50:41 2009
From: gary.poster at canonical.com (Gary Poster)
Date: Sat, 15 Aug 2009 07:50:41 -0400
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
	support -m
In-Reply-To: <4A86958A.4040507@simplistix.co.uk>
References: <4A86958A.4040507@simplistix.co.uk>
Message-ID: <E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>


On Aug 15, 2009, at 7:01 AM, Chris Withers wrote:

> With a buildout.cfg section that looks like:
>
> [py]
> recipe = zc.recipe.egg
> eggs = ...
> interpreter = py
>
> If I try and do:
>
> bin/py -m some.moldule
>
> ...I get:
>
> Traceback (most recent call last):
>  File "bin/py", line 28, in <module>
>    _options, _args = getopt.getopt(sys.argv[1:], 'ic:')
>  File "/usr/local/lib/python2.6/getopt.py", line 91, in getopt
>    opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
>  File "/usr/local/lib/python2.6/getopt.py", line 191, in do_shorts
>    if short_has_arg(opt, shortopts):
>  File "/usr/local/lib/python2.6/getopt.py", line 207, in short_has_arg
>    raise GetoptError('option -%s not recognized' % opt, opt)
>
> How should whatever generates bin/py be changed to enable -m to work?

The script is generated from a template near the bottom of  
zc.buildout.easy_install.  Change it, to make it part of zc.buildout  
1.4.

Gary


From chris at simplistix.co.uk  Sat Aug 15 13:52:53 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 12:52:53 +0100
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
 support -m
In-Reply-To: <E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>
References: <4A86958A.4040507@simplistix.co.uk>
	<E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>
Message-ID: <4A86A195.9090805@simplistix.co.uk>

Gary Poster wrote:
> 
>> How should whatever generates bin/py be changed to enable -m to work?
> 
> The script is generated from a template near the bottom of 
> zc.buildout.easy_install.  Change it, to make it part of zc.buildout 1.4.

Yeah, the problem is I don't know what changes to make ;-)

I don't know how to make -m work in that code :-S

Chris

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

From jim at zope.com  Sat Aug 15 14:23:14 2009
From: jim at zope.com (Jim Fulton)
Date: Sat, 15 Aug 2009 08:23:14 -0400
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
	support -m
In-Reply-To: <4A86A195.9090805@simplistix.co.uk>
References: <4A86958A.4040507@simplistix.co.uk>
	<E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>
	<4A86A195.9090805@simplistix.co.uk>
Message-ID: <1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>

On Sat, Aug 15, 2009 at 7:52 AM, Chris Withers<chris at simplistix.co.uk> wrote:
> Gary Poster wrote:
>>
>>> How should whatever generates bin/py be changed to enable -m to work?
>>
>> The script is generated from a template near the bottom of
>> zc.buildout.easy_install. ?Change it, to make it part of zc.buildout 1.4.
>
> Yeah, the problem is I don't know what changes to make ;-)
>
> I don't know how to make -m work in that code :-S

There's nothing all that interesting about that code. I think you just
don't know how to make -m work in a custom script.

AFAIK, the standard interpreter command line arguments are implemented
at a low level and aren't meant to be reusable.  To make them work
basically requires reimplementing them.  It would be useful if there
was a module that just had implementations of (most of) the standard
interpreter options.

Jim

-- 
Jim Fulton

From chris at simplistix.co.uk  Sat Aug 15 16:54:54 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 15:54:54 +0100
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
Message-ID: <4A86CC3E.5040300@simplistix.co.uk>

Hanno Schlichting wrote:
> The easiest way I could find right now seems to be:
> 
>>>> import pkg_resources
>>>> dist = pkg_resources.get_distribution('foo')
>>>> dist.version
> 3.2.1
> 
> Which isn't too bad and could be simplified into an even simpler API call.
> 
> If the package author doesn't set a __version__ attribute in his own
> code, I'd be hesitant to magically make it available from the
> accompanying metadata. If it's part of the metadata, an explicit API
> that makes it clear that you are querying the package metadata seems
> cleaner to me.

+1 to all of this...

Chris

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

From chris at simplistix.co.uk  Sat Aug 15 17:06:40 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 16:06:40 +0100
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
Message-ID: <4A86CF00.5030300@simplistix.co.uk>

Tarek Ziad? wrote:
> elements). root modules in setuptools will be moved to the
> distribute.core package so the
>   root namespace stays empty.

Is this purely to avoid the problem solved by Martin von Lewis's PEP to 
do with namespace packages?

> - Distribution Name  = "DistributeResources"
> - Content: the part of pkg_resources.py that handles installed
> distribution querying +  renamed to "distribute.resources"
 >
> - Distribution Name  = "DistributeEntryPoints"
> - Content: the part of pkg_resources.py that handles entry points +
> renamed to "distribute.entry_points"
 >
> - Distribution Name  = "DistributeInstaller"
> - Content: the part of pkg_resources.py that handles version
> comparison + package_index, that gets files at pypi + easy_install.py
> + easy_install command extracted from setuptools package +  renamed
> into a "distribute.installer" package

These all raise the question for me, again:
What's the difference between a distribution and a package?
Which is the one with a setup.py and what is the other one?

If a distribution has a setup.py, then I'm not just having the 
distribution names be the same as the module names and be:

distribution_resources
distribution_entrypoints (why is this not part of
                           distribution_resources?)
distribution_installer

If it's package that has the setup.py, then just replace 'distribution' 
with 'package' in the above. If you're splitting these because they 
deserve to be independent packages, then why do they need to be tied 
together under the 'distribute' name?

Chris

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

From chris at simplistix.co.uk  Sat Aug 15 17:08:29 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 16:08:29 +0100
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
Message-ID: <4A86CF6D.3050708@simplistix.co.uk>

Tarek Ziad? wrote:
> So, like a subpart of package_index ? this is a nice idea, so tools
> like yolk or z3c.pypimirror could browse pypi index with it,
> 
> It could also have a full xmlrpc client implementation for PyPI xml-rpc APIs,

I like this idea too, but why call it distribute.anything? It sounds 
like it's basically a python client library for pypi, so why not just 
have both the distribution and package name be pypi?

cheers,

Chris

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

From chris at simplistix.co.uk  Sat Aug 15 17:10:30 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 16:10:30 +0100
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
Message-ID: <4A86CFE6.101@simplistix.co.uk>

Tarek Ziad? wrote:
> I think things will look better the day we remove setup.py in favor of
> a static metadata file.

I concur this is unlikely to ever happen and agree that the best thing 
to do is writer a helper that lets people get access to their metadata 
from a declarative file, eg:

from distribute import setup

...

setup(metadata='setup.ini',**other_options)

cheers,

Chris

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

From chris at simplistix.co.uk  Sat Aug 15 17:11:52 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 16:11:52 +0100
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
Message-ID: <4A86D038.8050005@simplistix.co.uk>

Barry Warsaw wrote:
> On Aug 12, 2009, at 7:09 PM, David Lyon wrote:
> 
>> For example, add the ability for setup.py to interact with a new
>> file called, say "setup.xml".
> 
> Oh for Guido's sake, can we please not use XML?  I'd much prefer a 
> human-friendly format ;)

+10, but I'm +sys.maxint on not using json. We want to use javascript to 
configure python packages? Wait, what?!

It the data doesn't need to be nested, I'd say use ConfigParser 
format... If it does, then reluctantly xml...

Chris

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

From chris at simplistix.co.uk  Sat Aug 15 17:14:32 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 16:14:32 +0100
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
 support -m
In-Reply-To: <1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>
References: <4A86958A.4040507@simplistix.co.uk>	
	<E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>	
	<4A86A195.9090805@simplistix.co.uk>
	<1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>
Message-ID: <4A86D0D8.9090307@simplistix.co.uk>

Jim Fulton wrote:
> AFAIK, the standard interpreter command line arguments are implemented
> at a low level and aren't meant to be reusable.  

Anyone know if this code is in python or C?
If the former, where do they live? I might have a crack at extracting 
them into a little package...

Chris

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

From jim at zope.com  Sat Aug 15 17:30:24 2009
From: jim at zope.com (Jim Fulton)
Date: Sat, 15 Aug 2009 11:30:24 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <4A86D038.8050005@simplistix.co.uk>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
Message-ID: <1099b90b0908150830m3014393by85ddea2b2e5e09d9@mail.gmail.com>

On Sat, Aug 15, 2009 at 11:11 AM, Chris Withers<chris at simplistix.co.uk> wrote:
> Barry Warsaw wrote:
>>
>> On Aug 12, 2009, at 7:09 PM, David Lyon wrote:
>>
>>> For example, add the ability for setup.py to interact with a new
>>> file called, say "setup.xml".
>>
>> Oh for Guido's sake, can we please not use XML? ?I'd much prefer a
>> human-friendly format ;)
>
> +10, but I'm +sys.maxint on not using json. We want to use javascript to
> configure python packages? Wait, what?!
>
> It the data doesn't need to be nested, I'd say use ConfigParser format...

+1, even if the information is nested.

Note that there are variants of config parser that support nesting and
there are techniques for representing nested data in normal
config-parser files.

Jim

-- 
Jim Fulton

From chris at simplistix.co.uk  Sat Aug 15 17:33:03 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Aug 2009 16:33:03 +0100
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <1099b90b0908150830m3014393by85ddea2b2e5e09d9@mail.gmail.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>	
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>	
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>	
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>	
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>	
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>	
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>	
	<4A86D038.8050005@simplistix.co.uk>
	<1099b90b0908150830m3014393by85ddea2b2e5e09d9@mail.gmail.com>
Message-ID: <4A86D52F.4040507@simplistix.co.uk>

Jim Fulton wrote:
> Note that there are variants of config parser that support nesting and
> there are techniques for representing nested data in normal
> config-parser files.

...but I've not seen one that doesn't suck ;-)
(for example the one at 
http://docs.python.org/library/logging.html#configuring-logging)

I'd be happy to be proved wrong of course...

Chris

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

From ben+python at benfinney.id.au  Sun Aug 16 01:38:13 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 16 Aug 2009 09:38:13 +1000
Subject: [Distutils] Splitting distribute in several distributions
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<4A86CF00.5030300@simplistix.co.uk>
Message-ID: <877hx4odga.fsf@benfinney.id.au>

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

> These all raise the question for me, again:
> What's the difference between a distribution and a package?
> Which is the one with a setup.py and what is the other one?

<URL:http://docs.python.org/distutils/introduction.html#general-python-terminology>
<URL:http://docs.python.org/distutils/introduction.html#distutils-specific-terminology>

> If a distribution has a setup.py, then I'm not just having the
> distribution names be the same as the module names

This policy fails when the distribution includes multiple modules, or
multiple packages.

-- 
 \            ?Simplicity is prerequisite for reliability.? ?Edsger W. |
  `\                                                          Dijkstra |
_o__)                                                                  |
Ben Finney


From seb.binet at gmail.com  Thu Aug 13 09:19:05 2009
From: seb.binet at gmail.com (Sebastien Binet)
Date: Thu, 13 Aug 2009 09:19:05 +0200
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <1a2c3e8f083149271705f2cfe20af6e9@preisshare.net>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<1a2c3e8f083149271705f2cfe20af6e9@preisshare.net>
Message-ID: <200908130919.06054.binet@cern.ch>

On Thursday 13 August 2009 01:34:21 David Lyon wrote:
> On Wed, 12 Aug 2009 19:21:45 -0400, Barry Warsaw <barry at python.org> wrote:
> > Oh for Guido's sake, can we please not use XML?  I'd much prefer a
> > human-friendly format ;)
>
> xml is a human friendly format providing that it stays 'simple'.
>
> The advantage of xml in this instance is that the purpose of the file
> is immediately obvious to newcomers ie "setup.py + setup.xml". Whereas
> other extensions are less clear.

what's wrong with setup.json ?
that's a tad friendlier than setup.xml.

cheers,
sebastien.
-- 
#########################################
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#########################################

From zooko at zooko.com  Sun Aug 16 17:14:29 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sun, 16 Aug 2009 09:14:29 -0600
Subject: [Distutils] Low Level API for translating distutils/setuptools
	metatdata to Debian metadata
In-Reply-To: <20090722155233.GA43860@Boo.lan>
References: <20090529091202.GB22620@Boo.lan>
	<38B432CD-A600-4FB9-AF88-9D18DB648045@zooko.com>
	<20090722155233.GA43860@Boo.lan>
Message-ID: <9789A39D-776F-4CCD-BCCC-004C52F0156F@zooko.com>

On Wednesday,2009-07-22, at 9:52 , Brian Sutherland wrote:

> van.pydeb is designed to be run at package build time, rather than  
> at the time you create the source package. I assume that's when  
> stdeb's code runs? Using apt-file during package build time on one  
> of the Debian project's auto-builders will not be acceptable (I  
> assume).

So if I understand correctly there is a Python package with its  
accompanying metadata, in a setup.py and possibly a setup.cfg file,  
and then there is some step which produces a "Debian source package",  
which is a thing that includes a .dsc file, a .orig.tar.gz file, and  
a .diff.gz file, right?  And then you transport those files to a  
build machine and run a package builder to turn those files into a .deb.

So, stdeb is a tool to accomplish that first step, of taking in a  
setup.py and writing out a .dsc file and related files.

Now the problem I'm having is that I want stdeb to *correctly* (i.e.,  
without guessing) determine which Debian package provides which  
Python distribution, and the answer to that question depends on which  
Debian (/Ubuntu) distribution you are building for.  There is no way  
for that question to be automatically, correctly answered in a way  
that is generic for all Debian distributions.  That means that you  
can't create a .dsc-and-related-files one time, generically, and then  
copy them to the autobuilders and have a bunch of .deb's -- one for  
each specific distribution -- be built from the same .dsc.

So they way I currently do it [1, 2] is that I run stdeb and then run  
dpkg-buildpackage on many separate buildslaves, each of which is  
running a different Debian distribution.  This works fine!  The  
result is a .deb for that specific Debian distribution which has the  
exact right Dependencies for that distribution.

Regards,

Zooko

[1] http://allmydata.org/buildbot-pycryptopp/waterfall
[2] http://allmydata.org/buildbot-zfec/waterfall

From zooko at zooko.com  Sun Aug 16 22:16:29 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sun, 16 Aug 2009 14:16:29 -0600
Subject: [Distutils] how do I add some functionality to my setup.py which is
	testable and modular?
Message-ID: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>

Folks:

I have a recurring problem with distutils/setuptools/Distribute,  
which is that I don't know how to extend the functionality of  
setup.py and make the new functionality be testable and modular.

Here's one specific example that I currently have a lot of experience  
with: I'd like to generate a version number from revision control  
history.  Don't get hung up on the desired functionality though -- if  
you think that generating version numbers is best done a different  
way, or if you don't care about generating version numbers, then  
please just mentally insert some other extension of your build  
functionality that you do care about.

I'm familiar with three different ways to implement an extension like  
this.

The first is what Nevow does [1], which is to write in setup.py "from  
nevow import __version__".  Well, this works in the case that  
setup.py is being executed as the command-line script in a fresh,  
empty Python interpreter, but it fails in the case that the Python  
interpreter has already been running for a while, has already  
imported nevow (a *different* nevow from a different location on the  
local filesystem), and is now importing *this* nevow's setup module  
in order to build this nevow.  This happens with setuptools and  
py2exe.  Distribute v0.6 includes a patch [2] to fix this, but I'm  
not sure the patch is right (it involves 'for m in various_modules:  
del sys.modules[m]' and it doesn't seem to fix all cases).  PJE says  
"Thou shalt not import yourself when trying to build yourself" [3].   
Glyph says "Then how do I test this code?" [4].  I say "Ugh, I don't  
know. Let's look at the other two ways to do it."

The second is what I do in some of my packages such as pycryptopp  
[5]. Just take that functionality that you want to add to all of your  
packages and cut and paste the code into each of your setup.py's,  
then edit it a little to reflect the correct name of the current  
package.  This sucks because you're cutting and pasting code, because  
your setup.py gets bigger and hairier the more functionality your  
build system has, and because, again, you can't test it.

The third is what I do in Tahoe-LAFS [6].  I moved the functionality  
in question into a separate Python package, in this case named  
"darcsver" [7], and used setuptools's plugin system to add a command  
named "darcsver" which initializes the distribution.metadata.version  
attribute correctly.  Then I had to add a bunch of aliases to my  
setup.cfg [8] saying "If you're going to build, first darcsver, and  
if you're going to install, first darcsver, and ...".  This sort of  
works, except that yesterday my programming partner Brian Warner  
informed me [9] that he expected the "python ./setup.py --version"  
command-line to output the version number.  Argh!  There is no way to  
configure in my setup.cfg "If you're going to --version, first  
darcsver.".

So it appears to me that none of these techniques are both modular/ 
testable and compatible with distutils/setuptools/Distribute.  What  
are we to do?

Regards,

Zooko

[1] http://www.divmod.org/trac/browser/trunk/Nevow/setup.py?rev=17531
[2] http://bugs.python.org/setuptools/issue20
[3] http://bugs.python.org/setuptools/msg139
[4] http://www.divmod.org/trac/ticket/2699#comment:20
[5] http://allmydata.org/trac/pycryptopp/browser/setup.py?rev=661#L181
[6] http://allmydata.org/trac/tahoe/browser/setup.py?rev=4036#L97
[7] http://allmydata.org/trac/darcsver
[8] http://allmydata.org/trac/tahoe/browser/setup.cfg?rev=3996#L46
[9] http://allmydata.org/trac/darcsver/ticket/6

From pje at telecommunity.com  Mon Aug 17 02:17:11 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 16 Aug 2009 20:17:11 -0400
Subject: [Distutils] how do I add some functionality to my setup.py
 which is testable and modular?
In-Reply-To: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
Message-ID: <20090817001724.E76AB3A4119@sparrow.telecommunity.com>

At 02:16 PM 8/16/2009 -0600, Zooko Wilcox-O'Hearn wrote:
>So it appears to me that none of these techniques are both modular/ 
>testable and compatible with distutils/setuptools/Distribute.  What
>are we to do?

We could be modular if there was a way to specify pre-setup.py 
dependencies.  Unfortunately, there isn't such a thing at the moment, 
short of calling setup() twice, and forcing the first call to have no 
script arguments, just a setup_requires argument.

Of course, that'd only work if setuptools were present, and it would 
also force an immediate download of the build dependencies in 
question.  Something like:

   try:
       from setuptools import Distribution
   except ImportError:
       pass
   else:
       Distribution(dict(setup_requires=[...]))

If you want to get fancy, you could replace the "pass" with printing 
some user-readable instructions after attempting to see if your 
build-time dependencies are already present.


From david.lyon at preisshare.net  Mon Aug 17 02:55:53 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sun, 16 Aug 2009 20:55:53 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <4A86D038.8050005@simplistix.co.uk>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
Message-ID: <69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>

On Sat, 15 Aug 2009 16:11:52 +0100, Chris Withers <chris at simplistix.co.uk>
wrote:
> Barry Warsaw wrote:
>> On Aug 12, 2009, at 7:09 PM, David Lyon wrote:
>> 
>>> For example, add the ability for setup.py to interact with a new
>>> file called, say "setup.xml".
>> 

Not disagreeing - just discussing..

ConfigParser is good.. no debate.. it's more modern than the
.egg_info metadata format, and easier than xml.

> It the data doesn't need to be nested, I'd say use ConfigParser 
> format... If it does, then reluctantly xml...

We must resist the option to nest (against unnecessary complexity). 
ConfigParser does lists easily so you can store a list of files 
extremely easily. It also does free form text (descriptions).

One advantage of ConfigParser is that it's more built in to
python than xml and just a breeze to edit the data. If somebody
needs scripts to adjust version numbers, that's just so easy also.

For me, that only leaves the choice of a filename.. 

 - setup.info

 - setup.conf

 - others..?

Having a setup.py and a setup.info to me seems simple and
straightforward. It's easier to understand than having all
the metadata 'hardcoded' in a program (as "cute" as that is).

I'll try to build some samples and post them on the distutils
page during the week. It may only be an hour or two of work
to flesh out some improvements.

David






From ziade.tarek at gmail.com  Mon Aug 17 09:34:56 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Aug 2009 09:34:56 +0200
Subject: [Distutils] Static metadata using setup.cfg
Message-ID: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>

Hello

Following the discussion on the format of the static metadata file,
it's evident for me that it has to be a ConfigParser file.

Now for the name of the file, I wouldn't want yet another file since
we already have
setup.cfg and since it can be extended w/o any problem or bacward
compatibility issue.

(That's from Tres and Matthias idea at Pycon)

I am also realizing that we can use it to describe "static metadata"
almost with the
existing distutils code.

We can use the [global] section of the setup.cfg file to describe them.

If we want to remove all metadata expressed as setup() arguments, we
can just move them
to the setup.cfg.

example of setup.cfg file:

"""
[global]
name: foo
version: 1.0
author: tarek
long_description: some
  long description
  here

url: http://example.com
"""

What's left in setup.py :

"""
from distutils.core import setup

setup()
"""

Right now the behavior of the code is:

Distutils will take the setup.cfg options and apply them to the
Distribution class,
overriding any argument passed to setup(), then they will be in turn
overriden by
the command line options if any.

This behavior seems fine.

Now there's a very small change to make in distutils to make this work,
wich consists of applying these values to the DistutilsMetadata
object (the metadata attribute in the dist instance)

I've changed this in my working trunk to give a try, and it works fine.

the long_description field is expressed as a multi-line field following
the config parser convention so no problem for it (see my example)

Although there's another change we need to apply and decide : being
able to express a
list of values, for fields like "keywords" or "classifiers".

It can be a "," separated list of values, or a "\n" separated one.

I am proposing the current scheme (applying it in this precise order):

1/ if the value contains '\n' signs, it's a  list and values are
splitted using \n, then each element is left stripped
   (not sure yet if we want to right strip them too)

2/ if the value contains ',' signs, it's a list and values are
splitted using ','    (not sure yet if we want to strip them)
3/ else, it's a value

This allows us to use "," for small lists like keywords we know they
will never contain any "," sign,
and several lines when the values might contain "," signs. So for example:


"""
[global]
name: foo
version: 1.0
author: tarek
long_description: some
  long description
  here

url: http://example.com
keywords: one, two, three
classifiers =
  Classifier1
  Classifier2
  Classifier3
"""

Any thoughts ?


Cheers
Tarek

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

From rylesny at gmail.com  Mon Aug 17 09:45:45 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 00:45:45 -0700 (PDT)
Subject: [Distutils] Why is requiring version 0.0.1 when both 0.0.1 and
	0.0.2 are available a conflict?
Message-ID: <a30c43aa-f285-4fb1-b27f-79ddb5d5e145@d4g2000yqa.googlegroups.com>

I have 2 egg versions of 'mypkg' installed in /custom/site-packages,
0.0.1 and 0.0.2 This directory is an alternate site directory as
described here: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation

I have elected to not use easy_install --multi-version since it's
convenient to have easy-install.pth set up so that users can by
default import the latest version if they don't explicitly require a
version either via setup.py or by using pkg_resources.require
directly.

However, require() is refusing to resolve version 0.0.1:

Python 2.6.2 (r262:71600, Jul 16 2009, 14:04:28)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py> from pkg_resources import require
py> require("mypkg==0.0.1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 626, in
require
  File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 528, in
resolve
pkg_resources.VersionConflict: (mypkg 0.0.2 (/custom/site-packages/
mypkgl-0.0.2-py2.6.egg), Requirement.parse('mypkg==0.0.1'))
py>

Can someone explain what exactly the conflict is (I'm guessing
pkg_resources is unhappy that 0.0.2 is already on sys.path)?

I'd like for users to be able to explicitly use the older version if
they're not yet comfortable with the new one. And a user just writing
a simple script without wanting setuptools, or even simply trying
something in the interactive interpreter, should be able to access the
latest version without needing to know about pkg_resources.

From hanno at hannosch.eu  Mon Aug 17 11:48:24 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Mon, 17 Aug 2009 11:48:24 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
Message-ID: <5cae42b20908170248y7a3f8c86meb920ffeba0a7829@mail.gmail.com>

On Mon, Aug 17, 2009 at 9:34 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> Following the discussion on the format of the static metadata file,
> it's evident for me that it has to be a ConfigParser file.

Big +1

> I am proposing the current scheme (applying it in this precise order):
>
> 1/ if the value contains '\n' signs, it's a ?list and values are
> splitted using \n, then each element is left stripped
> ? (not sure yet if we want to right strip them too)
>
> 2/ if the value contains ',' signs, it's a list and values are
> splitted using ',' ? ?(not sure yet if we want to strip them)
> 3/ else, it's a value

I'd generally prefer a full strip() on list entries. People tend to
put trailing whitespace into files without noticing it too much. The
number of whitespace fanatics is certainly larger in Python cycles,
but not among casual developers.

Hanno

From rylesny at gmail.com  Mon Aug 17 09:23:50 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 00:23:50 -0700 (PDT)
Subject: [Distutils] Why is requiring version 0.0.1 when both 0.0.1 and
	0.0.2 are available a conflict?
Message-ID: <f022ab36-99f5-4850-92af-038841312d33@j21g2000yqe.googlegroups.com>

I have 2 egg versions of 'mypkg' installed in /custom/site-packages,
0.0.1 and 0.0.2 This directory is an alternate site directory as
described here: http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation

I have elected to not use easy_install --multi-version since it's
convenient to have easy-install.pth set up so that users can by
default import the latest version if they don't explicitly require a
version either via setup.py or by using pkg_resources.require
directly.

However, require() is refusing to resolve version 0.0.1:

Python 2.6.2 (r262:71600, Jul 16 2009, 14:04:28)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
py> from pkg_resources import require
py> require("mypkg==0.0.1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 626, in
require
  File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 528, in
resolve
pkg_resources.VersionConflict: (mypkg 0.0.2 (/custom/site-packages/
mypkgl-0.0.2-py2.6.egg), Requirement.parse('mypkg==0.0.1'))
py>

Can someone explain what exactly the conflict is (I'm guessing
pkg_resources is unhappy that 0.0.2 is already on sys.path)?

I'd like for users to be able to explicitly use the older version if
they're not yet comfortable with the new one. And a user just writing
a simple script without wanting setuptools, or even simply trying
something in the interactive interpreter, should be able to access the
latest version without needing to know about pkg_resources.

From warner at lothar.com  Mon Aug 17 07:55:28 2009
From: warner at lothar.com (Brian Warner)
Date: Sun, 16 Aug 2009 22:55:28 -0700
Subject: [Distutils] how do I add some functionality to my setup.py
 which is testable and modular?
In-Reply-To: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
Message-ID: <20090816225528.29da49c5@lothar.com>

On Sun, 16 Aug 2009 14:16:29 -0600
Zooko Wilcox-O'Hearn <zooko at zooko.com> wrote:

> Folks:
> 
> I have a recurring problem with distutils/setuptools/Distribute,  
> which is that I don't know how to extend the functionality of  
> setup.py and make the new functionality be testable and modular.
> ...
> Here's one specific example that I currently have a lot of
> experience with: I'd like to generate a version number from revision
> control history.
> ...
> 
> The third is what I do in Tahoe-LAFS [6].  I moved the functionality  
> in question into a separate Python package, in this case named  
> "darcsver" [7], and used setuptools's plugin system to add a command  
> named "darcsver" which initializes the distribution.metadata.version  
> attribute correctly.  Then I had to add a bunch of aliases to my  
> setup.cfg [8] saying "If you're going to build, first darcsver, and  
> if you're going to install, first darcsver, and ...".  This sort of  
> works, except that yesterday my programming partner Brian Warner  
> informed me [9] that he expected the "python ./setup.py --version"  
> command-line to output the version number.  Argh!  There is no way
> to configure in my setup.cfg "If you're going to --version, first  
> darcsver.".

I think I have a plan for addressing this in the specific case of Tahoe.
The following may be irrelevant to the extending-setuptools discussion,
but it also might be informative.

The job of "setup.py darcsver" (as used by Tahoe) is to perform a
relatively disk-intensive operation to compute the current source tree's
version string and then record it in two places:

 src/allmydata/_version.py : for use by tahoe itself, so it knows it own
                             version at runtime, i.e. so that running a
                             "tahoe --version" command works
 distribution.metadata.version : for use by setuptools, so commands like
                                 "setup.py sdist" can name the tarball
                                 correctly

"distribution.metadata.version" is usually set by passing a version=
argument to the main setup() call inside setup.py . Packages can use
whatever mechanism they like to decide what to pass to version= . Tahoe
currently never passes a version= to setup().

There are two basic scenarios that Tahoe's what-version-should-I-use
code must contend with:

 1: running in a darcs checkout
 2: running from a source tarball, without _darcs/ metadata

We always use darcsver to populate src/allmydata/_version.py before
generating a tarball, so the #2 scenario should always find a
_version.py file with the pre-computed version string.

darcsver has code to handle the situation where it cannot use darcs to
compute a version string (either "darcs" is unrunnable or _darcs/ is
missing), and *also* has an existing _version.py file. In this case, it
reads _version.py and greps the version string out of it, then saves the
result in distribution.metadata.version . 

This is the bit that's relevant to Zooko's main question: it doesn't
attempt to "import allmydata._version", but instead of does a
out-of-band open/read/grep. In setup.py and other build-time code, I'm
generally opposed to using "import XYZ; XYZ.__version__" to determining
somebody's version string, specifically because you can't unimport
anything. Instead, I prefer to grep a version out of a file with a
well-known-format (we generate _version.py so we control its format,
making it safe to grep), or to run a subprocess which does "import XYZ;
print XYZ.__version__" (which of course still assumes the __version__
convention).

Anyways, the problem with "setup.py --version" not working is because
this read-_version.py-and-grep code only gets run when you invoke the
"darcsver" command, and "setup.py --version" doesn't run any commands.

So my proposal for Tahoe is:

 1: setup.py should always start by attempting to read
    src/allmydata/_version.py and grep the version out of it. If this
    works, pass a version= argument into the setup() call, which will
    populate distribution.metadata.version and make everything work
    (including "setup.py --version", "setup.py --fullname", and
    "setup.py sdist")
 2: if the "darcsver" command is run, that will possibly regenerate
    _version.py and reset distribution.metadata.version to a new value

In general, you only run "darcsver" when you want to rebuild _version.py
. At all other times we should instead just use the most recently cached
value. Zooko modified the tahoe setup.cfg file to forcibly invoke
"darcsver" before most major commands for two reasons:

 1: to get a version string at all for commands like sdist (since
    without the always-read-_version.py approach proposed above, this
    was the only way to set distribution.metadata.version)

 2: to protect the user against confusion if they run darcsver, then
    pull a new patch or two (invalidating the version string), then run
    sdist: the tarball would be generated with the wrong version string.
    Basically setup.py has no way to magically tell that the source tree
    has been changed, so re-running darcsver all the time is the only
    way to make sure the version string is up-to-date.

My personal preference would be to leave tahoe.cfg empty and instruct
people to run "darcsver" before doing anything else, or to make setup.py
test for the existence of _version.py and invoke darcsver if it is
missing, because darcsver is rather disk-intensive and takes up to 10
seconds to run on my slow (FileVault encrypted) OS-X partition. But I
appreciate Zooko's concern#2, and have been personally bitten by the
out-of-date-version-string problem in the past. So tolerating slower
setup.py commands is a reasonable tradeoff to make.

It may still be an interesting-to-setuptools issue of how to best
modularize this proposed "read _version.py and run darcsver if
necessary" functionality. It seems to me that the setuptools plugin
mechanism is a good way to provide new commands (like "darcsver"), but
not a good way to persistently modify existing behavior, and that the
latter will always require not-very-modular customizations to a
package's setup.py .


cheers,
 -Brian

From h.goebel at goebel-consult.de  Mon Aug 17 13:54:50 2009
From: h.goebel at goebel-consult.de (Hartmut Goebel)
Date: Mon, 17 Aug 2009 13:54:50 +0200
Subject: [Distutils] Splitting distribute in several distributions
In-Reply-To: <4A828A9D.3010406@nextday.fi>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<4A828A2E.1080107@goebel-consult.de>
	<4A828A9D.3010406@nextday.fi>
Message-ID: <4A89450A.3060800@goebel-consult.de>

Alex Gr?nholm schrieb:

> Make sure you add an issue for this in the bug tracker, so it won't be
> forgotten by the time the code gets an overhaul.

Done.

-- 
Sch?nen Gru? - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP

Goebel Consult
Spezialist f?r IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Monatliche Kolumne:
<http://www.all-about-security.de/kolumnen/cissp-gefluester/>

Goebel Consult mit Mitglied bei <http://www.7-it.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4732 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090817/3030c8ca/attachment.bin>

From pje at telecommunity.com  Mon Aug 17 15:15:34 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 17 Aug 2009 09:15:34 -0400
Subject: [Distutils] Why is requiring version 0.0.1 when both 0.0.1 and
 0.0.2 are available a conflict?
In-Reply-To: <a30c43aa-f285-4fb1-b27f-79ddb5d5e145@d4g2000yqa.googlegrou
	ps.com>
References: <a30c43aa-f285-4fb1-b27f-79ddb5d5e145@d4g2000yqa.googlegroups.com>
Message-ID: <20090817131548.5108F3A4079@sparrow.telecommunity.com>

At 12:45 AM 8/17/2009 -0700, ryles wrote:
>Can someone explain what exactly the conflict is (I'm guessing
>pkg_resources is unhappy that 0.0.2 is already on sys.path)?

You guess correctly.

>I'd like for users to be able to explicitly use the older version if
>they're not yet comfortable with the new one. And a user just writing
>a simple script without wanting setuptools, or even simply trying
>something in the interactive interpreter, should be able to access the
>latest version without needing to know about pkg_resources.

Whichever version you install later will be the default in the 
interpreter, unless you use --multi-version.

Note, however, that a script whose setup.py requires a non-default 
version of the package will still work.  In other words, if you 
create another project with a setup.py that requires version 0.0.1, 
then upon installation that project's scripts will use 0.0.1, even 
though the interpreter's default will remain 0.0.2.


From pje at telecommunity.com  Mon Aug 17 15:32:25 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 17 Aug 2009 09:32:25 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
Message-ID: <20090817133239.D45B43A4079@sparrow.telecommunity.com>

At 09:34 AM 8/17/2009 +0200, Tarek Ziad? wrote:
>Right now the behavior of the code is:
>
>Distutils will take the setup.cfg options and apply them to the
>Distribution class,
>overriding any argument passed to setup(), then they will be in turn
>overriden by
>the command line options if any.
>
>This behavior seems fine.
>
>Now there's a very small change to make in distutils to make this work,
>wich consists of applying these values to the DistutilsMetadata
>object (the metadata attribute in the dist instance)
>
>I've changed this in my working trunk to give a try, and it works fine.

Are you doing this in setup(), Distribution.__init__, 
Distribution.parse_config_files(), Distribution.finalize_options(), 
or somewhere else?  I'm a bit concerned about backward compatibility, 
and integrating e.g. setup_requires.

One of the consequences of this approach would be that if setuptools 
tried to support setup_requires this way, it could end up running 
recursively by endlessly re-parsing the same configuration file, and 
then creating a new distribution to do the installation, which in 
turn would parse the config file and see a setup_requires, and so on.


From ziade.tarek at gmail.com  Mon Aug 17 15:52:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Aug 2009 15:52:59 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <20090817133239.D45B43A4079@sparrow.telecommunity.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<20090817133239.D45B43A4079@sparrow.telecommunity.com>
Message-ID: <94bdd2610908170652w6ab6408eh86e0e7ea70723e90@mail.gmail.com>

2009/8/17 P.J. Eby <pje at telecommunity.com>:
> At 09:34 AM 8/17/2009 +0200, Tarek Ziad? wrote:
>>
>> Right now the behavior of the code is:
>>
>> Distutils will take the setup.cfg options and apply them to the
>> Distribution class,
>> overriding any argument passed to setup(), then they will be in turn
>> overriden by
>> the command line options if any.
>>
>> This behavior seems fine.
>>
>> Now there's a very small change to make in distutils to make this work,
>> wich consists of applying these values to the DistutilsMetadata
>> object (the metadata attribute in the dist instance)
>>
>> I've changed this in my working trunk to give a try, and it works fine.
>
> Are you doing this in setup(), Distribution.__init__,
> Distribution.parse_config_files(), Distribution.finalize_options(), or
> somewhere else? ?I'm a bit concerned about backward compatibility, and
> integrating e.g. setup_requires.

I was thinking about doing it in parse_config_files(), after the files
are parsed
in the part where the "global" section is applied in the distribution object,
I've attached a diff of the dist.py if you want to take a look (that's
not the final
version but you get the idea)

>
> One of the consequences of this approach would be that if setuptools tried
> to support setup_requires this way, it could end up running recursively by
> endlessly re-parsing the same configuration file, and then creating a new
> distribution to do the installation, which in turn would parse the config
> file and see a setup_requires, and so on.

I am not sure to follow this case, would that be through fetch_build_egg ?

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

From ziade.tarek at gmail.com  Mon Aug 17 15:54:52 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Aug 2009 15:54:52 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908170652w6ab6408eh86e0e7ea70723e90@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<20090817133239.D45B43A4079@sparrow.telecommunity.com>
	<94bdd2610908170652w6ab6408eh86e0e7ea70723e90@mail.gmail.com>
Message-ID: <94bdd2610908170654o10c96a60q2484cee455dd3606@mail.gmail.com>

Did I attach the file  ?

From rylesny at gmail.com  Mon Aug 17 15:54:53 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 06:54:53 -0700 (PDT)
Subject: [Distutils] Why is requiring version 0.0.1 when both 0.0.1 and
	0.0.2 are available a conflict?
In-Reply-To: <20090817131548.5108F3A4079@sparrow.telecommunity.com>
References: <a30c43aa-f285-4fb1-b27f-79ddb5d5e145@d4g2000yqa.googlegroups.com>
	<20090817131548.5108F3A4079@sparrow.telecommunity.com>
Message-ID: <0b575a40-37f1-4589-8ac8-3e5dafe3a4d1@j9g2000vbp.googlegroups.com>



On Aug 17, 9:15?am, "P.J. Eby" <p... at telecommunity.com> wrote:
> Note, however, that a script whose setup.py requires a non-default
> version of the package will still work. ?In other words, if you
> create another project with a setup.py that requires version 0.0.1,
> then upon installation that project's scripts will use 0.0.1, even
> though the interpreter's default will remain 0.0.2.

Thanks. install_requires actually does seem to be working. I should
point out that if instead of install_requires you have setup_requires
(something I originally thought I needed, but now realize I don't),
then you will get the same VersionConflict exception shown above. Is
that intentional?

From ziade.tarek at gmail.com  Mon Aug 17 15:59:44 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Aug 2009 15:59:44 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908170654o10c96a60q2484cee455dd3606@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<20090817133239.D45B43A4079@sparrow.telecommunity.com>
	<94bdd2610908170652w6ab6408eh86e0e7ea70723e90@mail.gmail.com>
	<94bdd2610908170654o10c96a60q2484cee455dd3606@mail.gmail.com>
Message-ID: <94bdd2610908170659p503e746dx2bcc6cd3cd8b6dba@mail.gmail.com>

Here we go

On Mon, Aug 17, 2009 at 3:54 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> Did I attach the file ??
>



-- 
Tarek Ziad? | http://ziade.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: site.diff
Type: application/octet-stream
Size: 1330 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090817/d3933442/attachment.obj>

From rylesny at gmail.com  Mon Aug 17 16:13:46 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 07:13:46 -0700 (PDT)
Subject: [Distutils] setup.py develop is not locating install_requires
	packages in custom site dir
Message-ID: <6daf7ba8-e2d6-432e-8251-462458021ec5@r24g2000vbn.googlegroups.com>

I have a package, 'proj', which specifies a dependency on 'mypkg',
version 0.0.2


$ cat setup.py
from setuptools import find_packages, setup

setup(name = "proj",
      version = "0.0.1",
      platforms = ["linux2"],
      packages = find_packages(),
      zip_safe = False,
      install_requires=["mypkg==0.0.2"],
      entry_points = {"console_scripts": ["proj = proj.main:main"]},
     )

I have been able to successfully easy_install an egg created with
setup.py bdist_egg, and the 'proj' entry point successfully `requires'
mypkg 0.0.2.

However, setup.py develop is not able to find mypkg. I am installing
it into the user site dir so that it's private during development,
rather than in my system wide /custom/site-packages directory:

$ python setup.py develop --install-dir ~/.local/lib/python2.6/site-
packages --script-dir ~/bin --allow-hosts localhost
running develop
Checking .pth file support in /home/user/.local/lib/python2.6/site-
packages
/custom/bin/python -E -c pass
TEST PASSED: /home/user/.local/lib/python2.6/site-packages appears to
support .pth files
running egg_info
creating proj.egg-info
writing requirements to proj.egg-info/requires.txt
writing proj.egg-info/PKG-INFO
writing top-level names to proj.egg-info/top_level.txt
writing dependency_links to proj.egg-info/dependency_links.txt
writing entry points to proj.egg-info/entry_points.txt
writing manifest file 'proj.egg-info/SOURCES.txt'
reading manifest file 'proj.egg-info/SOURCES.txt'
writing manifest file 'proj.egg-info/SOURCES.txt'
running build_ext
Creating /home/user/.local/lib/python2.6/site-packages/proj.egg-link
(link to .)
Adding proj 0.0.1 to easy-install.pth file
Installing proj script to /home/user/bin

Installed /path/to/proj
Processing dependencies for proj==0.0.1
Searching for mypkg==0.0.2

Link to http://pypi.python.org/simple/mypkg/ ***BLOCKED*** by --allow-
hosts

Couldn't find index page for 'myproj' (maybe misspelled?)
Scanning index of all packages (this may take a while)

Link to http://pypi.python.org/simple/ ***BLOCKED*** by --allow-hosts

No local packages or download links found for mypkg==0.0.2
error: Could not find suitable distribution for Requirement.parse
('mypkg==0.0.2')

pkg_resources.require() has no trouble finding it, however.

$ python
Python 2.6.2 (r262:71600, Jul 16 2009, 14:04:28)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import require
>>> require("mypkg==0.0.2")
[mypkg 0.0.2 (/custom/site-packages/mypkg-0.0.2-py2.6.egg)]
>>> import mypkg
>>>

The problem is fixed if I explicitly tell setuptools that /custom/site-
packages is
a site directory with --site-dirs, but it's unclear why this should be
necessary since that directory is already in sys.path. Note that /
custom/site-packages was created by following the instructions here:
http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation

From rylesny at gmail.com  Mon Aug 17 16:46:50 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 07:46:50 -0700 (PDT)
Subject: [Distutils] setup.py develop is not locating install_requires
	packages in custom site dir
In-Reply-To: <6daf7ba8-e2d6-432e-8251-462458021ec5@r24g2000vbn.googlegroups.com>
References: <6daf7ba8-e2d6-432e-8251-462458021ec5@r24g2000vbn.googlegroups.com>
Message-ID: <533a10fb-7c86-45a3-b0b8-b911702a778f@g1g2000vbr.googlegroups.com>

A related question: mypkg comes with several scripts which I'm not
interested in using for this project. However, because the mypkg
location (/custom/site-packages, /custom/bin) differs from the
development location ~/.local/lib/python.2-6/site-packages, ~/bin),
setuptools is copying all of the mypkg scripts to ~/bin. Since I don't
actually need any of these is there any way to disable this? I still
want the scripts / console_scripts associated with 'proj', however.
It's especially inconvenient since running setup.py develop --
uninstall will not remove them.

From rylesny at gmail.com  Mon Aug 17 16:52:35 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 07:52:35 -0700 (PDT)
Subject: [Distutils] setup.py develop is not locating install_requires
	packages in custom site dir
In-Reply-To: <533a10fb-7c86-45a3-b0b8-b911702a778f@g1g2000vbr.googlegroups.com>
References: <6daf7ba8-e2d6-432e-8251-462458021ec5@r24g2000vbn.googlegroups.com>
	<533a10fb-7c86-45a3-b0b8-b911702a778f@g1g2000vbr.googlegroups.com>
Message-ID: <bc88cdc9-7162-40ae-ba74-d9788ddd0ed1@d4g2000vbm.googlegroups.com>

On Aug 17, 10:46?am, ryles <ryle... at gmail.com> wrote:
> A related question: mypkg comes with several scripts which I'm not
> interested in using for this project. However, because the mypkg
> location (/custom/site-packages, /custom/bin) differs from the
> development location ~/.local/lib/python.2-6/site-packages, ~/bin),
> setuptools is copying all of the mypkg scripts to ~/bin. Since I don't
> actually need any of these is there any way to disable this? I still
> want the scripts / console_scripts associated with 'proj', however.
> It's especially inconvenient since running setup.py develop --
> uninstall will not remove them.

I also noted that while setup.py develop --uninstall will remove
'proj' from ~/.local/lib/python.2-6/site-packages/easy-install.pth,
mypkg will remain there. I suppose this is intentional since
setuptools
is uncertain if any other package is still dependent on having it
there.

I wonder if it would be worth it to add an option to force cleanup of
these things.

From chris at simplistix.co.uk  Mon Aug 17 17:09:31 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 17 Aug 2009 16:09:31 +0100
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
	<69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>
Message-ID: <4A8972AB.8040106@simplistix.co.uk>

David Lyon wrote:
> We must resist the option to nest (against unnecessary complexity). 
> ConfigParser does lists easily so you can store a list of files 
> extremely easily.

Cool, what's the format for lists?

> It also does free form text (descriptions).

And for this?

> For me, that only leaves the choice of a filename.. 
> 
>  - setup.info
> 
>  - setup.conf
> 
>  - others..?

...is entirely up to the package developer. We can suggest whatever, but 
since it'll be called from setup.py, we can't do anything other than 
suggest a sensible default that will work with the tools that will 
hopefully show up that only parse the static file...

> Having a setup.py and a setup.info to me seems simple and
> straightforward. It's easier to understand than having all
> the metadata 'hardcoded' in a program (as "cute" as that is).

For some packages (see lxml for example) it's not cute but a necessity 
to figure out how to build their extensions properly...

cheers,

Chris

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

From ronaldoussoren at mac.com  Mon Aug 17 17:23:14 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 17 Aug 2009 17:23:14 +0200
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <4A8972AB.8040106@simplistix.co.uk>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
	<69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>
	<4A8972AB.8040106@simplistix.co.uk>
Message-ID: <51168057981425037026125491951089776772-Webmail@me.com>

 
On Monday, 17 August, 2009, at 05:09PM, "Chris Withers" <chris at simplistix.co.uk> wrote:

>
>> For me, that only leaves the choice of a filename.. 
>> 
>>  - setup.info
>> 
>>  - setup.conf
>> 
>>  - others..?
>
>...is entirely up to the package developer. We can suggest whatever, but 
>since it'll be called from setup.py, we can't do anything other than 
>suggest a sensible default that will work with the tools that will 
>hopefully show up that only parse the static file...

We already have 'setup.cfg', what's wrong with that?  If another filename is needed: please pick one where the suffix is unique, that would make it easier to associate the file with specific programs (double-click to open, spotlight/quicklook helpers on OSX, ...)

Ronald


From david.lyon at preisshare.net  Mon Aug 17 17:23:43 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 11:23:43 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <4A8972AB.8040106@simplistix.co.uk>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>	<op.uyiw50r1brrvlq@double>	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>	<op.uyiye7xibrrvlq@double>	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
	<69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>
	<4A8972AB.8040106@simplistix.co.uk>
Message-ID: <363d43c305ea600a66e83cac873b84a4@preisshare.net>

On Mon, 17 Aug 2009 16:09:31 +0100, Chris Withers <chris at simplistix.co.uk>
wrote:
>> We must resist the option to nest (against unnecessary complexity). 
>> ConfigParser does lists easily so you can store a list of files 
>> extremely easily.
> 
> Cool, what's the format for lists?

If there isn't a built in format for lists, you can simulate it
by numbering items. Eg:

[InstallableFiles]
file1 = abc.txt
file2 = def.txt
..etc..

>> It also does free form text (descriptions).
> 
> And for this?

>From my observations it seems to tabulate the first column. Eg:

[PackageMetadata]
description = This package converts popular tv soap operas
        into something that is readily viewable on your
        python powered mobile phone.


>> For me, that only leaves the choice of a filename.. 
>> 
>>  - setup.info
>> 
>>  - setup.conf
>> 
>>  - others..?
> 
> ...is entirely up to the package developer. We can suggest whatever, but 
> since it'll be called from setup.py, we can't do anything other than 
> suggest a sensible default that will work with the tools that will 
> hopefully show up that only parse the static file...

My idea was to have the distutils "setup()" read the data from the 
config file. Defaulting to a particular file with a particular name.

Since we have a convention for setup.py, adding the convention for
a particular 'setup.info'/'setup.xml'/'package.setup' doesn't seem to
me to be a difficult ask. As long as it has 'setup' included somewhere
in the filename.

>> Having a setup.py and a setup.info to me seems simple and
>> straightforward. It's easier to understand than having all
>> the metadata 'hardcoded' in a program (as "cute" as that is).
> 
> For some packages (see lxml for example) it's not cute but a necessity 
> to figure out how to build their extensions properly...

ok - I'll check it out.

David

From david.lyon at preisshare.net  Mon Aug 17 17:26:34 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 11:26:34 -0400
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <51168057981425037026125491951089776772-Webmail@me.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<op.uyiw50r1brrvlq@double>
	<94bdd2610908111744o74c6e9c7o3f991ef747035d8c@mail.gmail.com>
	<op.uyiye7xibrrvlq@double>
	<94bdd2610908120135l2627fafama526ec6ae4d59ad9@mail.gmail.com>
	<7E939611-A444-4A05-9D53-7F76D872FB9B@python.org>
	<5cae42b20908120531s5fcf8cd1w62a8ab6b0cbf3bd8@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
	<69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>
	<4A8972AB.8040106@simplistix.co.uk>
	<51168057981425037026125491951089776772-Webmail@me.com>
Message-ID: <403cd4d243ea8a627aa7585ee1d83557@preisshare.net>

On Mon, 17 Aug 2009 17:23:14 +0200, Ronald Oussoren
<ronaldoussoren at mac.com>
wrote:

> We already have 'setup.cfg', what's wrong with that?  

Only that the metadata file needs to be 'transmitted' along-with/inside
the package. As such it isn't a config file as such.

My apologies for being pedantic, but setup.cfg has other information
that you want to keep on your machine.

> If another filename
> is needed: please pick one where the suffix is unique, that would make it
> easier to associate the file with specific programs (double-click to
open,
> spotlight/quicklook helpers on OSX, ...)

Exactly.

David

From david.lyon at preisshare.net  Mon Aug 17 17:39:18 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 11:39:18 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
Message-ID: <aa030340d3d05b66b14aa22eabade5b7@preisshare.net>

On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> Now for the name of the file, I wouldn't want yet another file since
> we already have
> setup.cfg and since it can be extended w/o any problem or bacward
> compatibility issue.

The only issue here is that the "new" setup.metadata file that gets
sent to pypi won't contain all the private build stuff that is in
the developers setup.cfg file.

As I understand and correct me if I'm wrong, but there's all sorts
of options that you can build in for all the different platforms.

The developer won't want all the (irrelevent) stuff sent out..

> I am also realizing that we can use it to describe "static metadata"
> almost with the
> existing distutils code.

Yes. I would agree with that.

> We can use the [global] section of the setup.cfg file to describe them.

Yes.

> If we want to remove all metadata expressed as setup() arguments, we
> can just move them
> to the setup.cfg.

Yes, good thinking.

> 
> example of setup.cfg file:
> 
> """
> [global]
> name: foo
> version: 1.0
> author: tarek
> long_description: some
>   long description
>   here
> 
> url: http://example.com
> """
> 
> What's left in setup.py :
> 
> """
> from distutils.core import setup
> 
> setup()
> """
> 

Exactly, that's how simple it should be.

> I've changed this in my working trunk to give a try, and it works fine.
> 
> the long_description field is expressed as a multi-line field following
> the config parser convention so no problem for it (see my example)

Yes.

> Although there's another change we need to apply and decide : being
> able to express a
> list of values, for fields like "keywords" or "classifiers".

[Files]
file1 = abc.txt
file2 = def.txt

You can get all the keys in "[Files]" in a list in the configparser
class.

> Any thoughts ?

You are having good thoughts...

David


From ziade.tarek at gmail.com  Mon Aug 17 17:44:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Aug 2009 17:44:25 +0200
Subject: [Distutils] Splitting metadata from setup.py in distutils..
In-Reply-To: <51168057981425037026125491951089776772-Webmail@me.com>
References: <94bdd2610908111530n2bc7faeclca7a86a869919d46@mail.gmail.com>
	<94bdd2610908121458n3ad3175bv647c41ee027e2514@mail.gmail.com>
	<212BF589-C56E-4C55-BB70-B545B41441BD@python.org>
	<94bdd2610908121513r71edd812u103d6b2bce6158cc@mail.gmail.com>
	<0eea566be7aff928cdae23beea7ca043@preisshare.net>
	<079C3254-87F5-4BCA-9544-ABFC0DDE2C6A@python.org>
	<4A86D038.8050005@simplistix.co.uk>
	<69e40aeb0ee4352c17acc73af8b0fd63@preisshare.net>
	<4A8972AB.8040106@simplistix.co.uk>
	<51168057981425037026125491951089776772-Webmail@me.com>
Message-ID: <94bdd2610908170844g7af8208di2a3a6e34efc3428f@mail.gmail.com>

On Mon, Aug 17, 2009 at 5:23 PM, Ronald Oussoren<ronaldoussoren at mac.com> wrote:
>
> On Monday, 17 August, 2009, at 05:09PM, "Chris Withers" <chris at simplistix.co.uk> wrote:
>
>>
>>> For me, that only leaves the choice of a filename..
>>>
>>> ?- setup.info
>>>
>>> ?- setup.conf
>>>
>>> ?- others..?
>>
>>...is entirely up to the package developer. We can suggest whatever, but
>>since it'll be called from setup.py, we can't do anything other than
>>suggest a sensible default that will work with the tools that will
>>hopefully show up that only parse the static file...
>
> We already have 'setup.cfg', what's wrong with that? ?If another filename is needed: please pick one where the suffix is unique, that would make it easier to associate the file with specific programs (double-click to open, spotlight/quicklook helpers on OSX, ...)

Yes please, have a look at my mail on this (next thread)
I don't see why we would have another file

From sridharr at activestate.com  Mon Aug 17 22:09:40 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 17 Aug 2009 13:09:40 -0700
Subject: [Distutils] [setuptools] conditionally installing scripts based on
	extras require
Message-ID: <op.uytoye1l1q4jlt@whymac>

I have a setup.py like this:

    [...]
    extras_require = {'foo': 'pkginfo'},
    [...]
    entry_points = {'console_scripts': [
      'bar=myapp.bar:main',
      'foo=myapp.foo:main [foo]',
    ]}
    [...]

When I do a 'python setup.py install', the package 'pkginfo' is *not*  
installed as expected. However, the script 'foo' *is* installed. This is  
somewhat ironic .. because `foo' as per the definition depends on the  
'foo' feature; yet installing 'myapp' (without 'foo' feature) installs the  
script 'foo'.

1) What is the rationale behind this behavior? setuptools documentation  
reads: "[...] if Project A includes a "rst2pdf" script, it might declare  
it like this, so that the "PDF" requirements are only resolved if the  
"rst2pdf" script is run". Why install a script if the user installed a  
distribution without a particular feature that this script depends on?

2) Is there a workaround to tell setuptools *not* to install scripts  
depending on features not asked for?

-srid

From david.lyon at preisshare.net  Tue Aug 18 02:22:51 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 20:22:51 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
Message-ID: <531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>

On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> We can use the [global] section of the setup.cfg file to describe them.

My suggestion is [setup] because it directly corresponds to the setup()
function. I know it is a triplication of the name (setup.cfg, setup()
and then [setup]) but it's much more consistent and will be easier to
find for new users.

[setup]
name: foo
version: 1.0
author: tarek
long_description: some
  long description
  here
 
url: http://example.com

And then...

> """
> from distutils.core import setup
> 
> setup()
> """

That's all that it should be (for now... evil grin.. :-)

In a commercial level app you always need to do extra
stuff. If we can't do this now then fine.. later..

But it needs to be pointed out that these things are
somewhat mandatory for python applications, not
necessarily packages.

"""
from distutils.core import setup
 
preinstall()  # Read current environment and adjust
              # installation.. twiddle directory locations
              # and perphaps make choices dependent on 
              # environment KDE/Gnome/Windows/Mac

setup()       # run the distutils function

postinstall() # Now generate the documentation, register
              # .dll files, update environment, create
              # window manager shortcuts etc

Regards

David



From sridharr at activestate.com  Tue Aug 18 03:21:15 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 17 Aug 2009 18:21:15 -0700
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
Message-ID: <op.uyt3dpre1q4jlt@whymac>

On Mon, 17 Aug 2009 17:22:51 -0700, David Lyon <david.lyon at preisshare.net>  
wrote:

> [setup]
> name: foo
> version: 1.0
> author: tarek
> long_description: some
>   long description
>   here

More often developers may want to assign the contents of README.txt to the  
`long_description` field. I have seen setup.py's that simply do:

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

If one is to use setup.cfg, how would this particular case be handled?  
Override `long_description` in setup.py .. or provide a Config variable  
($README)?

-srid

From rylesny at gmail.com  Tue Aug 18 03:43:56 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 17 Aug 2009 18:43:56 -0700 (PDT)
Subject: [Distutils] Make easy_install script updates atomic / allow in
	multi-user env
Message-ID: <7682843f-bfbb-4a73-904b-62ae3c761d34@l35g2000vba.googlegroups.com>

In setuptools/command/easy_install.py, easy_install.write_script is
the method called to install each of a package's scripts. It contains
the following:

f = open(target,"w"+mode)
f.write(contents)
f.close()
chmod(target,0755)

opening the file with "w" will cause it to truncate, and then there is
a race between the open and the write. Further, due to buffering there
is even no guarantee that a user will see either an empty or complete
version of the script during this time. It should be safer to instead
write to a temporary file and then use shutil.move, which, on Unix-
like systems at least, will call rename() (i.e. what /bin/mv would
do). renaming is atomic and allows the old version to remain in tact
(anonymously) if any process had it open for reading, and also ensures
that no process will see an incomplete version.


The above code can also create problems in a multi-user environment.

chmod() is inflexibly giving only the owner write access. The author
may have purposely given the script (the original non-wrapper version,
at least) group write access so that other developers could install
newer versions of the package at a later time. The chmod() call blocks
this attempt.

More importantly, directory permissions are ignored. That is, even if
the script itself is not writable (necessarily true with the current
code), its parent directory may purposely be writable so that newer
versions can be added. Using shutl.move will address this since it
operates on the directory and not the file itself. This is arguable
the correct semantics anyway: "install a new version of the script",
not "edit the existing script".

From alex.gronholm at nextday.fi  Tue Aug 18 04:11:28 2009
From: alex.gronholm at nextday.fi (=?UTF-8?B?QWxleCBHcsO2bmhvbG0=?=)
Date: Tue, 18 Aug 2009 05:11:28 +0300
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
Message-ID: <4A8A0DD0.8020101@nextday.fi>

David Lyon kirjoitti:
> On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>   
>> We can use the [global] section of the setup.cfg file to describe them.
>>     
>
> My suggestion is [setup] because it directly corresponds to the setup()
> function. I know it is a triplication of the name (setup.cfg, setup()
> and then [setup]) but it's much more consistent and will be easier to
> find for new users.
>
> [setup]
> name: foo
> version: 1.0
> author: tarek
> long_description: some
>   long description
>   here
>  
> url: http://example.com
>
> And then...
>
>   
How would you declare dependencies? Remember that the list of 
dependencies depends on at least two variables: Python version and platform.
>> """
>> from distutils.core import setup
>>
>> setup()
>> """
>>     
>
> That's all that it should be (for now... evil grin.. :-)
>
> In a commercial level app you always need to do extra
> stuff. If we can't do this now then fine.. later..
>
> But it needs to be pointed out that these things are
> somewhat mandatory for python applications, not
> necessarily packages.
>
> """
> from distutils.core import setup
>  
> preinstall()  # Read current environment and adjust
>               # installation.. twiddle directory locations
>               # and perphaps make choices dependent on 
>               # environment KDE/Gnome/Windows/Mac
>
> setup()       # run the distutils function
>
> postinstall() # Now generate the documentation, register
>               # .dll files, update environment, create
>               # window manager shortcuts etc
>
> Regards
>
> David
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090818/57cd3c61/attachment-0001.htm>

From david.lyon at preisshare.net  Tue Aug 18 04:41:41 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 22:41:41 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <op.uyt3dpre1q4jlt@whymac>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<op.uyt3dpre1q4jlt@whymac>
Message-ID: <f8ea2c07b7ec071b48a3c21b7ca118dd@preisshare.net>

On Mon, 17 Aug 2009 18:21:15 -0700, "Sridhar Ratnakumar"
<sridharr at activestate.com> wrote:
> More often developers may want to assign the contents of README.txt to
the 
> 
> `long_description` field. I have seen setup.py's that simply do:
> 
>    long_description = open('README.txt').read()

Perphaps:

[setup]
name: foo
version: 1.0
author: tarek
long_description_file: README.txt

> If one is to use setup.cfg, how would this particular case be handled?  
> Override `long_description` in setup.py .. 

Perphaps. 

> or provide a Config variable  ($README)?

I'm not keen on that because I don't fully understand it. I think
the first option should be clear enough.

David




From david.lyon at preisshare.net  Tue Aug 18 04:51:28 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 22:51:28 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A8A0DD0.8020101@nextday.fi>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A8A0DD0.8020101@nextday.fi>
Message-ID: <ada993177ecacb65f348f3ff86b3be5b@preisshare.net>

On Tue, 18 Aug 2009 05:11:28 +0300, Alex Gr?nholm
<alex.gronholm at nextday.fi> wrote:

> How would you declare dependencies? Remember that the list of 
> dependencies depends on at least two variables: Python version and
> platform.

hmm.. they're the most important of all...

Perphaps...

"""
[setup]
name: foo
version: 1.0
author: tarek
long_description: some
  long description
  here

url: http://example.com

[dependencies]
dependency1=numpy,>X.Y
dependency2=lxml,E.F

[dependency_linux2_python2.5]
dependency1=gtkwinhelper,>S.T

[dependency_mac_python2.4]
dependency1=hotplug
"""

The operating system name should match one of the
os.name() or sys.platform() functions.. 

David


From david.lyon at preisshare.net  Tue Aug 18 05:20:52 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 17 Aug 2009 23:20:52 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A8A1AB5.1040204@nextday.fi>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A8A0DD0.8020101@nextday.fi>
	<ada993177ecacb65f348f3ff86b3be5b@preisshare.net>
	<4A8A1AB5.1040204@nextday.fi>
Message-ID: <f9a4af415d6410b0055632daac04b6a3@preisshare.net>

On Tue, 18 Aug 2009 06:06:29 +0300, Alex Gr?nholm
<alex.gronholm at nextday.fi> wrote:
   
> That scheme does not allow me to say "This dependency is required unless 
> platform is X". A practical example of this is Beaker, where pycryptopp 
> is required for cookie encryption, but works without external 
> dependencies on Jython.

Yes, I follow..

That's why I'm so keen on having a pre_setup() and a post_setup()
user routine, where the environment and dependencies can be exposed.

I can't see any easy way to do conditional logic in a config file.

imho it just has to go in code.. and it is as simple as that - haha

for example (demonstration code - not runnable):

"""
from distutils.core import setup

def pre_setup():
    if sys.platform() == "linux2":
        self.dependencies.append("pycryptopp")
    return

setup()
"""

So, one could modify the dependencies dynamically based
on the underlying platform.

Dependencies is a list of packages within the setup class. So
the user can add or remove items before the actual setup() is
done.

> Also, how do I define that this package has a minimum (or maximum) 
> required Python version?

[Python_versions]
minimum_supported=2.3
maximum_supported=2.7

We can't tell a user it won't work - only that it isn't supported.

> Or that the distribution is only applicable to a certain platform (say, 
> win32 or java)?

[Platforms]
supported1=linux2
supported2=mac
supported3=win32,win64

I think we can let the developer specify what *is* supported, and if it
doesn't 
match then give the user the choice to proceed or not. (At their own risk)

David


From floris.bruynooghe at gmail.com  Tue Aug 18 09:08:17 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 18 Aug 2009 08:08:17 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A8A0DD0.8020101@nextday.fi>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A8A0DD0.8020101@nextday.fi>
Message-ID: <20090818070817.GA8134@laurie.devork>

On Tue, Aug 18, 2009 at 05:11:28AM +0300, Alex Gr?nholm wrote:
> How would you declare dependencies? Remember that the list of
> dependencies depends on at least two variables: Python version and
> platform.

Many more, defining a known list of variables to be used to define
dependencies is not going to be enough.  Maybe there should be a way
of having general purpose named conditionals and implement a mapping
so that setup.py can define boolean functions for each named
conditional.  This can then be used for modules etc too instead of
just dependencies.

The benefit is that you allow developers to specify anything possible,
but still allow package management systems to analyse the
dependencies and modules etc from static data.  They will recognise
that something is conditional but are free to do with that knowledge
they want.

Expressiong conditionals in an elegant-ConfigParser-compatible way
might be tricky.

Regards
Floris

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

From ronaldoussoren at mac.com  Tue Aug 18 09:48:58 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 18 Aug 2009 09:48:58 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <20090818070817.GA8134@laurie.devork>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A8A0DD0.8020101@nextday.fi> <20090818070817.GA8134@laurie.devork>
Message-ID: <93624EF4-0EFA-42D0-9141-CFBD239E2452@mac.com>


On 18 Aug, 2009, at 9:08, Floris Bruynooghe wrote:

> On Tue, Aug 18, 2009 at 05:11:28AM +0300, Alex Gr?nholm wrote:
>> How would you declare dependencies? Remember that the list of
>> dependencies depends on at least two variables: Python version and
>> platform.
>
> Many more, defining a known list of variables to be used to define
> dependencies is not going to be enough.  Maybe there should be a way
> of having general purpose named conditionals and implement a mapping
> so that setup.py can define boolean functions for each named
> conditional.  This can then be used for modules etc too instead of
> just dependencies.
>
> The benefit is that you allow developers to specify anything possible,
> but still allow package management systems to analyse the
> dependencies and modules etc from static data.  They will recognise
> that something is conditional but are free to do with that knowledge
> they want.
>
> Expressiong conditionals in an elegant-ConfigParser-compatible way
> might be tricky.

Wouldn't it be good enough to just have the most common use-cases in  
setup.cfg? The user can still add code to setup.py to tweak the  
default behaviour when the project does something non-standard.

BTW. One way to do conditionals in ConfigParser files might be:

[dependencies.os9]
use-when:   python>=2.7, platform=='macos9'
require:   unix-toolbox>=2.5

[dependencies.suse]
use-when: file_exists('/etc/SuSE-release')
require: ...

That is, use a config-key in dependency blocks that describes when the  
block should be used. The bit after the '.' in de section-name would  
be ignored by distutils and would basicly be comment.

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/20090818/4d595088/attachment.bin>

From jeff at taupro.com  Tue Aug 18 10:03:57 2009
From: jeff at taupro.com (Jeff Rush)
Date: Tue, 18 Aug 2009 03:03:57 -0500
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
Message-ID: <4A8A606D.6090306@taupro.com>

David Lyon wrote:
> On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>> the long_description field is expressed as a multi-line field following
>> the config parser convention so no problem for it (see my example)

The long_description field is also a reStructuredText field and as such,
for the developer to preview it during its composure, it needs to be
left-aligned.  While a developer -could- cut/paste it into a separate
text file each time he wants to test preview it, that would be annoying.


>> Although there's another change we need to apply and decide : being
>> able to express a
>> list of values, for fields like "keywords" or "classifiers".
> 
> [Files]
> file1 = abc.txt
> file2 = def.txt
> 
> You can get all the keys in "[Files]" in a list in the configparser
> class.

Many of these ideas have already been expressed in a buildout.cfg file
that also uses ConfigParser.  Look there for ideas on how to do lists,
order things, substitute fields.  However if you put too much expressive
power into the metadata file, you make it hard to programatically reason
about what is means, which is the whole point of having a static
metadata file.  If you put too little, people will stick with setup.py.

-Jeff

From ben+python at benfinney.id.au  Tue Aug 18 11:47:10 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 18 Aug 2009 19:47:10 +1000
Subject: [Distutils] Static metadata using setup.cfg
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
Message-ID: <87my5xihcx.fsf@benfinney.id.au>

Jeff Rush <jeff at taupro.com> writes:

> The long_description field is also a reStructuredText field and as
> such, for the developer to preview it during its composure, it needs
> to be left-aligned. While a developer -could- cut/paste it into a
> separate text file each time he wants to test preview it, that would
> be annoying.

I get my ?description? and ?long_description? field not directly from a
text file, but from the package docstring. Following the usual docstring
interpretation conventions as per PEP 257, I trim all common leading
indentation from non-blank lines:

    import textwrap
    import foopackage

    short_description, long_description = (
        textwrap.dedent(d).strip()
        for d in main_module.__doc__.split('\n\n', 1))

If we want to allow a multi-line option value in a configuration file,
we could define the interpretation of that value by the same or similar
convention.

-- 
 \       ?Well, my brother says Hello. So, hooray for speech therapy.? |
  `\                                                      ?Emo Philips |
_o__)                                                                  |
Ben Finney


From david.lyon at preisshare.net  Tue Aug 18 13:02:54 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 18 Aug 2009 07:02:54 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A8A606D.6090306@taupro.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
Message-ID: <0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>

On Tue, 18 Aug 2009 03:03:57 -0500, Jeff Rush <jeff at taupro.com> wrote:
> David Lyon wrote:
>>> the long_description field is expressed as a multi-line field following
>>> the config parser convention so no problem for it (see my example)
> 
> The long_description field is also a reStructuredText field and as such,
> for the developer to preview it during its composure, it needs to be
> left-aligned.  While a developer -could- cut/paste it into a separate
> text file each time he wants to test preview it, that would be annoying.

ok - well not much can be done to eliminate the classic ID10t error..

and wth is that guy doing? editing the file without emacs... serves
him right (doesn't emacs fix everything?) :-)

Normal users would edit the text imho with a text boxt. The congigparser
takes care of adjusting everything up. I'm operating on the assumption
that there's a "util" to edit the file somewhere in distutils..

> Many of these ideas have already been expressed in a buildout.cfg file
> that also uses ConfigParser.  Look there for ideas on how to do lists,
> order things, substitute fields.

If I get time...

I'm just bashing this stuff out as I go along.. and there's probably
some way of improving most everything I suggest. I'm not an 'old'
python hack.. I'm still learning..

>  However if you put too much expressive
> power into the metadata file, you make it hard to programatically reason
> about what is means, which is the whole point of having a static
> metadata file.  

That's why we need to keep it simple. Handle 85% of use cases with
config and the other 15% with the ability to use (python) code.

David



From eric at trueblade.com  Tue Aug 18 13:26:33 2009
From: eric at trueblade.com (Eric Smith)
Date: Tue, 18 Aug 2009 07:26:33 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
Message-ID: <4A8A8FE9.6070905@trueblade.com>

David Lyon wrote:
> That's why we need to keep it simple. Handle 85% of use cases with
> config and the other 15% with the ability to use (python) code.

The part that needs to by "code-like" is only the stuff that's needed 
when the config file is used by an installer, and is known only to the 
target system. Remember one of the points of having a static file (as we 
discussed at the language summit) is so that installers can install a 
"module distribution" (distutils term) without executing any python code.

So version dependencies might need to be code-like, per-python-version 
dependencies might also need to be. But the long description doesn't. If 
you want it to be read from some other file, use a script (possibly in a 
makefile) that generates the config file from various pieces.

I think these things that need to be code-like are things that depend on 
the target system and can't be known until an actual installation takes 
place. The rest of it can be truly static. I think this list of 
code-like things can and should be enumerated, and should be very small.

Ideally, they'd be translatable into the same sorts of expressions that 
are understood by rpm and deb (and other) installers, but that's a tall 
order.

Eric.


From pje at telecommunity.com  Tue Aug 18 17:08:46 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 18 Aug 2009 11:08:46 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <20090818070817.GA8134@laurie.devork>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A8A0DD0.8020101@nextday.fi> <20090818070817.GA8134@laurie.devork>
Message-ID: <20090818150903.5176A3A4079@sparrow.telecommunity.com>

At 08:08 AM 8/18/2009 +0100, Floris Bruynooghe wrote:
>The benefit is that you allow developers to specify anything possible,
>but still allow package management systems to analyse the
>dependencies and modules etc from static data.  They will recognise
>that something is conditional but are free to do with that knowledge
>they want.

In which case, why not simply have a "configure"-like command that 
generates a fixed set of static metadata?

Or better yet, make it "configure.py" or something like that.  Since 
it is not the old setup.py, it does not have to offer the same 
command line interface or be backward compatible with existing code.


From ziade.tarek at gmail.com  Tue Aug 18 18:32:09 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 18 Aug 2009 18:32:09 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A8A8FE9.6070905@trueblade.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
	<0b8f78d03f5dfdeba987ef233b2ae8eb@preisshare.net>
	<4A8A8FE9.6070905@trueblade.com>
Message-ID: <94bdd2610908180932te51f49byc9f3938c29a0c100@mail.gmail.com>

On Tue, Aug 18, 2009 at 1:26 PM, Eric Smith<eric at trueblade.com> wrote:
> David Lyon wrote:
>>
>> That's why we need to keep it simple. Handle 85% of use cases with
>> config and the other 15% with the ability to use (python) code.
>
> The part that needs to by "code-like" is only the stuff that's needed when
> the config file is used by an installer, and is known only to the target
> system. Remember one of the points of having a static file (as we discussed
> at the language summit) is so that installers can install a "module
> distribution" (distutils term) without executing any python code.
>
> So version dependencies might need to be code-like, per-python-version
> dependencies might also need to be. But the long description doesn't. If you
> want it to be read from some other file, use a script (possibly in a
> makefile) that generates the config file from various pieces.
>
> I think these things that need to be code-like are things that depend on the
> target system and can't be known until an actual installation takes place.
> The rest of it can be truly static. I think this list of code-like things
> can and should be enumerated, and should be very small.
>
> Ideally, they'd be translatable into the same sorts of expressions that are
> understood by rpm and deb (and other) installers, but that's a tall order.

What about a fully static setup.cfg file, and a template file called
setup.cfg.in,
working like MANIFEST and MANIFEST.in

A -  From the developer PoV:

1. the developer doesn't have metadata that depend on the target
system, he provides a static setup.cfg

2. the developer does have metadata that depend on the target system,
he provides a setup.cfg.in
    that can be processed by distutils to generate a setup.cfg file

The setup.cfg.in file would then have expressions ala automake, that
could be used to
generate the setup.cfg.

When distributions are made, a default setup.cfg is generated in case
a setup.cfg.in is found,
and it's updated when installed on the target system.

The execution environment will contain a restricted list of functions
to query the environment,
provided by distutils, to make conditional statements in the file.

- sys.platform
- os.name
- python version
- others ?

The advantages of a ".in" file is that we don't have to stick with the
ConfigParser format
and enjoy conditional sections. Plus, it's a hint to know that the
dsitribution installation
differs depending on the patform.

B - From the OS packager PoV:

1. he sees a setup.cfg.in file, he knows that the distribution has os
specific metadata.
   he tweaks the setup.cfg.in file and re-generate the setup.cfg.

2. he uses setup.cfg when provided alone

C - From PyPI user PoV

Both setup.cfg and setup.cfg.in files are uploaded besides the
archive, allowing people to get the static
metadata for their platform without having to dowload and install the
whole distribution.

This will work as long as the expressions are restricted to something
that can be run on a vanilla Python.

For the template file syntax, a simple "if" would be sufficient to
allow conditional parts in the template


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

From ziade.tarek at gmail.com  Tue Aug 18 18:42:18 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 18 Aug 2009 18:42:18 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <87my5xihcx.fsf@benfinney.id.au>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com> <87my5xihcx.fsf@benfinney.id.au>
Message-ID: <94bdd2610908180942g16faa6e9nba0f0d56c736f13e@mail.gmail.com>

On Tue, Aug 18, 2009 at 11:47 AM, Ben Finney<ben+python at benfinney.id.au> wrote:
> Jeff Rush <jeff at taupro.com> writes:
>
>> The long_description field is also a reStructuredText field and as
>> such, for the developer to preview it during its composure, it needs
>> to be left-aligned. While a developer -could- cut/paste it into a
>> separate text file each time he wants to test preview it, that would
>> be annoying.

Right, following my template proposal (setup.cfg.in), in your case,
the template engine
would require a feature to be able to inject a file in setup.cfg

>
> I get my ?description? and ?long_description? field not directly from a
> text file, but from the package docstring. Following the usual docstring
> interpretation conventions as per PEP 257, I trim all common leading
> indentation from non-blank lines:
>
> ? ?import textwrap
> ? ?import foopackage
>
> ? ?short_description, long_description = (
> ? ? ? ?textwrap.dedent(d).strip()
> ? ? ? ?for d in main_module.__doc__.split('\n\n', 1))
>

As said earlier in this thread, these could be pre-generated in you
release process,
in a static file that can be used by setup.cfg.in without requiring
your code to be shipped
to be able to get static metadata.

From zooko at zooko.com  Wed Aug 19 01:20:47 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Tue, 18 Aug 2009 17:20:47 -0600
Subject: [Distutils] how do I add some functionality to my setup.py
	which is testable and modular?
In-Reply-To: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
Message-ID: <B0DC3DDD-85CA-40A3-AF69-5F93EC02CD87@zooko.com>

Dear Tarek Ziad? and fellowship of the packaging:

Please pay attention to this issue.  If we can extend our build  
processes in a modular, re-usable, and testable way then this could  
contribute to the success of distutils/setuptools/Distribute.

In particular, I want Nevow to be automatically installable as a  
dependency (using, for now, setuptools, but presumably the same will  
apply to Distribute), and one of the issues is still outstanding and  
Glyph refuses to accept my patch which fixes it because the fix isn't  
testable.

http://divmod.org/trac/ticket/2699

I want Distribute-compatible build extensions to be accepted by  
Glyph.  This requires that they be testable.  Please help me  
understand how to write build extensions which are testable.

Regards,

Zooko

On Sunday,2009-08-16, at 14:16 , Zooko Wilcox-O'Hearn wrote:

> Folks:
>
> I have a recurring problem with distutils/setuptools/Distribute,  
> which is that I don't know how to extend the functionality of  
> setup.py and make the new functionality be testable and modular.
>
> Here's one specific example that I currently have a lot of  
> experience with: I'd like to generate a version number from  
> revision control history.  Don't get hung up on the desired  
> functionality though -- if you think that generating version  
> numbers is best done a different way, or if you don't care about  
> generating version numbers, then please just mentally insert some  
> other extension of your build functionality that you do care about.
>
> I'm familiar with three different ways to implement an extension  
> like this.
>
> The first is what Nevow does [1], which is to write in setup.py  
> "from nevow import __version__".  Well, this works in the case that  
> setup.py is being executed as the command-line script in a fresh,  
> empty Python interpreter, but it fails in the case that the Python  
> interpreter has already been running for a while, has already  
> imported nevow (a *different* nevow from a different location on  
> the local filesystem), and is now importing *this* nevow's setup  
> module in order to build this nevow.  This happens with setuptools  
> and py2exe.  Distribute v0.6 includes a patch [2] to fix this, but  
> I'm not sure the patch is right (it involves 'for m in  
> various_modules: del sys.modules[m]' and it doesn't seem to fix all  
> cases).  PJE says "Thou shalt not import yourself when trying to  
> build yourself" [3].  Glyph says "Then how do I test this  
> code?" [4].  I say "Ugh, I don't know. Let's look at the other two  
> ways to do it."
>
> The second is what I do in some of my packages such as pycryptopp  
> [5]. Just take that functionality that you want to add to all of  
> your packages and cut and paste the code into each of your  
> setup.py's, then edit it a little to reflect the correct name of  
> the current package.  This sucks because you're cutting and pasting  
> code, because your setup.py gets bigger and hairier the more  
> functionality your build system has, and because, again, you can't  
> test it.
>
> The third is what I do in Tahoe-LAFS [6].  I moved the  
> functionality in question into a separate Python package, in this  
> case named "darcsver" [7], and used setuptools's plugin system to  
> add a command named "darcsver" which initializes the  
> distribution.metadata.version attribute correctly.  Then I had to  
> add a bunch of aliases to my setup.cfg [8] saying "If you're going  
> to build, first darcsver, and if you're going to install, first  
> darcsver, and ...".  This sort of works, except that yesterday my  
> programming partner Brian Warner informed me [9] that he expected  
> the "python ./setup.py --version" command-line to output the  
> version number.  Argh!  There is no way to configure in my  
> setup.cfg "If you're going to --version, first darcsver.".
>
> So it appears to me that none of these techniques are both modular/ 
> testable and compatible with distutils/setuptools/Distribute.  What  
> are we to do?
>
> Regards,
>
> Zooko
>
> [1] http://www.divmod.org/trac/browser/trunk/Nevow/setup.py?rev=17531
> [2] http://bugs.python.org/setuptools/issue20
> [3] http://bugs.python.org/setuptools/msg139
> [4] http://www.divmod.org/trac/ticket/2699#comment:20
> [5] http://allmydata.org/trac/pycryptopp/browser/setup.py?rev=661#L181
> [6] http://allmydata.org/trac/tahoe/browser/setup.py?rev=4036#L97
> [7] http://allmydata.org/trac/darcsver
> [8] http://allmydata.org/trac/tahoe/browser/setup.cfg?rev=3996#L46
> [9] http://allmydata.org/trac/darcsver/ticket/6
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From pje at telecommunity.com  Wed Aug 19 01:59:32 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 18 Aug 2009 19:59:32 -0400
Subject: [Distutils] how do I add some functionality to my setup.py
 which is testable and modular?
In-Reply-To: <B0DC3DDD-85CA-40A3-AF69-5F93EC02CD87@zooko.com>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
	<B0DC3DDD-85CA-40A3-AF69-5F93EC02CD87@zooko.com>
Message-ID: <20090818235954.63C003A4079@sparrow.telecommunity.com>

At 05:20 PM 8/18/2009 -0600, Zooko Wilcox-O'Hearn wrote:
>Dear Tarek Ziad? and fellowship of the packaging:
>
>Please pay attention to this issue.

Did you read the email where I explained how you could solve the problem today?

   http://mail.python.org/pipermail/distutils-sig/2009-August/012974.html

(Specifically, the problem of fetching dependencies at the start of 
setup.py, so you can use modular extensions to the distutils or setuptools.)


From glyph at twistedmatrix.com  Wed Aug 19 02:11:03 2009
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Tue, 18 Aug 2009 20:11:03 -0400
Subject: [Distutils] how do I add some functionality to my setup.py
	which is testable and modular?
In-Reply-To: <B0DC3DDD-85CA-40A3-AF69-5F93EC02CD87@zooko.com>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
	<B0DC3DDD-85CA-40A3-AF69-5F93EC02CD87@zooko.com>
Message-ID: <d9047f780908181711y1d5247c3h7556212858265b8b@mail.gmail.com>

On Tue, Aug 18, 2009 at 7:20 PM, Zooko Wilcox-O'Hearn <zooko at zooko.com>wrote:

> ... and Glyph refuses to accept my patch which fixes it because the fix
> isn't testable ...


Hi, Zooko :).

Since this message officially makes me That Jerk Who Is Forcing The Issue,
I've finally joined distutils-sig.

Thank you for writing up the whole thing with such a detailed bibliography.
 I'll reply to PJE's message shortly.

(For what it's worth, I wouldn't quite characterize it like that.  More like
"Twisted and Nevow refuse to accept these patches because their policy
requires testability."  I didn't make a personal decision to exclude these
patches; the contributors have achieved a consensus about testability.  The
fact that we all arrived at that consensus because I said so in the first
place is irrelevant ;-)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090818/e8b34a9a/attachment.htm>

From ben+python at benfinney.id.au  Wed Aug 19 02:37:38 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 19 Aug 2009 10:37:38 +1000
Subject: [Distutils] how do I add some functionality to my setup.py
	which is testable and modular?
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
	<B0DC3DDD-85CA-40A3-AF69-5F93EC02CD87@zooko.com>
	<d9047f780908181711y1d5247c3h7556212858265b8b@mail.gmail.com>
Message-ID: <87ljlgfxkd.fsf@benfinney.id.au>

Glyph Lefkowitz <glyph at twistedmatrix.com> writes:

> On Tue, Aug 18, 2009 at 7:20 PM, Zooko Wilcox-O'Hearn <zooko at zooko.com>wrote:
> > ... and Glyph refuses to accept my patch which fixes it because the
> > fix isn't testable ...
>
> Since this message officially makes me That Jerk Who Is Forcing The
> Issue,

I wouldn't characterise it like that :-)

> I've finally joined distutils-sig.

Welcome!

> (For what it's worth, I wouldn't quite characterize it like that. More
> like "Twisted and Nevow refuse to accept these patches because their
> policy requires testability."

I see no real difference between those two; and I find both describe an
equally commendable action.

-- 
 \       ?I never forget a face, but in your case I'll be glad to make |
  `\                                      an exception.? ?Groucho Marx |
_o__)                                                                  |
Ben Finney


From glyph at twistedmatrix.com  Wed Aug 19 06:28:11 2009
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Wed, 19 Aug 2009 00:28:11 -0400
Subject: [Distutils] how do I add some functionality to my setup.py
	which is testable and modular?
In-Reply-To: <20090817001724.E76AB3A4119@sparrow.telecommunity.com>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
	<20090817001724.E76AB3A4119@sparrow.telecommunity.com>
Message-ID: <d9047f780908182128l3081e7dco5ad9c59049ffc558@mail.gmail.com>

On Sun, Aug 16, 2009 at 8:17 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 02:16 PM 8/16/2009 -0600, Zooko Wilcox-O'Hearn wrote:
>
>> So it appears to me that none of these techniques are both modular/
>> testable and compatible with distutils/setuptools/Distribute.  What
>> are we to do?
>>
>
> We could be modular if there was a way to specify pre-setup.py
> dependencies.


For a lot ? although admittedly, not all ? of the code in question, the only
dependency is on some code that lives in the package itself which explicitly
avoids depending on anything besides distutils.  That's not to say
pre-setup.py dependencies wouldn't be useful, but if we could formalize
making that case work (as it would if we could depend on the simplistic
environment that a distutils-only 'setup.py install' has), it would go a
long way towards fixing the larger problem.

Unfortunately, there isn't such a thing at the moment, short of calling
> setup() twice, and forcing the first call to have no script arguments, just
> a setup_requires argument.
>

So, "modular" is a slippery word.  Let me try to be a little more specific
about what I personally want; Zooko can elaborate, and I'm flexible on some
of it, but best to start with an ideal.

I have a development environment where sys.path is set up to point at the
source code for a set of working branches.  For the purposes of this
discussion let's say I've got "Nevow", which contains "nevow/__init__.py",
"Twisted", which contains "twisted/__init__.py", and "Tahoe", which... well,
actually it contains "src/allmydata/__init__.py" but happily my setup can
deal with that.  My sys.path has ["Twisted", "Nevow", "Tahoe/src"] on the
end of it.  My $PATH (or %PATH%, as the case may be) has Twisted/bin,
Nevow/bin, Tahoe/bin.  I hope this convention is clear.

Now, here's the important point.  I want to run 'trial twisted', which is to
say, "~/.../Twisted/bin/trial twisted", and have it load the code from my
pre-existing "Twisted/" sys.path entry.  I want to load and examine the
distribution metadata, which in the current context means running most of
what usually goes in setup.py.  I also want to be able to run *parts* of the
distribution process, to unit-test them, without actually invoking the
entire thing.  There are lots of reasons to want this:

   1. It's much faster to skip installation, especially if you're rapidly
   iterating over changes to a small piece of the distribution setup process
   2. It encourages splitting the distribution process up into smaller
   pieces ("modularizing" it) so that it can be re-used by other parts of the
   same project.
   3. It allows for independent testing of those same pieces so that when
   they are re-used, there is some existing expectation that they will behave
   as expected that isn't specific to installation of a particular package.
   4. By including it in the package, you allow dependencies of that package
   to use the packaging functionality as well, so that custom distribution
   stuff is done consistently across all parts of an ecosystem.

As some of Zooko's links suggest, the way I would *prefer* to do that is for
the distribution metadata to live in a module in 'twisted/', which can be
imported by setup.py as a normal python module, and to have setup.py itself
look like

from distutils import setup
from twisted.python.distribution import metadata
setup(**metadata)

or even better:

from twisted.python.distribution import autosetup
autosetup()

The buildbot, as it happens, has a similar setup.  There are specific
buildslaves that do a full system installation rather than just an 'svn up'
before running the tests, to do whole-system integration testing for the
installation procedure, but that process is much slower and more
disk-intensive, it increases wear and tear on the testing machines, and it
takes longer to provide feedback to developers who are sitting idle, so we
don't want to have it set up that way everywhere.

Of course, that'd only work if setuptools were present, and it would also
> force an immediate download of the build dependencies in question.
>  Something like:
>
>  try:
>      from setuptools import Distribution
>  except ImportError:
>      pass
>  else:
>      Distribution(dict(setup_requires=[...]))
>

What goes in the "..." is pretty important.  For one thing, I don't quite
understand the implications of this approach.  For another, I really don't
want to depend on setuptools, because we certainly need to keep supporting
non-setuptools environments.

If you want to get fancy, you could replace the "pass" with printing some
> user-readable instructions after attempting to see if your build-time
> dependencies are already present.
>

This strikes me as very non-modular.  If such a message is interesting or
important, presumably it needs to be localized, displayed by installers,
etc, and therefore belongs in a module somewhere.  Even if that module needs
to be bundled along with your application in order to make it work :).

Thanks for reading :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090819/5f9b8691/attachment-0001.htm>

From pje at telecommunity.com  Wed Aug 19 18:11:30 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 19 Aug 2009 12:11:30 -0400
Subject: [Distutils] how do I add some functionality to my setup.py
 which is testable and modular?
In-Reply-To: <d9047f780908182128l3081e7dco5ad9c59049ffc558@mail.gmail.co
 m>
References: <EF6D31CA-14F8-48D8-A260-2718ADFF0845@zooko.com>
	<20090817001724.E76AB3A4119@sparrow.telecommunity.com>
	<d9047f780908182128l3081e7dco5ad9c59049ffc558@mail.gmail.com>
Message-ID: <20090819161148.7D5C93A4079@sparrow.telecommunity.com>

At 12:28 AM 8/19/2009 -0400, Glyph Lefkowitz wrote:
>What goes in the "..." is pretty important.?  For one thing, I don't 
>quite understand the implications of this approach.

Basically, anything required in the '...' will be downloaded (and 
built if necessary) then dropped into the setup.py directory as an 
.egg file or directory, unless of course a suitable version of that 
dependency is already on sys.path (or was already downloaded during a 
previous run).  They will not necessarily be included at install 
time, but will be available during the remainder of the setup.py execution.

It occurs to me that there is some possibility that if a given 
library is both a build-time and install-time dependency, that it 
might not be installed correctly in the case of a "setup.py install" 
(as opposed to an "easy_install whatever") use case. (But if so, then 
it's an existing bug in setuptools that should be fixed anyway, and 
is not specific to this way of invoking a build-time dependency.)


From doko at ubuntu.com  Thu Aug 20 11:47:03 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 20 Aug 2009 11:47:03 +0200
Subject: [Distutils] [Python-Dev] request for comments - standardization
 of python's purelib and platlib
In-Reply-To: <94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
References: <h61lmi$m3v$1@ger.gmane.org>	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
	<94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
Message-ID: <4A8D1B97.4060108@ubuntu.com>

On 14.08.2009 10:02, Tarek Ziad? wrote:
> On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett at python.org>  wrote:
>>
>>
>> On Thu, Aug 13, 2009 at 11:23, Jan Matejek<jan.matejek at novell.com>  wrote:
>>>
>>> Hello,
>>>
>>> I'm cross-posting this to distributions at freedesktop and python-dev,
>>> because the topic is relevant to both groups and should be solved in
>>> cooperation.
>>>
>>> The issue:
>>>
>>> In Python's default configuration (on linux), both purelib (location for
>>> pure python modules) and platlib (location for platform-dependent binary
>>> extensions) point to $prefix/lib/pythonX.Y/site-packages.
>>> That is no good for two main reasons.
>>>
>>> One, python depends on the "lib" directory. (from distro's point of
>>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
>>> impossible to install python under /usr/lib64 without heavy patching.
>>> Repeated attempts to bring python developers to acknowledge and rectify
>>> the situation have all failed (common argument here is "that would mean
>>> redesign of distutils and huge parts of whatnot").
>>
>> This is now Tarek's call, so this may or may not have changed in terms of
>> what the (now) distutils maintainer thinks.
>>
>
> I don't recall those repeated attempts , but I've been around for less
> than two years.
>
> You are very welcome to come in the Distutils-SIG ML to discuss these matters.
> I'm moving the discussion there.
>
> Among the proposals you have detailed, the sharedir way seems like the
> most simple/interesting
> one (depending on you answer to Brett's question )

The approach of splitting the installation into two different locations seems to 
be wrong, it changes the semantics for imports of python packages which are not 
installed in the same location. Simplest counter example is the use of relative 
imports, which will fail if the imported module/extension is not found in the 
same paths.

Other languages like Perl or Java don't have relative imports, or they map all 
components on the "path" into one logical path so you don't have this kind of 
problem.

I don't see an explict statement that code really has to live inside /usr/share, 
and even generated .py files differ depending on the architecture you build for 
(e.g. sip, qt bindings).

   Matthias

From jason.heeris at gmail.com  Thu Aug 20 09:23:50 2009
From: jason.heeris at gmail.com (Jason Heeris)
Date: Thu, 20 Aug 2009 15:23:50 +0800
Subject: [Distutils] Postinst functions for distutils MSI installer?
Message-ID: <d69956980908200023i4fc768aib2f01f6adfd5b570@mail.gmail.com>

Hi,

(Under Python 2.6) I'm trying to get an MSI installer together for a
small python program. I've written a postinst script that basically
creates a shortcut on the desktop (unfortunately I couldn't see a more
agnostic way to do this, but oh well). It works with a "bdist_wininst"
type build, but not with a "bdist_msi" build. It looks like a console
pops up for a tenth of a second, and depending on what fails there's a
GUI error dialog suggesting that I contact... myself... for support.
The script appears to run, but sys.argv does not contain "-install" as
I expected and none of the functions that are given in the
"bdist_wininst" docs are present.

I guess I naively presumed that the MSI build would be similar to the
wininst build, but I can't find any docs, so are there any other
resources I can look at?

Cheers,
Jason

From jan.matejek at novell.com  Thu Aug 20 19:17:01 2009
From: jan.matejek at novell.com (Jan Matejek)
Date: Thu, 20 Aug 2009 19:17:01 +0200
Subject: [Distutils] [Python-Dev] request for comments - standardization
 of python's purelib and platlib
In-Reply-To: <4A8D1B97.4060108@ubuntu.com>
References: <h61lmi$m3v$1@ger.gmane.org>	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>	<94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
	<4A8D1B97.4060108@ubuntu.com>
Message-ID: <4A8D850D.7060805@novell.com>

finally some kind of discussion! ;)

Dne 20.8.2009 11:47, Matthias Klose napsal(a):
> On 14.08.2009 10:02, Tarek Ziad? wrote:
>> On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett at python.org>  wrote:
>>>
>>>
>>> On Thu, Aug 13, 2009 at 11:23, Jan Matejek<jan.matejek at novell.com> 
>>> wrote:
>> Among the proposals you have detailed, the sharedir way seems like the
>> most simple/interesting
>> one (depending on you answer to Brett's question )
> 
> The approach of splitting the installation into two different locations
> seems to be wrong, it changes the semantics for imports of python
> packages which are not installed in the same location. Simplest counter
> example is the use of relative imports, which will fail if the imported
> module/extension is not found in the same paths.

isn't using relative imports outside packages a bad practice?

I'm not proposing to split installation of single package. I'm proposing
having two different default install locations, based on package type
(platform dependent/independent), not on file type.
Package is pure (platform independent) as long as -all- of its files are
pure.

I have seen one problem so far: wxGTK's python part installs a .pth file
along with its purelib part, that supposedly points to its platlib
package. That of course breaks when purelib != platlib. So far i would
consider this a bug in wxGTK, or rather relying on behavior that is not
well defined. But i admit that i'm not sure.

> 
> Other languages like Perl or Java don't have relative imports, or they
> map all components on the "path" into one logical path so you don't have
> this kind of problem.

and that's probably why perl approach would fail miserably in python ;)
unless we implemented mapping to one path. Hopefully, we probably don't
need to do it.

> 
> I don't see an explict statement that code really has to live inside
> /usr/share,

Doesn't have to - it's just that there doesn't seem to be a better
location. If you know of one, let's see it.

> and even generated .py files differ depending on the
> architecture you build for (e.g. sip, qt bindings).

In that case, such packages aren't pure and installing them into purelib
path would be a bug.

regards
m.

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



From alsuren at gmail.com  Fri Aug 21 17:15:47 2009
From: alsuren at gmail.com (David Laban)
Date: Fri, 21 Aug 2009 16:15:47 +0100
Subject: [Distutils] Installing config files into specific directories,
	even with setuptools?
In-Reply-To: <op.uyg8slrx1q4jlt@whymac.activestate.com>
References: <4A8087ED.301@gmail.com> <op.uyg8slrx1q4jlt@whymac.activestate.com>
Message-ID: <44bf3a1f0908210815v5590150m88dd090c12ec9576@mail.gmail.com>

> 2. When the application is first run, check for ~/.local (or APPDATA on
> Windows) - and if user config directory-or-files is not present, copy them
> from the namespace location to ~/.local.

The app is only ever run by dbus finding the service file, so this
won't work. The file does not need to be editable once it's installed,
but if the user does not have root access, it needs to be installed in
~.local/share rather than /usr/share or wherever.

If I created an "install_xdg" function, would I be able to contribute
it to distutils/setuptools/distribute?

David

From sridharr at activestate.com  Sat Aug 22 03:58:52 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 21 Aug 2009 18:58:52 -0700
Subject: [Distutils] Support for post-install code
In-Reply-To: <44bf3a1f0908210815v5590150m88dd090c12ec9576@mail.gmail.com>
References: <4A8087ED.301@gmail.com> <op.uyg8slrx1q4jlt@whymac.activestate.com>
	<44bf3a1f0908210815v5590150m88dd090c12ec9576@mail.gmail.com>
Message-ID: <op.uy1jsems1q4jlt@whymac.activestate.com>

On Fri, 21 Aug 2009 08:15:47 -0700, David Laban <alsuren at gmail.com> wrote:

>> 2. When the application is first run, check for ~/.local (or APPDATA on
>> Windows) - and if user config directory-or-files is not present, copy  
>> them
>> from the namespace location to ~/.local.
> The app is only ever run by dbus finding the service file, so this
> won't work. The file does not need to be editable once it's installed,
> but if the user does not have root access, it needs to be installed in
> ~.local/share rather than /usr/share or wherever.
> If I created an "install_xdg" function, would I be able to contribute
> it to distutils/setuptools/distribute?

Aside:

It looks like providing support for "post install" scripts in  
distutils/Distribute would satisfy the user cases like above.  
apt/yast/etc.. already do this. seutp.py:postinstall() method perhaps?  
Note that if we are doing this - package managers must also be taken into  
account .. for post install should not be *run* during "setup.py install  
--root=.." but only when the package is actually installed (which is  
installer-specific) on the target system.

-srid

From sridharr at activestate.com  Sat Aug 22 04:05:22 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 21 Aug 2009 19:05:22 -0700
Subject: [Distutils] [Catalog-sig] HTML in long description
In-Reply-To: <4A8EB7CB.6040609@v.loewis.de>
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
Message-ID: <op.uy1j28pq1q4jlt@whymac.activestate.com>

On Fri, 21 Aug 2009 08:05:47 -0700, Martin v. L?wis <martin at v.loewis.de>  
wrote:

> It might also be useful to have a
> distutils command that generates a pypi-like page, so that people can
> preview the rendered description.

I often think: why not integrate Sphinx with PyPI's web page generation?  
Perhaps a sphinx extension that would generate the "front page" for PyPI  
containing long_description and download links along with other pertinent  
metadata. Then, this "preview" functionality can be flexibly added to  
distutils (which would delegate to Sphinx anyway).

Additionally, the entire documentation can also be attached to a PyPI  
page, for instance:

   http://pypi.python.org/pypi/Distribute would be the "front page"

and:

   http://pypi.python.org/pypi/Distribute/docs/api can be the api docs

The same URL structure can be made available in the local preview  
(http://localhost:8800/pypi/Distribute/docs/api).

<radical/crazy thinking>Hmm, why not merge bitbucket and PyPI (w/ sphinx,  
Distribute)? One stop Python development!

-srid

From martin at v.loewis.de  Sat Aug 22 09:45:15 2009
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 22 Aug 2009 09:45:15 +0200
Subject: [Distutils] [Catalog-sig] HTML in long description
In-Reply-To: <op.uy1j28pq1q4jlt@whymac.activestate.com>
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
	<op.uy1j28pq1q4jlt@whymac.activestate.com>
Message-ID: <4A8FA20B.40600@v.loewis.de>

> Hmm, why not merge bitbucket and PyPI 

I don't think we have the resources for that, in terms of volunteers.
We hardly have enough volunteers to make any changes to PyPI.

Regards,
Martin

From chris at simplistix.co.uk  Mon Aug 24 17:46:05 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Aug 2009 16:46:05 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A8A606D.6090306@taupro.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<aa030340d3d05b66b14aa22eabade5b7@preisshare.net>
	<4A8A606D.6090306@taupro.com>
Message-ID: <4A92B5BD.2040201@simplistix.co.uk>

Jeff Rush wrote:
> The long_description field is also a reStructuredText field and as such,

Indeed, for this I'd prefer a long_description_path to a file containing 
the long description...

Chris

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

From chris at simplistix.co.uk  Mon Aug 24 17:47:09 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Aug 2009 16:47:09 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
Message-ID: <4A92B5FD.6080809@simplistix.co.uk>

David Lyon wrote:
> On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>> We can use the [global] section of the setup.cfg file to describe them.
> 
> My suggestion is [setup] because it directly corresponds to the setup()
> function. I know it is a triplication of the name (setup.cfg, setup()
> and then [setup]) but it's much more consistent and will be easier to
> find for new users.

+1

Chris

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

From chris at simplistix.co.uk  Mon Aug 24 17:49:01 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Aug 2009 16:49:01 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <20090818150903.5176A3A4079@sparrow.telecommunity.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>	<4A8A0DD0.8020101@nextday.fi>
	<20090818070817.GA8134@laurie.devork>
	<20090818150903.5176A3A4079@sparrow.telecommunity.com>
Message-ID: <4A92B66D.2030507@simplistix.co.uk>

P.J. Eby wrote:
> In which case, why not simply have a "configure"-like command that 
> generates a fixed set of static metadata?
> 
> Or better yet, make it "configure.py" or something like that.  Since it 
> is not the old setup.py, it does not have to offer the same command line 
> interface or be backward compatible with existing code.

minus lots on allowing it to be anything other than an extremely 
constrained domain specific language...

Chris

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

From ziade.tarek at gmail.com  Mon Aug 24 17:58:47 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 24 Aug 2009 17:58:47 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A92B5FD.6080809@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A92B5FD.6080809@simplistix.co.uk>
Message-ID: <94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>

2009/8/24 Chris Withers <chris at simplistix.co.uk>:
> David Lyon wrote:
>>
>> On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
>> wrote:
>>>
>>> We can use the [global] section of the setup.cfg file to describe them.
>>
>> My suggestion is [setup] because it directly corresponds to the setup()
>> function. I know it is a triplication of the name (setup.cfg, setup()
>> and then [setup]) but it's much more consistent and will be easier to
>> find for new users.
>
> +1

If we change the name, I would rather call it [metadata]
which is more explicit than [setup] : it's a section containing
the metadata of the distribution.

btw,  I have a working prototype for the setup.cfg.in template file,
I'll push here when I get home tonite, for feedback

From jannis at leidel.info  Mon Aug 24 18:03:34 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Mon, 24 Aug 2009 18:03:34 +0200
Subject: [Distutils] [Catalog-sig] HTML in long description
In-Reply-To: <op.uy1j28pq1q4jlt@whymac.activestate.com>
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
	<op.uy1j28pq1q4jlt@whymac.activestate.com>
Message-ID: <A230C638-379D-40A0-A280-E698C472A631@leidel.info>

> I often think: why not integrate Sphinx with PyPI's web page  
> generation? Perhaps a sphinx extension that would generate the  
> "front page" for PyPI containing long_description and download links  
> along with other pertinent metadata. Then, this "preview"  
> functionality can be flexibly added to distutils (which would  
> delegate to Sphinx anyway).
>
> Additionally, the entire documentation can also be attached to a  
> PyPI page, for instance:
>
>  http://pypi.python.org/pypi/Distribute would be the "front page"
>
> and:
>
>  http://pypi.python.org/pypi/Distribute/docs/api can be the api docs
>
> The same URL structure can be made available in the local preview (http://localhost:8800/pypi/Distribute/docs/api 
> ).
>
> <radical/crazy thinking>Hmm, why not merge bitbucket and PyPI (w/  
> sphinx, Distribute)? One stop Python development!

A lot less radical and working today:

     http://pypi.python.org/pypi/Sphinx-PyPI-upload

which will add an upload_sphinx command to (setuptools based)  
setup.py, creates a zip file of your Sphinx build directory and  
uploads it to PyPI to show up at http://packages.python.org/ 
<package>/, e.g. http://packages.python.org/django-authority/.

Jannis

From chris at simplistix.co.uk  Mon Aug 24 18:05:04 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Aug 2009 17:05:04 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>	<4A92B5FD.6080809@simplistix.co.uk>
	<94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>
Message-ID: <4A92BA30.7030508@simplistix.co.uk>

Tarek Ziad? wrote:
> If we change the name, I would rather call it [metadata]
> which is more explicit than [setup] 

Not really... metadata is a generic, meaningless word.
We're talking about setup metadata, so I think [setup] makes more sense. 
I think the parallels with setup.py and setup.cfg are also better for 
discoverability...

> btw,  I have a working prototype for the setup.cfg.in template file,
> I'll push here when I get home tonite, for feedback

I missed the thread on this... Why is it needed? I generally hate the 
idea of having a .in file for a .cfg file. It's a sign that the .cfg 
fiel is being used incorrectly...

Chris

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

From ziade.tarek at gmail.com  Mon Aug 24 18:09:46 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 24 Aug 2009 18:09:46 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A92BA30.7030508@simplistix.co.uk>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A92B5FD.6080809@simplistix.co.uk>
	<94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>
	<4A92BA30.7030508@simplistix.co.uk>
Message-ID: <94bdd2610908240909t4179b131qcd22c09cbd6c5c2c@mail.gmail.com>

On Mon, Aug 24, 2009 at 6:05 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> If we change the name, I would rather call it [metadata]
>> which is more explicit than [setup]
>
> Not really... metadata is a generic, meaningless word.

I disagree. We are talking about the fields that describes... 	
'Metadata for Python Software Packages'

(see PEP 241 + PEP 314)

So I don't find the word "metadata" meaningless. Whereas "setup"
is meaningless to me in this context, especially iff we are already located in
a file called setup.cfg: it doesn't add any useful information, just redundancy.

From nicdumz at gmail.com  Mon Aug 24 23:09:22 2009
From: nicdumz at gmail.com (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 23:09:22 +0200
Subject: [Distutils] Setup script exited with error: build/ *
	/egg/EGG-INFO/zip-safe: No such file or directory
Message-ID: <1f077e770908241409t27010628je2aa4502cf62b801@mail.gmail.com>

Hello!

I am the maintainer of a small C extension, and after uploading it to
pypi, out of curiosity, I tried installing it using easy_install.

The error that easy_install returns is however quite cryptic, and I
have no idea of what is happening:

$ easy_install -v -n --install-dir /Users/junk/py-lib pyfsevents
Checking existing site.py in /Users/junk/py-lib
Searching for pyfsevents
Reading http://pypi.python.org/simple/pyfsevents/
Reading http://bitbucket.org/nicdumz/fsevents/
Found link: http://pypi.python.org/packages/source/p/pyfsevents/pyfsevents-0.1.tar.gz#md5=edadbf0670ff96077fc05196817084e3
Best match: pyfsevents 0.1
Downloading http://pypi.python.org/packages/source/p/pyfsevents/pyfsevents-0.1.tar.gz#md5=edadbf0670ff96077fc05196817084e3
Validating md5 checksum for /tmp/easy_install-NGokgY/pyfsevents-0.1.tar.gz
Processing pyfsevents-0.1.tar.gz
Unpacking pyfsevents-0.1// to /tmp/easy_install-NGokgY/pyfsevents-0.1/
Unpacking pyfsevents-0.1/BUGS to /tmp/easy_install-NGokgY/pyfsevents-0.1/BUGS
Unpacking pyfsevents-0.1/examples// to
/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/
Unpacking pyfsevents-0.1/examples/proofofconcept.py to
/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/proofofconcept.py
Unpacking pyfsevents-0.1/examples/testwatcher.py to
/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/testwatcher.py
Unpacking pyfsevents-0.1/examples/watcher.py to
/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/watcher.py
Unpacking pyfsevents-0.1/examples/watcher.pyc to
/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/watcher.pyc
Unpacking pyfsevents-0.1/INSTALL to
/tmp/easy_install-NGokgY/pyfsevents-0.1/INSTALL
Unpacking pyfsevents-0.1/LICENSE to
/tmp/easy_install-NGokgY/pyfsevents-0.1/LICENSE
Unpacking pyfsevents-0.1/PKG-INFO to
/tmp/easy_install-NGokgY/pyfsevents-0.1/PKG-INFO
Unpacking pyfsevents-0.1/pyfsevents.c to
/tmp/easy_install-NGokgY/pyfsevents-0.1/pyfsevents.c
Unpacking pyfsevents-0.1/README to
/tmp/easy_install-NGokgY/pyfsevents-0.1/README
Unpacking pyfsevents-0.1/readme.rst to
/tmp/easy_install-NGokgY/pyfsevents-0.1/readme.rst
Unpacking pyfsevents-0.1/setup.py to
/tmp/easy_install-NGokgY/pyfsevents-0.1/setup.py
Running pyfsevents-0.1/setup.py -n bdist_egg --dist-dir
/tmp/easy_install-NGokgY/pyfsevents-0.1/egg-dist-tmp-3dV2pZ
running bdist_egg
running egg_info
creating pyfsevents.egg-info
writing pyfsevents.egg-info/PKG-INFO
writing top-level names to pyfsevents.egg-info/top_level.txt
writing dependency_links to pyfsevents.egg-info/dependency_links.txt
writing manifest file 'pyfsevents.egg-info/SOURCES.txt'
writing manifest file 'pyfsevents.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.5-i386/egg
running install_lib
running build_ext
building 'pyfsevents' extension
creating build
creating build/temp.macosx-10.5-i386-2.5
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall
-Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE -arch
i386 -arch ppc -pipe
-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-c pyfsevents.c -o build/temp.macosx-10.5-i386-2.5/pyfsevents.o
creating build/lib.macosx-10.5-i386-2.5
gcc -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc
build/temp.macosx-10.5-i386-2.5/pyfsevents.o -o
build/lib.macosx-10.5-i386-2.5/pyfsevents.so -framework CoreFoundation
-framework CoreServices
creating build/bdist.macosx-10.5-i386
creating build/bdist.macosx-10.5-i386/egg
creating build/bdist.macosx-10.5-i386/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
error: Setup script exited with error:
build/bdist.macosx-10.5-i386/egg/EGG-INFO/zip-safe: No such file or
directory

Do we have a bug? Or simply a badly worded message?

Note that I did not expect easy_install to work out of the box without
configuration on my end, I am just surprised by the opaque error.

Troubleshooting the issue seems quite difficult. Even with
--build-directory , that build/bdist* repertory is not kept after the
error. Maybe -k should be passed to setup.py when -b is passed to
easy_install?

Thanks,
-- 
Nicolas Dumazet ? NicDumZ

From sorin.sbarnea at gmail.com  Fri Aug 21 12:43:04 2009
From: sorin.sbarnea at gmail.com (Sorin Sbarnea)
Date: Fri, 21 Aug 2009 13:43:04 +0300
Subject: [Distutils] x64 - maintaining setuptools? svn write access?
Message-ID: <d77cce480908210343r7028f3b9ue802e01107a660eb@mail.gmail.com>

Please take a look at issue #2 - http://bugs.python.org/setuptools/issue2
It's very old, it has a patch that was tested and is marked and
considered critical by several users (7) and still nobody take time to
include the patch in svn.

If nobody can commit this I would like to request a svn account so I
would be able to repair this issue.

Thanks,
--
/sorin
http://nusunt.eu

---------- Forwarded message ----------
From: Jules Stevenson <setuptools at bugs.python.org>
Date: Fri, Aug 21, 2009 at 12:48 PM
Subject: [issue2] easy_install broken on 64 bits Windows
To: asmodai at in-nomine.org, jaraco at jaraco.com, jules at js3d.co.uk,
nick.bolton.uk at gmail.com, pje at telecommunity.com,
sorin.sbarnea at gmail.com, sridharr at activestate.com



Jules Stevenson <jules at js3d.co.uk> added the comment:

I'm having no joy installing the patch [my knowledge of this is practically
non-existent]. Is there any chance that anyone could host the patched source so
I can get hold of it? Aprreciate this is a big ask. My email is jules at
js3d.co.uk. many thanks.

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue2>
_______________________________________________

From david.lyon at preisshare.net  Tue Aug 25 01:13:06 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 24 Aug 2009 19:13:06 -0400
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A92B5FD.6080809@simplistix.co.uk>
	<94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>
Message-ID: <2dbabf1ed9821c79fe95f92861f295d9@preisshare.net>

On Mon, 24 Aug 2009 17:58:47 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> btw,  I have a working prototype for the setup.cfg.in template file,
> I'll push here when I get home tonite, for feedback

This seems somewhat unfair that I cannot participate in the
development of this.

I've asked you onlist and offlist how I go about this but I
never get any answer.

Now you claim to have "closed" source on this...

Not nice - Tarek...




From pje at telecommunity.com  Tue Aug 25 01:37:20 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 24 Aug 2009 19:37:20 -0400
Subject: [Distutils] Setup script exited with error: build/ *
 /egg/EGG-INFO/zip-safe: No such file or directory
In-Reply-To: <1f077e770908241409t27010628je2aa4502cf62b801@mail.gmail.co
 m>
References: <1f077e770908241409t27010628je2aa4502cf62b801@mail.gmail.com>
Message-ID: <20090824233748.66ECC3A406B@sparrow.telecommunity.com>

At 11:09 PM 8/24/2009 +0200, Nicolas Dumazet wrote:
>Hello! I am the maintainer of a small C extension, and after 
>uploading it to pypi, out of curiosity, I tried installing it using 
>easy_install. The error that easy_install returns is however quite 
>cryptic, and I have no idea of what is happening: $ easy_install -v 
>-n --install-dir /Users/junk/py-lib pyfsevents


Try:

   easy_install -eb. pyfsevents
   cd ./pyfsevents
   python -c "import setuptools; execfile('setup.py')" bdist_egg

This will leave the build directories in place, and may give you 
better error information about the problem.


>Checking existing site.py in /Users/junk/py-lib Searching for 
>pyfsevents Reading http://pypi.python.org/simple/pyfsevents/ Reading 
>http://bitbucket.org/nicdumz/fsevents/ Found link: 
>http://pypi.python.org/packages/source/p/pyfsevents/pyfsevents-0.1.tar.gz#md5=edadbf0670ff96077fc05196817084e3 
>Best match: pyfsevents 0.1 Downloading 
>http://pypi.python.org/packages/source/p/pyfsevents/pyfsevents-0.1.tar.gz#md5=edadbf0670ff96077fc05196817084e3 
>Validating md5 checksum for 
>/tmp/easy_install-NGokgY/pyfsevents-0.1.tar.gz Processing 
>pyfsevents-0.1.tar.gz Unpacking pyfsevents-0.1// to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/ Unpacking 
>pyfsevents-0.1/BUGS to /tmp/easy_install-NGokgY/pyfsevents-0.1/BUGS 
>Unpacking pyfsevents-0.1/examples// to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/ Unpacking 
>pyfsevents-0.1/examples/proofofconcept.py to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/proofofconcept.py 
>Unpacking pyfsevents-0.1/examples/testwatcher.py to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/testwatcher.py 
>Unpacking pyfsevents-0.1/examples/watcher.py to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/watcher.py 
>Unpacking pyfsevents-0.1/examples/watcher.pyc to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/examples/watcher.pyc 
>Unpacking pyfsevents-0.1/INSTALL to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/INSTALL Unpacking 
>pyfsevents-0.1/LICENSE to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/LICENSE Unpacking 
>pyfsevents-0.1/PKG-INFO to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/PKG-INFO Unpacking 
>pyfsevents-0.1/pyfsevents.c to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/pyfsevents.c Unpacking 
>pyfsevents-0.1/README to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/README Unpacking 
>pyfsevents-0.1/readme.rst to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/readme.rst Unpacking 
>pyfsevents-0.1/setup.py to 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/setup.py Running 
>pyfsevents-0.1/setup.py -n bdist_egg --dist-dir 
>/tmp/easy_install-NGokgY/pyfsevents-0.1/egg-dist-tmp-3dV2pZ running 
>bdist_egg running egg_info creating pyfsevents.egg-info writing 
>pyfsevents.egg-info/PKG-INFO writing top-level names to 
>pyfsevents.egg-info/top_level.txt writing dependency_links to 
>pyfsevents.egg-info/dependency_links.txt writing manifest file 
>'pyfsevents.egg-info/SOURCES.txt' writing manifest file 
>'pyfsevents.egg-info/SOURCES.txt' installing library code to 
>build/bdist.macosx-10.5-i386/egg running install_lib running 
>build_ext building 'pyfsevents' extension creating build creating 
>build/temp.macosx-10.5-i386-2.5 gcc -fno-strict-aliasing 
>-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common 
>-dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX 
>-I/usr/include/ffi -DENABLE_DTRACE -arch i386 -arch ppc -pipe 
>-I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 
>-c pyfsevents.c -o build/temp.macosx-10.5-i386-2.5/pyfsevents.o 
>creating build/lib.macosx-10.5-i386-2.5 gcc -Wl,-F. -bundle 
>-undefined dynamic_lookup -arch i386 -arch ppc 
>build/temp.macosx-10.5-i386-2.5/pyfsevents.o -o 
>build/lib.macosx-10.5-i386-2.5/pyfsevents.so -framework 
>CoreFoundation -framework CoreServices creating 
>build/bdist.macosx-10.5-i386 creating 
>build/bdist.macosx-10.5-i386/egg creating 
>build/bdist.macosx-10.5-i386/egg/EGG-INFO zip_safe flag not set; 
>analyzing archive contents... error: Setup script exited with error: 
>build/bdist.macosx-10.5-i386/egg/EGG-INFO/zip-safe: No such file or 
>directory Do we have a bug? Or simply a badly worded message? Note 
>that I did not expect easy_install to work out of the box without 
>configuration on my end, I am just surprised by the opaque error. 
>Troubleshooting the issue seems quite difficult. Even with 
>--build-directory , that build/bdist* repertory is not kept after 
>the error. Maybe -k should be passed to setup.py when -b is passed 
>to easy_install? Thanks, -- Nicolas Dumazet ? NicDumZ 
>________________________________________________ Distutils-SIG 
>maillist  -  Distutils-SIG at python.org 
>http://mail.python.org/mailman/listinfo/distutils-sig


From ziade.tarek at gmail.com  Tue Aug 25 09:11:15 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 25 Aug 2009 09:11:15 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <2dbabf1ed9821c79fe95f92861f295d9@preisshare.net>
References: <94bdd2610908170034q544bca48g7619589bd3764@mail.gmail.com>
	<531f0bc5ca644a47380bb6fc8add3dbf@preisshare.net>
	<4A92B5FD.6080809@simplistix.co.uk>
	<94bdd2610908240858m2072e44bv7e63185c71ddf8f2@mail.gmail.com>
	<2dbabf1ed9821c79fe95f92861f295d9@preisshare.net>
Message-ID: <94bdd2610908250011s314faaa8u8a0980408e920974@mail.gmail.com>

On Tue, Aug 25, 2009 at 1:13 AM, David Lyon<david.lyon at preisshare.net> wrote:
> On Mon, 24 Aug 2009 17:58:47 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>> btw, ?I have a working prototype for the setup.cfg.in template file,
>> I'll push here when I get home tonite, for feedback
>
> This seems somewhat unfair that I cannot participate in the
> development of this.
>
> I've asked you onlist and offlist how I go about this but I
> never get any answer.
>
> Now you claim to have "closed" source on this...
>
> Not nice - Tarek...
>

I've always answered your private mails and IMs, that's not very rewarding :)

I have done a prototype (=not closed, not finished) right after the
discussion, in
the train back home, and I got your private mail *after* that telling
me that you
wanted to participate.

I was waiting to push it on a public repo so people here (including you)
could participate in it if they wanted. And I was going to answer to
your mail at that moment.

I am sorry if you feel frustrated somehow, but this was not my intent.

I guess the best way to exchange is to stick in this mailing list and
in the code that get
published.


Cheers

Tarek

From chris at simplistix.co.uk  Tue Aug 25 10:25:28 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 25 Aug 2009 09:25:28 +0100
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
 support -m
In-Reply-To: <1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>
References: <4A86958A.4040507@simplistix.co.uk>	
	<E1B47AD1-E53F-4D5C-B54A-AA3AB8A14570@canonical.com>	
	<4A86A195.9090805@simplistix.co.uk>
	<1099b90b0908150523v483aca06u73726159ac4b2e55@mail.gmail.com>
Message-ID: <4A939FF8.1050907@simplistix.co.uk>

Jim Fulton wrote:
> AFAIK, the standard interpreter command line arguments are implemented
> at a low level and aren't meant to be reusable.  To make them work
> basically requires reimplementing them.  It would be useful if there
> was a module that just had implementations of (most of) the standard
> interpreter options.

Is this perhaps what's in the runpy module of the standard library?

http://docs.python.org/library/runpy.html#module-runpy

Hmmm, maybe it does just the right thing for -m?

In any case, any objections to me implementing this for buildout scripts?
If not, where is the actual code that generates the scripts?

cheers,

Chris

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

From reinout at vanrees.org  Tue Aug 25 10:44:58 2009
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 25 Aug 2009 08:44:58 +0000 (UTC)
Subject: [Distutils] [Catalog-sig] HTML in long description
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
	<op.uy1j28pq1q4jlt@whymac.activestate.com>
	<A230C638-379D-40A0-A280-E698C472A631@leidel.info>
Message-ID: <slrnh9794a.27d0.reinout@isengrim.local>

On 2009-08-24, Jannis Leidel <jannis at leidel.info> wrote:
>
> A lot less radical and working today:
>
>      http://pypi.python.org/pypi/Sphinx-PyPI-upload
>
> which will add an upload_sphinx command to (setuptools based)  
> setup.py, creates a zip file of your Sphinx build directory and  
> uploads it to PyPI to show up at http://packages.python.org/ 
><package>/, e.g. http://packages.python.org/django-authority/.

Could you add a really quick readme to that package?  I'm unsure how to use it
and I definitively don't want to experiment with packages.python.org :-)

Are there alternatives for uploading documentation there?  And is there
documentation for the goal of that packages.python.org/* documentation area?
Googling on packages.python.org is hard to get useful results out :-)


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  Tue Aug 25 11:48:11 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 25 Aug 2009 11:48:11 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908180932te51f49byc9f3938c29a0c100@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>
Message-ID: <94bdd2610908250248o46349e76uea66245f5ebd1173@mail.gmail.com>

On Tue, Aug 18, 2009 at 6:32 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Tue, Aug 18, 2009 at 1:26 PM, Eric Smith<eric at trueblade.com> wrote:
>> David Lyon wrote:
>>>
>>> That's why we need to keep it simple. Handle 85% of use cases with
>>> config and the other 15% with the ability to use (python) code.
>>
>> The part that needs to by "code-like" is only the stuff that's needed when
>> the config file is used by an installer, and is known only to the target
>> system. Remember one of the points of having a static file (as we discussed
>> at the language summit) is so that installers can install a "module
>> distribution" (distutils term) without executing any python code.
>>
>> So version dependencies might need to be code-like, per-python-version
>> dependencies might also need to be. But the long description doesn't. If you
>> want it to be read from some other file, use a script (possibly in a
>> makefile) that generates the config file from various pieces.
>>
>> I think these things that need to be code-like are things that depend on the
>> target system and can't be known until an actual installation takes place.
>> The rest of it can be truly static. I think this list of code-like things
>> can and should be enumerated, and should be very small.
>>
>> Ideally, they'd be translatable into the same sorts of expressions that are
>> understood by rpm and deb (and other) installers, but that's a tall order.
>
> What about a fully static setup.cfg file, and a template file called
> setup.cfg.in,
> working like MANIFEST and MANIFEST.in

Here's a demo of what I was thinking of adding in Distutils:

http://bitbucket.org/tarek/staticmetadata/

It uses Mako just for the proof of concept, README.txt explains how it works

Let me know how this fits your needs,

Cheers
Tarek

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

From jim at zope.com  Tue Aug 25 12:00:01 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 25 Aug 2009 06:00:01 -0400
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
	support -m
In-Reply-To: <4A939FF8.1050907@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>
Message-ID: <1099b90b0908250300s70876458yc49e234fd4905784@mail.gmail.com>

On Tue, Aug 25, 2009 at 4:25 AM, Chris Withers<chris at simplistix.co.uk> wrote:
> Jim Fulton wrote:
>>
>> AFAIK, the standard interpreter command line arguments are implemented
>> at a low level and aren't meant to be reusable. ?To make them work
>> basically requires reimplementing them. ?It would be useful if there
>> was a module that just had implementations of (most of) the standard
>> interpreter options.
>
> Is this perhaps what's in the runpy module of the standard library?

No.

>
> http://docs.python.org/library/runpy.html#module-runpy
>
> Hmmm, maybe it does just the right thing for -m?

Perhaps.

> In any case, any objections to me implementing this for buildout scripts?

No, but I want to review it before you merge it to trunk.

> If not, where is the actual code that generates the scripts?

In the easy_install meodule.

Jim

-- 
Jim Fulton

From barry at python.org  Tue Aug 25 12:02:39 2009
From: barry at python.org (Barry Warsaw)
Date: Tue, 25 Aug 2009 06:02:39 -0400
Subject: [Distutils] [Catalog-sig] HTML in long description
In-Reply-To: <slrnh9794a.27d0.reinout@isengrim.local>
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
	<op.uy1j28pq1q4jlt@whymac.activestate.com>
	<A230C638-379D-40A0-A280-E698C472A631@leidel.info>
	<slrnh9794a.27d0.reinout@isengrim.local>
Message-ID: <3F20127A-C992-4B86-9AB6-A21982EB6EF4@python.org>

On Aug 25, 2009, at 4:44 AM, Reinout van Rees wrote:

> On 2009-08-24, Jannis Leidel <jannis at leidel.info> wrote:
>>
>> A lot less radical and working today:
>>
>>     http://pypi.python.org/pypi/Sphinx-PyPI-upload
>>
>> which will add an upload_sphinx command to (setuptools based)
>> setup.py, creates a zip file of your Sphinx build directory and
>> uploads it to PyPI to show up at http://packages.python.org/
>> <package>/, e.g. http://packages.python.org/django-authority/.
>
> Could you add a really quick readme to that package?  I'm unsure how  
> to use it
> and I definitively don't want to experiment with  
> packages.python.org :-)

I tried playing with this but unfortunately it doesn't seem to work  
well with a buildout based package.  It couldn't find the directory to  
zip and I wasn't able to use -d to do the right thing.

> Are there alternatives for uploading documentation there?  And is  
> there
> documentation for the goal of that packages.python.org/*  
> documentation area?
> Googling on packages.python.org is hard to get useful results out :-)

It's easy enough to upload documentation manually.  Go into the  
directory that contains your index.html file and do something like  
'zip -r docs.zip .' then go to your package's page on pypi and scroll  
down for the upload form.

-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/20090825/5a490174/attachment.pgp>

From jannis at leidel.info  Tue Aug 25 13:48:37 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 25 Aug 2009 13:48:37 +0200
Subject: [Distutils] [Catalog-sig] HTML in long description
In-Reply-To: <slrnh9794a.27d0.reinout@isengrim.local>
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
	<op.uy1j28pq1q4jlt@whymac.activestate.com>
	<A230C638-379D-40A0-A280-E698C472A631@leidel.info>
	<slrnh9794a.27d0.reinout@isengrim.local>
Message-ID: <B41BD213-D564-422F-98E7-97F56AB49305@leidel.info>


Am 25.08.2009 um 10:44 schrieb Reinout van Rees:

> On 2009-08-24, Jannis Leidel <jannis at leidel.info> wrote:
>>
>> A lot less radical and working today:
>>
>>     http://pypi.python.org/pypi/Sphinx-PyPI-upload
>>
>> which will add an upload_sphinx command to (setuptools based)
>> setup.py, creates a zip file of your Sphinx build directory and
>> uploads it to PyPI to show up at http://packages.python.org/
>> <package>/, e.g. http://packages.python.org/django-authority/.
>
> Could you add a really quick readme to that package?  I'm unsure how  
> to use it
> and I definitively don't want to experiment with  
> packages.python.org :-)

Oh, totally. I added documentation to http://pypi.python.org/pypi/Sphinx-PyPI-upload/

Jannis

From jannis at leidel.info  Tue Aug 25 14:01:37 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 25 Aug 2009 14:01:37 +0200
Subject: [Distutils] [Catalog-sig] HTML in long description
In-Reply-To: <3F20127A-C992-4B86-9AB6-A21982EB6EF4@python.org>
References: <4A8EB02A.9070001@v.loewis.de>
	<9cee7ab80908210735l67039347w2ccd13a5e822275b@mail.gmail.com>
	<94bdd2610908210751w6e35f03ct4bac396b4c008037@mail.gmail.com>
	<4A8EB7CB.6040609@v.loewis.de>
	<op.uy1j28pq1q4jlt@whymac.activestate.com>
	<A230C638-379D-40A0-A280-E698C472A631@leidel.info>
	<slrnh9794a.27d0.reinout@isengrim.local>
	<3F20127A-C992-4B86-9AB6-A21982EB6EF4@python.org>
Message-ID: <A3C6371F-4043-45CC-85E3-6016977DAC5E@leidel.info>


Am 25.08.2009 um 12:02 schrieb Barry Warsaw:

> On Aug 25, 2009, at 4:44 AM, Reinout van Rees wrote:
>
>> On 2009-08-24, Jannis Leidel <jannis at leidel.info> wrote:
>>>
>>> A lot less radical and working today:
>>>
>>>    http://pypi.python.org/pypi/Sphinx-PyPI-upload
>>>
>>> which will add an upload_sphinx command to (setuptools based)
>>> setup.py, creates a zip file of your Sphinx build directory and
>>> uploads it to PyPI to show up at http://packages.python.org/
>>> <package>/, e.g. http://packages.python.org/django-authority/.
>>
>> Could you add a really quick readme to that package?  I'm unsure  
>> how to use it
>> and I definitively don't want to experiment with  
>> packages.python.org :-)
>
> I tried playing with this but unfortunately it doesn't seem to work  
> well with a buildout based package.  It couldn't find the directory  
> to zip and I wasn't able to use -d to do the right thing.

Would you mind opening a ticket describing what you did and what not  
worked? The issue tracker is at http://bitbucket.org/jezdez/sphinx-pypi-upload/ 
  :)

Thanks,

Jannis


From jmatejek at suse.cz  Tue Aug 25 14:19:02 2009
From: jmatejek at suse.cz (=?UTF-8?B?SmFuIE1hdMSbamVr?=)
Date: Tue, 25 Aug 2009 14:19:02 +0200
Subject: [Distutils] [Python-Dev] request for comments - standardization
 of python's purelib and platlib
In-Reply-To: <bbaeab100908201252h513b30f0l94424b89d846c103@mail.gmail.com>
References: <h61lmi$m3v$1@ger.gmane.org>
	<bbaeab100908131222u65d80e24ka4d8f1d5312a052b@mail.gmail.com>
	<94bdd2610908140102y5ef04116i52fb7071bb83aab9@mail.gmail.com>
	<4A8D1B97.4060108@ubuntu.com> <4A8D850D.7060805@novell.com>
	<bbaeab100908201252h513b30f0l94424b89d846c103@mail.gmail.com>
Message-ID: <4A93D6B6.2050205@suse.cz>



Dne 20.8.2009 21:52, Brett Cannon napsal(a):
> 2009/8/20 Jan Matejek <jan.matejek at novell.com>:
>> Dne 20.8.2009 11:47, Matthias Klose napsal(a):
>>> On 14.08.2009 10:02, Tarek Ziad? wrote:
>>>> On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett at python.org>  wrote:
>>>>>
>>>>>
>>>>> On Thu, Aug 13, 2009 at 11:23, Jan Matejek<jan.matejek at novell.com>
>>>>> wrote:
>>>> Among the proposals you have detailed, the sharedir way seems like the
>>>> most simple/interesting
>>>> one (depending on you answer to Brett's question )
>>>
>>> The approach of splitting the installation into two different locations
>>> seems to be wrong, it changes the semantics for imports of python
>>> packages which are not installed in the same location. Simplest counter
>>> example is the use of relative imports, which will fail if the imported
>>> module/extension is not found in the same paths.
>>
>> isn't using relative imports outside packages a bad practice?
>>
> 
> You actually can't do relative imports outside of packages; Python
> won't allow it.

all the better

> 
>> I'm not proposing to split installation of single package. I'm proposing
>> having two different default install locations, based on package type
>> (platform dependent/independent), not on file type.
>> Package is pure (platform independent) as long as -all- of its files are
>> pure.
>>
>> I have seen one problem so far: wxGTK's python part installs a .pth file
>> along with its purelib part, that supposedly points to its platlib
>> package. That of course breaks when purelib != platlib.
> 
> But aren't you suggesting that something like wxGTK that is impure not
> be installed in two separate locations, meaning the .pth file will
> work fine?

Situation with wxGTK is such that it contains two separate packages -
one is pure, but installs the .pth. Other is impure and apparently needs
the .pth to be enabled. That's what i consider a bug, because it relies
on all packages being installed into the same location.

> 
>> So far i would
>> consider this a bug in wxGTK, or rather relying on behavior that is not
>> well defined. But i admit that i'm not sure.
>>
> 
> I would argue it is well defined. When you install a package all of
> its files end up in a single directory, letting you make assumptions
> that a .pth file will be relative to all files you have installed.
> 
>>>
>>> Other languages like Perl or Java don't have relative imports, or they
>>> map all components on the "path" into one logical path so you don't have
>>> this kind of problem.
>>
>> and that's probably why perl approach would fail miserably in python ;)
>> unless we implemented mapping to one path. Hopefully, we probably don't
>> need to do it.
> 
> Not sure what you mean by "mapping to one path". Are you saying Perl
> basically treats all directories on its path as if it was one big
> directory? If so Python already does that with sys.path (but with a
> defined order). But as soon as you end up in a package that goes away
> as __path__ takes over (although that can be changed and is the reason
> pkgutil exists).
> 
> -Brett

As you're saying. Relative imports break the abstraction. In order to
implement the "perl approach", i.e. splitting by pure/impure files
instead of packages, we would need relative imports to support this.

But this is all just theoretical. As there doesn't seem to be any
compelling argument to go this way, let's stick with what works now.

regards
m.

From nicdumz at gmail.com  Tue Aug 25 17:30:12 2009
From: nicdumz at gmail.com (Nicolas Dumazet)
Date: Tue, 25 Aug 2009 17:30:12 +0200
Subject: [Distutils] Setup script exited with error: build/ *
	/egg/EGG-INFO/zip-safe: No such file or directory
In-Reply-To: <20090824233748.66ECC3A406B@sparrow.telecommunity.com>
References: <1f077e770908241409t27010628je2aa4502cf62b801@mail.gmail.com> 
	<20090824233748.66ECC3A406B@sparrow.telecommunity.com>
Message-ID: <1f077e770908250830u2eb6162dsc72ee822cd6c97ec@mail.gmail.com>

2009/8/25 P.J. Eby <pje at telecommunity.com>:
>
> Try:
>
> ?easy_install -eb. pyfsevents
> ?cd ./pyfsevents
> ?python -c "import setuptools; execfile('setup.py')" bdist_egg
>
> This will leave the build directories in place, and may give you better
> error information about the problem.
>

I'm afraid it does not help.
I had to remove a __file__ mention in my setup.py that would not pass
execfile(), but after that change, "easy_install pyfsevents" returns
the same aforementioned error, and when using your approach I
encounter no issues and the egg building / install scripts work
properly.

If I call a python -c "import setuptools; execfile('setup.py')"
bdist_egg -k, the dist/ * /egg/EGG-INFO/zip-safe file is available.

Any ideas?

From ziade.tarek at gmail.com  Wed Aug 26 09:07:45 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 26 Aug 2009 09:07:45 +0200
Subject: [Distutils] Distribute split final shape
Message-ID: <94bdd2610908260007w2310e556j317fdafadafff0e7@mail.gmail.com>

Hello

I've been working on bug fixes for 0.6.1, if you have some bug fixes
you'd like to see urgently fixed in this release
please let me know.

I'll also split Distribute 0.7 sometimes today and change the names,
here's the splitting I'll do

(Distribution Name / Role / Content )

- Distribution Name  = "distribute"
- Role: the core package
- Content: setuptools package renamed to distribute (minus some
  elements). root modules in setuptools will be moved to a
 "distribute.core" package so the root namespace stays empty.
 (the version comparison engine is included here)

- Distribution Name : "distribute.installer"
- Role: everything needed to install
- Content: the part of pkg_resources.py that handles version
  comparison + package_index, that gets files at pypi + easy_install.py
    + easy_install command extracted from setuptools package +  renamed
    into a "distribute.installer" package

- Distribution Name  = "distribute.resources"
- Role: everything needed to query installed packages
- Content: the part of pkg_resources.py that handles installed distribution
  querying +  renamed to "distribute.resources"

- Distribution Name  = "distribute.entrypoints"
- Role: the plugin system
 - Content: the part of pkg_resources.py that handles entry points +
    renamed to "distribute.entrypoints" package.

I'll drop then the bootstraping part we had to have for 0.6 since
the names will not conflict anymore with the Setuptools project.

Cheers
Tarek

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

From chris at simplistix.co.uk  Wed Aug 26 20:12:11 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 26 Aug 2009 19:12:11 +0100
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
 support -m
In-Reply-To: <1099b90b0908250300s70876458yc49e234fd4905784@mail.gmail.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>
Message-ID: <4A957AFB.6000801@simplistix.co.uk>

Jim Fulton wrote:
>> http://docs.python.org/library/runpy.html#module-runpy
>>
>> Hmmm, maybe it does just the right thing for -m?
> 
> Perhaps.
> 
>> In any case, any objections to me implementing this for buildout scripts?
> 
> No, but I want to review it before you merge it to trunk.
> 
>> If not, where is the actual code that generates the scripts?
> 
> In the easy_install meodule.

Okay, I'll add it to my to-do list...

...don't worry, no risk of it getting to the top anytime soon ;-)

Chris

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

From yonsy at aureal.com.pe  Thu Aug 27 02:38:46 2009
From: yonsy at aureal.com.pe (Yonsy Solis)
Date: Wed, 26 Aug 2009 19:38:46 -0500
Subject: [Distutils] virtualenv and buildout integration ?
Message-ID: <1251333526.5297.52.camel@alisah>

Hi o/

we recently began tu use virtualenv and buildout for development and
deployments in some projects (more one internal effort to convince the
ppl heads to use this for the next projects)

by now i have two ways to work.

1) create a venv and inside this create the buildout dir project.
2) create a venv and in the same venv directory create the buildout
tree.

by now i see that maybe the second option is little dangerous but we
dont use an custom interpreter and like we are a django shop, we use
djangorecipe and do bin/django shell (shell_plus with django_extensions)
to have a shell to the project.

by now both options require to do two operations, first create the
venv, activate this and after this create the buildout and run this.

i am thinking about develop an recipe/extension for buildout to:

- create a virtualenv
- activate the venv
- rerun the buildout using the ptyhon venv (bypassing the venv part)

my questions are:

1) someone think and do this first?
2) do you consider this alternative dangerous for some operation?
3) exist any plan for buildout to obtain the same isolation level than
virtualenv ? when ?
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)

well that's all by now ^^

--
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.com.pe


From gary.poster at canonical.com  Thu Aug 27 03:22:58 2009
From: gary.poster at canonical.com (Gary Poster)
Date: Wed, 26 Aug 2009 21:22:58 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1251333526.5297.52.camel@alisah>
References: <1251333526.5297.52.camel@alisah>
Message-ID: <DB395FDF-0120-449C-AF6C-1DF742BE5038@canonical.com>


On Aug 26, 2009, at 8:38 PM, Yonsy Solis wrote:

> Hi o/

hi

> 3) exist any plan for buildout to obtain the same isolation level than
> virtualenv ? when ?

I have a branch of zc.buildout that provides a number of facilities  
and approaches for working with a system Python, including this one, I  
believe.  (ViewCVS http://svn.zope.org/zc.buildout/branches/gary-support-system-python-2/ 
   or anonymous checkout http://svn.zope.org/repos/main/zc.buildout/branches/gary-support-system-python-2/) 
.  I submitted it to Jim Fulton for review a couple of weeks ago.

The branch has a lot of changes, and Jim's very busy and very  
thorough, so I don't know when it will be merged, or what it will look  
like when it is.

While it has the functionality that I believe you want (that is, you  
can entirely exclude the normal Python site-packages), we're using it  
successfully on Launchpad right now to do something similar to what  
you describe, but different.  We allow site-packages through, so we  
get system lxml and pyopenssl, for instance, but we explicitly get  
distributions via buildout for the bits that are more closely tied to  
the application, even if conflicting eggs are installed for the  
system.  We've only had the changes in place for a couple of weeks,  
but things seem to be *much* smoother with them now.

Gary

From chris at simplistix.co.uk  Thu Aug 27 09:46:07 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 27 Aug 2009 08:46:07 +0100
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <DB395FDF-0120-449C-AF6C-1DF742BE5038@canonical.com>
References: <1251333526.5297.52.camel@alisah>
	<DB395FDF-0120-449C-AF6C-1DF742BE5038@canonical.com>
Message-ID: <4A9639BF.50902@simplistix.co.uk>

Gary Poster wrote:
> 
> While it has the functionality that I believe you want (that is, you can 
> entirely exclude the normal Python site-packages), 

Cool :-)

> we're using it 
> successfully on Launchpad right now to do something similar to what you 
> describe, but different.  We allow site-packages through, so we get 
> system lxml and pyopenssl, for instance, but we explicitly get 
> distributions via buildout for the bits that are more closely tied to 
> the application, even if conflicting eggs are installed for the system.  
> We've only had the changes in place for a couple of weeks, but things 
> seem to be *much* smoother with them now.

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)?

Chris

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

From jeff at taupro.com  Thu Aug 27 12:14:20 2009
From: jeff at taupro.com (Jeff Rush)
Date: Thu, 27 Aug 2009 05:14:20 -0500
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1251333526.5297.52.camel@alisah>
References: <1251333526.5297.52.camel@alisah>
Message-ID: <4A965C7C.2000700@taupro.com>

Yonsy Solis wrote:
> 
> we recently began tu use virtualenv and buildout for development and
> deployments in some projects (more one internal effort to convince the
> ppl heads to use this for the next projects)
> 
> by now i have two ways to work.
> 
> 1) create a venv and inside this create the buildout dir project.
> 2) create a venv and in the same venv directory create the buildout
> tree.
> by now both options require to do two operations, first create the
> venv, activate this and after this create the buildout and run this.
> 
> i am thinking about develop an recipe/extension for buildout to:
> 
> - create a virtualenv
> - activate the venv
> - rerun the buildout using the ptyhon venv (bypassing the venv part)

Not quite the approach you propose but (in a french Monty Python and the
Holy Grail accent) "We're already got one." ;-)

Like you I need to initialize new projects often and tired of repeating
various steps.  One day I noticed that the virtualenv command is
extensible so I extended it to init a buildout after creating a sandbox.
 I also had it drop in some default files like a buildout.cfg with my
favorite options, license/README.txt files and the buildout bootstrap.py
that I always forget about.  The extension also changes the default
sandbox option to --no-site-packages since I use that most often.

You can find it at:

  https://www.dfwpython.org/repo/Projects/sandbox/mk_sandbox.py

To create your new command, run once with your chosen version of Python:

  $ python2.6 mk_sandbox.py
  $ cp sandbox /usr/local/bin/

now anytime I need a readymade project I run:

  $ sandbox projectx
  $ cd projectx
  (edit buildout.cfg)
  $ bin/buildout
  (make some changes)
  $ hg ci

It has some new command-line options as well.  I find it quite useful
during presentations when you need to spin up a workarea to illustrate
some concept spontaneously.

  $ sandbox --help
Usage: sandbox [OPTIONS] DEST_DIR

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         Increase verbosity
  -q, --quiet           Decrease verbosity
  -p PYTHON_EXE, --python=PYTHON_EXE
                        The Python interpreter to use, e.g.,
                        --python=python2.5 will use the python2.5
                        interpreter to create the new environment.
                        The default is the interpreter that virtualenv
                        was installed with (/usr/bin/python2.6)
  --clear               Clear out the non-root install and start from
                        scratch
  --unzip-setuptools    Unzip Setuptools when installing it
  --relocatable         Make an EXISTING virtualenv environment
                        relocatable.  This fixes up scripts and makes
                        all .pth files relative
  --site-packages       Give access to the global site-packages dir to
                        the virtual environment
  --no-buildout         Omit installing zc.buildout into the sandbox
  --no-mercurial        Omit initializing a Mercurial repository in the
                        sandbox

-Jeff


From gary.poster at canonical.com  Thu Aug 27 13:48:17 2009
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 27 Aug 2009 07:48:17 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <4A9639BF.50902@simplistix.co.uk>
References: <1251333526.5297.52.camel@alisah>
	<DB395FDF-0120-449C-AF6C-1DF742BE5038@canonical.com>
	<4A9639BF.50902@simplistix.co.uk>
Message-ID: <416D11D0-8C33-4F20-9BE6-65A4DDBF94C8@canonical.com>


On Aug 27, 2009, at 3:46 AM, Chris Withers wrote:

> Gary Poster wrote:
>> While it has the functionality that I believe you want (that is,  
>> you can entirely exclude the normal Python site-packages),
>
> Cool :-)
>
>> we're using it successfully on Launchpad right now to do something  
>> similar to what you describe, but different.  We allow site- 
>> packages through, so we get system lxml and pyopenssl, for  
>> instance, but we explicitly get distributions via buildout for the  
>> bits that are more closely tied to the application, even if  
>> conflicting eggs are installed for the system.  We've only had the  
>> changes in place for a couple of weeks, but things seem to be  
>> *much* smoother with them now.
>
> 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, 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).

Gary


From jim at zope.com  Thu Aug 27 14:36:20 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 27 Aug 2009 08:36:20 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1251333526.5297.52.camel@alisah>
References: <1251333526.5297.52.camel@alisah>
Message-ID: <1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>

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

-- 
Jim Fulton

From jon at multani.info  Fri Aug 28 11:35:07 2009
From: jon at multani.info (Jonathan Ballet)
Date: Fri, 28 Aug 2009 04:35:07 -0500
Subject: [Distutils] =?utf-8?q?Regression_in_zc=2Ebuildout_1=2E4=2E0=3F?=
Message-ID: <8088eb35075c3fa54091ae5c1931c53e@mail.webfaction.com>

Hi,

We often use the 'extends' feature of Buildout to create customized
version of configuration files per-developer or per-buildbot.

One nice feature of Buildout was that I can easily extend another
configuration file and add part to those specified in this 'base' file.
Then, if I launched the Buildout, I got all the parts from the base file
plus the one I defined in *my* configuration file. I was very happy.


Unfortunately, it seems that the new release 1.4.0 of Buildbot has broke
this feature and the new behavior seems to be: install only parts which
are *strictly* defined in the configuration file used by the Buildout,
and not the 'inherited' ones anymore.


I wrote a quick doctest which illustrate this problem (merely adapted
from other doctests):

===========================================================
Create a test recipe, which only prints itself

>>> mkdir('recipes')
>>> write('recipes', 'testrecipe.py',
... """
... import logging, os, zc.buildout
...
... class TestRecipe:
...
...     def __init__(self, buildout, name, options):
...         self.name, self.options = name, options
...
...     def install(self):
...         logging.getLogger(self.name).info(
...             'This is the test recipe which is installing!')
...         return ''
...
...     def update(self):
...         logging.getLogger(self.name).info(
...             'This is the test recipe which is updateting!')
... """)

And create a dummy package to use it:

>>> write('recipes', 'setup.py',
... """
... from setuptools import setup
...
... setup(
...     name = "recipes",
...     entry_points = {'zc.buildout':
...            ['testrecipe = testrecipe:TestRecipe']},
...     )
... """)

Now, this is a base buildout configuration file, which defines and uses
by default one part:

>>> write('base.cfg', """\
... [buildout]
... develop = recipes
... parts = base-part
... [base-part]
... recipe = recipes:testrecipe
... """)

And another buildout configuration file, which extends the base
configuration file, and add to it another part:

>>> write('buildout.cfg', """\
... [buildout]
... extends = base.cfg
... parts += buildout-part
... [buildout-part]
... recipe = recipes:testrecipe
... """)

If we run the buildout, then we should install first the part from the
base configuration file, then the part from the other buildout
configuration file:

>>> print system(buildout)
Develop: '/sample-buildout/recipes'
Installing base-part.
base-part: This is the test recipe which is installing!
Installing buildout-part.
buildout-part: This is the test recipe which is installing!
<BLANKLINE>
===========================================================


...which fails with latest versions of Buildout with:

===========================================================
File "..." line 52, in extends.txt
Failed example:
print system(buildout)
Expected:
Develop: '/sample-buildout/recipes'
Installing base-part.
base-part: This is the test recipe which is installing!
Installing buildout-part.
buildout-part: This is the test recipe which is installing!
<BLANKLINE>
Got:
Develop: '/sample-buildout/recipes'
Installing buildout-part.
buildout-part: This is the test recipe which is installing!
<BLANKLINE>
===========================================================

As you can see, the 'base-part' is not installed anymore. I bisected the
problem down to the merge of the 'tlotze-download-api' branch (the bug
didn't not occured before).

I'm not sure the behavior I expect was actually really documented (I
don't find it in the documentation) but this was nice!
Should I report a bug for this or was it a necessary change for the new
version of Buildout?


Thanks!

-Jonathan


From jim at zope.com  Fri Aug 28 12:10:09 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 28 Aug 2009 06:10:09 -0400
Subject: [Distutils] Regression in zc.buildout 1.4.0?
In-Reply-To: <8088eb35075c3fa54091ae5c1931c53e@mail.webfaction.com>
References: <8088eb35075c3fa54091ae5c1931c53e@mail.webfaction.com>
Message-ID: <1099b90b0908280310n49bd428vb210507dcca2cb58@mail.gmail.com>

On Fri, Aug 28, 2009 at 5:35 AM, Jonathan Ballet<jon at multani.info> wrote:
...
> We often use the 'extends' feature of Buildout to create customized
> version of configuration files per-developer or per-buildbot.
>
> One nice feature of Buildout was that I can easily extend another
> configuration file and add part to those specified in this 'base' file.
> Then, if I launched the Buildout, I got all the parts from the base file
> plus the one I defined in *my* configuration file. I was very happy.
>
>
> Unfortunately, it seems that the new release 1.4.0 of Buildbot has broke
> this feature and the new behavior seems to be: install only parts which
> are *strictly* defined in the configuration file used by the Buildout,
> and not the 'inherited' ones anymore.
>
>
> I wrote a quick doctest which illustrate this problem (merely adapted
> from other doctests):

...

> I'm not sure the behavior I expect was actually really documented (I
> don't find it in the documentation) but this was nice!

Sure it is:

http://pypi.python.org/pypi/zc.buildout#adding-and-removing-options

> Should I report a bug for this

Yes. It looks like we're missing a test.

> or was it a necessary change for the new
> version of Buildout?

No.

Thanks for alll of the analysis to demonstrate the problem.

Jim

-- 
Jim Fulton

From jim at zope.com  Sat Aug 29 00:59:13 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 28 Aug 2009 18:59:13 -0400
Subject: [Distutils] [buildout] zc.recipe.egg interpretters don't
	support -m
In-Reply-To: <4A957AFB.6000801@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>
Message-ID: <1099b90b0908281559o79a60910hf7aa1cb53428d226@mail.gmail.com>

On Wed, Aug 26, 2009 at 2:12 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Jim Fulton wrote:
>>>
>>> http://docs.python.org/library/runpy.html#module-runpy
>>>
>>> Hmmm, maybe it does just the right thing for -m?
>>
>> Perhaps.
>>
>>> In any case, any objections to me implementing this for buildout scripts?
>>
>> No, but I want to review it before you merge it to trunk.
>>
>>> If not, where is the actual code that generates the scripts?
>>
>> In the easy_install meodule.
>
> Okay, I'll add it to my to-do list...
>
> ...don't worry, no risk of it getting to the top anytime soon ;-)

I went ahead and implemented this in 1.4.1.

Jim

-- 
Jim Fulton

From yonsy at aureal.com.pe  Sat Aug 29 05:15:33 2009
From: yonsy at aureal.com.pe (Yonsy Solis)
Date: Fri, 28 Aug 2009 22:15:33 -0500
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: <1251515733.27075.88.camel@alisah>

On Thu, 2009-08-27 at 08:36 -0400, Jim Fulton 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 :).

this is, that the buildout will ignore the system python path ? this is
the final purpose that i want to obtain right now.

> 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.

we deploy in centos servers, with python 2.5 build from source
in /usr/local (and i am trying jython 2.5 for some apps) but we prefer
virtualenv for isolate apps.

> 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.

well, i think that i am going to write the recipe for:

1) build a virtualenv in the same buildout directory (with several
options, python interpreter version, --no-site-packages, etc)
2) activate the virtualenv
3) restart the buildout running with the python interpreter from the
buildout

i think that can be a good exercise for understand how to write recipes
for buildout. i found docs for recipe but very few for extensions, can u
give me some indications where i can search for this ?

thx in advance and i wait for 1.5 ^_^

--
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.com.pe



From yonsy at aureal.com.pe  Sat Aug 29 05:39:27 2009
From: yonsy at aureal.com.pe (Yonsy Solis)
Date: Fri, 28 Aug 2009 22:39:27 -0500
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <e5fff6640908282036ob01a40et80c88dd1294a6145@mail.gmail.com>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>
	<1251515733.27075.88.camel@alisah>
	<e5fff6640908282036ob01a40et80c88dd1294a6145@mail.gmail.com>
Message-ID: <1251517167.27075.90.camel@alisah>

On Fri, 2009-08-28 at 23:36 -0400, Benji York wrote:
> On Fri, Aug 28, 2009 at 11:15 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
> > i found docs for recipe but very few for extensions, can u
> > give me some indications where i can search for this ?
> 
> http://pypi.python.org/pypi?:action=browse&show=all&c=512

err. i refer to documentation to develop extensions, i found
documentation for develop recipes, 

btw recipes == extensions in buildout ?

--
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.com.pe


From benji at zope.com  Sat Aug 29 05:36:40 2009
From: benji at zope.com (Benji York)
Date: Fri, 28 Aug 2009 23:36:40 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1251515733.27075.88.camel@alisah>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com> 
	<1251515733.27075.88.camel@alisah>
Message-ID: <e5fff6640908282036ob01a40et80c88dd1294a6145@mail.gmail.com>

On Fri, Aug 28, 2009 at 11:15 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
> i found docs for recipe but very few for extensions, can u
> give me some indications where i can search for this ?

http://pypi.python.org/pypi?:action=browse&show=all&c=512
-- 
Benji York
Senior Software Engineer
Zope Corporation

From fwierzbicki at gmail.com  Sat Aug 29 11:49:19 2009
From: fwierzbicki at gmail.com (Frank Wierzbicki)
Date: Sat, 29 Aug 2009 05:49:19 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1251515733.27075.88.camel@alisah>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>
	<1251515733.27075.88.camel@alisah>
Message-ID: <4dab5f760908290249m7f2ced06j2097b188ae1a5740@mail.gmail.com>

On Fri, Aug 28, 2009 at 11:15 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
> we deploy in centos servers, with python 2.5 build from source
> in /usr/local (and i am trying jython 2.5 for some apps) but we prefer
> virtualenv for isolate apps.
Hi Younsy, I'd love to hear about how you do with Jython and your apps
with virtualenv, distutils, etc - especially if you run into any
trouble.

-Frank

From fwierzbicki at gmail.com  Sat Aug 29 11:50:01 2009
From: fwierzbicki at gmail.com (Frank Wierzbicki)
Date: Sat, 29 Aug 2009 05:50:01 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <4dab5f760908290249m7f2ced06j2097b188ae1a5740@mail.gmail.com>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>
	<1251515733.27075.88.camel@alisah>
	<4dab5f760908290249m7f2ced06j2097b188ae1a5740@mail.gmail.com>
Message-ID: <4dab5f760908290250n1f862d0bm308affb6476b1f7c@mail.gmail.com>

On Sat, Aug 29, 2009 at 5:49 AM, Frank Wierzbicki<fwierzbicki at gmail.com> wrote:
> On Fri, Aug 28, 2009 at 11:15 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
>> we deploy in centos servers, with python 2.5 build from source
>> in /usr/local (and i am trying jython 2.5 for some apps) but we prefer
>> virtualenv for isolate apps.
> Hi Younsy
oops, sorry Yonsy :).

-Frank

From benji at zope.com  Sat Aug 29 14:24:27 2009
From: benji at zope.com (Benji York)
Date: Sat, 29 Aug 2009 08:24:27 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <1251517167.27075.90.camel@alisah>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com> 
	<1251515733.27075.88.camel@alisah>
	<e5fff6640908282036ob01a40et80c88dd1294a6145@mail.gmail.com> 
	<1251517167.27075.90.camel@alisah>
Message-ID: <e5fff6640908290524v6ef41ce8i3b79e641e7666d7e@mail.gmail.com>

On Fri, Aug 28, 2009 at 11:39 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
> btw recipes == extensions in buildout ?

Yes.
-- 
Benji York
Senior Software Engineer
Zope Corporation

From chris at simplistix.co.uk  Mon Aug 31 13:52:36 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 31 Aug 2009 12:52:36 +0100
Subject: [Distutils] [buildout] zc.recipe.egg interpretters
 don't	support -m
In-Reply-To: <1099b90b0908281559o79a60910hf7aa1cb53428d226@mail.gmail.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>
Message-ID: <4A9BB984.6020405@simplistix.co.uk>

Jim Fulton wrote:
> On Wed, Aug 26, 2009 at 2:12 PM, Chris Withers<chris at simplistix.co.uk> wrote:
>> Jim Fulton wrote:
>>>> http://docs.python.org/library/runpy.html#module-runpy
>>>>
>>>> Hmmm, maybe it does just the right thing for -m?
>>> Perhaps.
>>>
>>>> In any case, any objections to me implementing this for buildout scripts?
>>> No, but I want to review it before you merge it to trunk.
>>>
>>>> If not, where is the actual code that generates the scripts?
>>> In the easy_install meodule.
>> Okay, I'll add it to my to-do list...
>>
>> ...don't worry, no risk of it getting to the top anytime soon ;-)
> 
> I went ahead and implemented this in 1.4.1.

Exellent, thanks :-)

...although I think there may still be some rough edges:

bin/py -m somemodule --some --options

...will throw an exception as the code in py tries to consume all the 
parameters.

"real" python only consumes the -m and passed the rest on to the script.

cheers,

Chris


From chris at simplistix.co.uk  Mon Aug 31 13:55:23 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 31 Aug 2009 12:55:23 +0100
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <94bdd2610908250248o46349e76uea66245f5ebd1173@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>
Message-ID: <4A9BBA2B.6010903@simplistix.co.uk>

Tarek Ziad? wrote:
> Here's a demo of what I was thinking of adding in Distutils:
> 
> http://bitbucket.org/tarek/staticmetadata/
> 
> It uses Mako just for the proof of concept, README.txt explains how it works
> 
> Let me know how this fits your needs,

A couple of things:

- 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.

- 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

cheers,

Chris

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

From gary.poster at canonical.com  Mon Aug 31 14:30:54 2009
From: gary.poster at canonical.com (Gary Poster)
Date: Mon, 31 Aug 2009 08:30:54 -0400
Subject: [Distutils] [buildout] zc.recipe.egg interpretters
	don't	support -m
In-Reply-To: <4A9BB984.6020405@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>
Message-ID: <5D4EBCDA-2AB4-4BD1-B2D9-B6F859036D5E@canonical.com>


On Aug 31, 2009, at 7:52 AM, Chris Withers wrote:

> Jim Fulton wrote:
>> On Wed, Aug 26, 2009 at 2:12 PM, Chris  
>> Withers<chris at simplistix.co.uk> wrote:
>>> Jim Fulton wrote:
>>>>> http://docs.python.org/library/runpy.html#module-runpy
>>>>>
>>>>> Hmmm, maybe it does just the right thing for -m?
>>>> Perhaps.
>>>>
>>>>> In any case, any objections to me implementing this for buildout  
>>>>> scripts?
>>>> No, but I want to review it before you merge it to trunk.
>>>>
>>>>> If not, where is the actual code that generates the scripts?
>>>> In the easy_install meodule.
>>> Okay, I'll add it to my to-do list...
>>>
>>> ...don't worry, no risk of it getting to the top anytime soon ;-)
>> I went ahead and implemented this in 1.4.1.
>
> Exellent, thanks :-)
>
> ...although I think there may still be some rough edges:
>
> bin/py -m somemodule --some --options
>
> ...will throw an exception as the code in py tries to consume all  
> the parameters.
>
> "real" python only consumes the -m and passed the rest on to the  
> script.

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.)

Gary

From chris at simplistix.co.uk  Mon Aug 31 14:29:16 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 31 Aug 2009 13:29:16 +0100
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <416D11D0-8C33-4F20-9BE6-65A4DDBF94C8@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>
Message-ID: <4A9BC21C.9080606@simplistix.co.uk>

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?

> 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?

Chris

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

From chris at simplistix.co.uk  Mon Aug 31 14:31:06 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 31 Aug 2009 13:31:06 +0100
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <e5fff6640908290524v6ef41ce8i3b79e641e7666d7e@mail.gmail.com>
References: <1251333526.5297.52.camel@alisah>	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com>
	<1251515733.27075.88.camel@alisah>	<e5fff6640908282036ob01a40et80c88dd1294a6145@mail.gmail.com>
	<1251517167.27075.90.camel@alisah>
	<e5fff6640908290524v6ef41ce8i3b79e641e7666d7e@mail.gmail.com>
Message-ID: <4A9BC28A.9000301@simplistix.co.uk>

Benji York wrote:
> On Fri, Aug 28, 2009 at 11:39 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
>> btw recipes == extensions in buildout ?
> 
> Yes.

No.

Buildout allows extensions as well as recipes.
Recipes are just used by buildout.
Extensions (such as lovely.buildouthttp) change how buildout works.

cheers,

Chris

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

From benji at zope.com  Mon Aug 31 14:54:03 2009
From: benji at zope.com (Benji York)
Date: Mon, 31 Aug 2009 08:54:03 -0400
Subject: [Distutils] virtualenv and buildout integration ?
In-Reply-To: <4A9BC28A.9000301@simplistix.co.uk>
References: <1251333526.5297.52.camel@alisah>
	<1099b90b0908270536o1b233febyb305bcd82b908b9@mail.gmail.com> 
	<1251515733.27075.88.camel@alisah>
	<e5fff6640908282036ob01a40et80c88dd1294a6145@mail.gmail.com> 
	<1251517167.27075.90.camel@alisah>
	<e5fff6640908290524v6ef41ce8i3b79e641e7666d7e@mail.gmail.com> 
	<4A9BC28A.9000301@simplistix.co.uk>
Message-ID: <e5fff6640908310554o63ee626em975bc0560938703f@mail.gmail.com>

On Mon, Aug 31, 2009 at 8:31 AM, Chris Withers<chris at simplistix.co.uk> wrote:
> Benji York wrote:
>>
>> On Fri, Aug 28, 2009 at 11:39 PM, Yonsy Solis<yonsy at aureal.com.pe> wrote:
>>>
>>> btw recipes == extensions in buildout ?
>>
>> Yes.
>
> No.

Indeed!  I forgot about the "extensions=" functionality.

Yonsy, it is documented at http://pypi.python.org/pypi/zc.buildout#extensions.
-- 
Benji York
Senior Software Engineer
Zope Corporation

From ziade.tarek at gmail.com  Mon Aug 31 15:37:57 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 31 Aug 2009 15:37:57 +0200
Subject: [Distutils] Static metadata using setup.cfg
In-Reply-To: <4A9BBA2B.6010903@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>
Message-ID: <94bdd2610908310637r17af992al469498e90544c5e0@mail.gmail.com>

On Mon, Aug 31, 2009 at 1:55 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> Here's a demo of what I was thinking of adding in Distutils:
>>
>> http://bitbucket.org/tarek/staticmetadata/
>>
>> It uses Mako just for the proof of concept, README.txt explains how it
>> works
>>
>> Let me know how this fits your needs,
>
> A couple of things:
>
> - 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

>
> - 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


Cheers
Tarek


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



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