On Mon, 12 Oct 2009 00:17:10 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Hey
this is the PEP for setup.cfg, as requested :
http://www.python.org/dev/peps/pep-0390
Please comment,
Tarek
Can I have assistance submitting an alternate PEP?
Generally speaking you never answer any email
On 2009-10-12, P.J. Eby p...@telecommunity.com wrote:
At 08:09 AM 10/12/2009 +, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ...
allowed to persist I'm pretty grumpy right now.
Relax, take a deep breath, and then easy_install
On 2009-10-12, Hanno Schlichting ha...@hannosch.eu wrote:
Hi.
On Mon, Oct 12, 2009 at 9:10 AM, Reinout van Rees rein...@vanrees.org wrote:
- When using buildout, I get lots of warnings. The 1.4.2 isn't out yet, but
I
also won't update all old projects' pinned zc.buildout version so I'm
sstein...@gmail.com wrote:
On Oct 12, 2009, at 7:48 PM, P.J. Eby wrote:
At 07:28 PM 10/12/2009 -0400, sstein...@gmail.com wrote:
In any case, the update is not intended for people who are happy to
have Distribute, but the people who are unhappy about having to
switch, or deal with its
On Tue, 13 Oct 2009 10:36:12 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Why are you doing a similar PEP, what's the point ? You've already helped
a
bit.
Tarek,
I championed the use of static metadata on the distutils mailing list
before you picked it up. Don't you remember?
The reason
On Tue, Oct 13, 2009 at 11:16 AM, David Lyon david.l...@preisshare.net wrote:
On Tue, 13 Oct 2009 10:36:12 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Why are you doing a similar PEP, what's the point ? You've already helped
a
bit.
Tarek,
I championed the use of static metadata on the
On Tue, Oct 13, 2009 at 02:18:11AM -0400, David Lyon wrote:
This PEP proposes a change to the way that applications
and libraries are installed in python, by using a new
file called setup.info rather than setup.py. To hold
installation information.
This seems to propose a whole build system,
Peace.
*What would newcomers think?*
On Tue, Oct 13, 2009 at 1:55 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Tue, Oct 13, 2009 at 9:32 AM, Jeff Rush j...@taupro.com wrote:
The fall-down was in the testing done before the Python release and I'm
sure more testing will be done in that
Hello,
I realise I may be starting something I would prefer not to (looking at
some of the replies of the announcement of setuptools 0.6c10), so I
would like to ask that this tries to stay as a factual thing rather than
a having a go at the other.
As it seems that setuptools is not dead just
On 2009-10-13, Michael Whapples mwhapp...@aim.com wrote:
Hello,
I realise I may be starting something I would prefer not to (looking at
some of the replies of the announcement of setuptools 0.6c10), so I
would like to ask that this tries to stay as a factual thing rather than
a having a go
On Oct 13, 2009, at 3:15 AM, Reinout van Rees wrote:
On 2009-10-12, P.J. Eby p...@telecommunity.com wrote:
At 08:09 AM 10/12/2009 +, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of
infrastructure ...
allowed to persist I'm pretty grumpy right now.
On 13/10/09 13:14, Lennart Regebro wrote:
2009/10/13 Michael Whapplesmwhapp...@aim.com:
As it seems that setuptools is not dead just possibly a bit slow at being
updated, could I ask what are the aims of the various projects setuptools
and distribute (please try and keep this information
On Oct 13, 2009, at 3:32 AM, Jeff Rush wrote:
Too little, too late, no thanks, I'll just be sticking with
Distribute
from now on.
Several developers and an open development process vs a lone coder
with
a closed codebase? That's not really a choice at all...
Sorry, it doesn't look like
On Tue, Oct 13, 2009 at 02:48:34PM +0100, Michael Whapples wrote:
[...]
and I am very much now thinking to avoid
setuptools/distribute.
Nothing wrong with that, if you don't need any of the features
provided by setuptools/distribute then using them is pointless extra
dependency. I've always
2009/10/13 Michael Whapples mwhapp...@aim.com:
Distribute is a fork and a complete replacement of setuptools. Hence
you can only have one installed in each environment at once. Yes it's
a mess.
May be there's certain reasons why setuptools and distribute couldn't be
designed to coexist on a
2009/10/13 Milind Khadilkar zedobj...@gmail.com:
Peace.
What would newcomers think?
Sadly, they'd probably get precisely the correct impression :-(
Paul.
___
Distutils-SIG maillist - Distutils-SIG@python.org
Floris,
I think I have come to the same conclusion. There are a couple of
features I use from setuptools but I feel it might just be better to
produce my own custom code for that.
Michael Whapples
On -10/01/37 20:59, Floris Bruynooghe wrote:
On Tue, Oct 13, 2009 at 02:48:34PM +0100, Michael
On -10/01/37 20:59, Paul Moore wrote:
2009/10/13 Milind Khadilkarzedobj...@gmail.com:
Peace.
What would newcomers think?
Sadly, they'd probably get precisely the correct impression :-(
Exactly, what I have seen on this list for the last couple of days has finally
given me that
On Tue, Oct 13, 2009 at 12:30 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
On Tue, Oct 13, 2009 at 02:18:11AM -0400, David Lyon wrote:
This PEP proposes a change to the way that applications
and libraries are installed in python, by using a new
file called setup.info rather than
On Mon, Oct 12, 2009 at 11:34 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Mon, Oct 12, 2009 at 6:10 PM, Ian Bicking i...@colorstudy.com wrote:
If you don't have tuples or , , etc, it seems like something like
Python version 2.6 or higher is hard to express. You'd have to
enumerate 2.6,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinout van Rees wrote:
On 2009-10-09, Chris Withers ch...@simplistix.co.uk wrote:
Reinout van Rees wrote:
I'm still not 100% sure whether it is safe to put distribute in the
install_requires list of a package right now, however.
As with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers ch...@simplistix.co.uk wrote:
Reinout van Rees wrote:
- Do my libraries have to list a dependency on distribute or on
setuptools?
Everything zopish has a 'setuptools = 0.6c9'
Michael:
Either one will probably work fine. The only differences at this
point (setuptools 0.6c10 prerelease and distribute 0.6.4) are which
issues have been fixed and how they were fixed. Also they are drop-
in replacements for one another, so you can try one and then switch
to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinout van Rees wrote:
On 2009-10-08, Ian Bicking i...@colorstudy.com wrote:
So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev.
But this is annoying, you might never create a version 0.3.2 (e.g., 0.4
might be the next
On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver tsea...@palladion.com wrote:
Why? Nobody will check / enforce / understand what 'install_requires'
even means except setuptools / distribute.
To quote Toshio Kuratomi:
It's nice for people creating system packages when you specify all of the
At 01:31 PM 10/13/2009 -0400, Tres Seaver wrote:
Why?
Because the user might have, say, setuptools 0.6c8, and the package
relies on a bugfix in 0.6c9. Also, at some point, there will be an
0.7a1, with new features that some people might actually want to use.
(Some projects also actually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Bicking wrote:
On Mon, Oct 12, 2009 at 4:45 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Mon, Oct 12, 2009 at 2:29 AM, Ian Bicking i...@colorstudy.com wrote:
The grammar in Context-dependant sections indicates possible EXPR
values. Because
At 01:45 PM 10/13/2009 -0400, Tres Seaver wrote:
Reinout van Rees wrote:
On 2009-10-08, Ian Bicking i...@colorstudy.com wrote:
So after creating, say, version 0.3.1, I always mark a package
as 0.3.2dev.
But this is annoying, you might never create a version 0.3.2 (e.g., 0.4
might be the
On Tue, Oct 13, 2009 at 1:30 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinout van Rees wrote:
On 2009-10-09, Chris Withers ch...@simplistix.co.uk wrote:
Reinout van Rees wrote:
I'm still not 100% sure whether it is safe to put distribute in
I plan to add explicit buildout support for distribute. Here's a
sketch. Basically it boils down to satisfying requirements for
setuptools with distribute whenever distribute is in buildout's
working set. So, when installing a package that requires setuptools,
it will convert that requirement to
On Tue, Oct 13, 2009 at 9:02 PM, Jim Fulton j...@zope.com wrote:
I plan to add explicit buildout support for distribute. Here's a
sketch. Basically it boils down to satisfying requirements for
setuptools with distribute whenever distribute is in buildout's
working set. So, when installing a
At 02:51 PM 10/13/2009 -0400, Jim Fulton wrote:
Really the run-time
code needed to support namespace packages should be split out into a
separate package and eventually added to the standard library.
Are you volunteering? ;-)
Seriously, MvL's namespace package PEP (#382) already takes care
On Tue, Oct 13, 2009 at 9:02 PM, Jim Fulton j...@zope.com wrote:
I plan to add explicit buildout support for distribute. Here's a
sketch. Basically it boils down to satisfying requirements for
setuptools with distribute whenever distribute is in buildout's
working set. So, when installing a
On Tue, Oct 13, 2009 at 9:17 PM, Hanno Schlichting ha...@hannosch.eu wrote:
Sounds good. Tarek already implemented the separate bootstrap file
including the requirements conversion. This is currently done via
monkey-patches of buildout, which could be avoided if this finds its
way into
On Tue, Oct 13, 2009 at 3:25 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
...
Notice that the current trunk of Distribute is now changing any 'setuptools'
requirement that is tiggered using Requirement.parse and resolve APIs into
a 'distribute' one.
Ah cool.
...
So I would propose changing
On Tue, Oct 13, 2009 at 3:22 PM, P.J. Eby p...@telecommunity.com wrote:
At 02:51 PM 10/13/2009 -0400, Jim Fulton wrote:
Really the run-time
code needed to support namespace packages should be split out into a
separate package and eventually added to the standard library.
Are you
At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote:
Notice that the current trunk of Distribute is now changing any 'setuptools'
requirement that is tiggered using Requirement.parse and resolve APIs into
a 'distribute' one.
Please note that this change will cause problems for people in the
2009/10/13 P.J. Eby p...@telecommunity.com:
At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote:
Notice that the current trunk of Distribute is now changing any
'setuptools'
requirement that is tiggered using Requirement.parse and resolve APIs
into
a 'distribute' one.
Please note that this
At 09:53 PM 10/13/2009 +0200, Tarek Ziadé wrote:
2009/10/13 P.J. Eby p...@telecommunity.com:
At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote:
Notice that the current trunk of Distribute is now changing any
'setuptools'
requirement that is tiggered using Requirement.parse and resolve APIs
On Tue, Oct 13, 2009 at 10:07 PM, P.J. Eby p...@telecommunity.com wrote:
Ok sure, makes sense. We will return 'distribute' only if 'setuptools'
is from the 0.6.x series
and below.
Great. I assume that means you plan to incorporate any further bug fixes
that land in 0.6c10 (or, gods forbid,
On Tue, 13 Oct 2009 19:01:30 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
If wanted, I can go ahead I create a new PEP for David's proposal. And
David can work it out
using PEP 390 references maybe
let me know
Thank you Tarek,
I appreciate it.
Good management decision :-)
David
On Tue, Oct 13, 2009 at 11:20 PM, David Lyon david.l...@preisshare.net wrote:
On Tue, 13 Oct 2009 19:01:30 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
If wanted, I can go ahead I create a new PEP for David's proposal. And
David can work it out
using PEP 390 references maybe
let me know
On Wed, 14 Oct 2009 00:36:54 +0100, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
To me it would seem a little early to start a PEP like this, there's
been virtually no discussion about this particular proposal nor any
proof of concept code. And given the scope of wanting to change the
On Tue, 13 Oct 2009 11:30:21 +0100, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
This seems to propose a whole build system, while PEP390 only aims for
static metadata.
It's not a whole new build system, but potentially a whole new install
system.
There's a big difference.
However,
On Tue, Oct 13, 2009 at 6:36 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
To me it would seem a little early to start a PEP like this, there's
been virtually no discussion about this particular proposal nor any
proof of concept code. And given the scope of wanting to change the
Ian Bicking wrote:
On Tue, Oct 13, 2009 at 6:36 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
To me it would seem a little early to start a PEP like this, there's
been virtually no discussion about this particular proposal nor any
proof of concept code. And given the scope of
On Tue, 13 Oct 2009 22:05:25 -0500, Ian Bicking i...@colorstudy.com
wrote:
Could an example API be encapsulated in something like this in setup.py?
from test_this_pep import setup_cfg
setup(other args, **setup_cfg())
Then packages could be converted to test it out, without breaking
47 matches
Mail list logo
