On 06/20/2012 11:57 PM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 3:29 AM, PJ Eby wrote:
On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan wrote:
On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou
wrote:
Agreed, especially if the "proven in the wild" criterion is required
(people won't rush to a
On Thu, Jun 21, 2012 at 3:29 AM, PJ Eby wrote:
> On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan wrote:
>>
>> On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou
>> wrote:
>> > Agreed, especially if the "proven in the wild" criterion is required
>> > (people won't rush to another third-party distutils
Hi Carl,
Thanks for clarifying this.
This means that indeed we have the same goals. I'll have a closer look
at the internal pip APIs, as they are probably really useful and already
used in production environment :)
___
Python-Dev mailing list
Python
On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou
> wrote:
> > Agreed, especially if the "proven in the wild" criterion is required
> > (people won't rush to another third-party distutils replacement, IMHO).
>
> The existence of setuptools mea
Hi Alexis,
On 06/20/2012 10:57 AM, Alexis Métaireau wrote:
> Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit :
>> Thanks - as you say, it's not so much the actual problem as the
>> principle of what the packaging API offers that matters here. Although
>> it does make a good point - to what
On 20/06/2012 17:29, Paul Moore wrote:
I wasn't aware of this - I've had a look and my first thought is that
the documentation needs completing. At the moment, there's a lot that
isn't documented, and we should avoid getting into the same situation
as with distutils where people have to use undo
Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit :
Thanks - as you say, it's not so much the actual problem as the
principle of what the packaging API offers that matters here. Although
it does make a good point - to what extent do the packaging APIs draw
on existing experience like that of
As the PEP czar for 397, after Martin's final updates, I hereby
pronounce this PEP "accepted"!
Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up
the code, Martin von Loewis for recent updates, and everyone in the
community who contributed to the discussions.
I will begin integ
On 20 June 2012 17:07, Carl Meyer wrote:
> Hi Paul,
>
> On 06/20/2012 09:29 AM, Paul Moore wrote:
>> As a specific example, one thing I would like to do is to be able to
>> set up a packaging.pypi client object that lets me query and download
>> distributions. However, rather than just querying Py
On 6/20/12 5:44 PM, Georg Brandl wrote:
Am 20.06.2012 17:34, schrieb Éric Araujo:
Hi all,
Sorry I can’t take the time to reply to all messages, this week I’m
fully busy with work and moving out.
To answer or correct a few things:
- I am lacking time these months, but that’s because I’m still
Hi Paul,
On 06/20/2012 09:29 AM, Paul Moore wrote:
> As a specific example, one thing I would like to do is to be able to
> set up a packaging.pypi client object that lets me query and download
> distributions. However, rather than just querying PyPI (the default)
> I'd like to be able to set up a
Am 20.06.2012 17:34, schrieb Éric Araujo:
> Hi all,
>
> Sorry I can’t take the time to reply to all messages, this week I’m
> fully busy with work and moving out.
>
> To answer or correct a few things:
>
> - I am lacking time these months, but that’s because I’m still getting
> used to having
Am 20.06.2012 16:25, schrieb jason.coombs:
> http://hg.python.org/cpython/rev/24369f6c4a22
> changeset: 77525:24369f6c4a22
> user:Jason R. Coombs
> date:Wed Jun 20 10:24:24 2012 -0400
> summary:
> Prefer assertEqual to simply assert per recommendation in issue6727.
> Clarified
Hi all,
Sorry I can’t take the time to reply to all messages, this week I’m
fully busy with work and moving out.
To answer or correct a few things:
- I am lacking time these months, but that’s because I’m still getting
used to having a full-time job and being settled into a new country.
Wit
On 20 June 2012 14:47, Paul Moore wrote:
> On 20 June 2012 14:16, Alexis Métaireau wrote:
>> packaging.pypi is functionally working but IMO the API can (and probably
>> should) be improved (we really lack feedback to know that).
>
> I wasn't aware of this - I've had a look and my first thought is
Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou wrote:
> > Agreed, especially if the "proven in the wild" criterion is required
> > (people won't rush to another third-party distutils replacement, IMHO).
>
> The existence of setuptools means that "proven in the wild" is ne
On 20 June 2012 14:16, Alexis Métaireau wrote:
> On 20/06/2012 13:31, Tarek Ziadé wrote:
>>
>> packaging.metadata is the implementation of all metadata versions.
>> standalone too.
>>
>> packaging.pypi is the PyPI crawler, and has fairly advanced features. I
>> defer to Alexis to tell us
>> is it'
Le mer. 20 juin 2012 15:28:56 CEST, Nick Coghlan a écrit :
There would be two main parts to such a PEP:
- defining the command line interface and capabilities (pysetup)
- defining the programmatic API (packaging.pypi and the dependency
graph management)
Okay. I don't think that the command line h
On Wed, Jun 20, 2012 at 11:19 PM, Alexis Métaireau wrote:
> On 20/06/2012 14:53, Nick Coghlan wrote:
>>
>> 3.4 PEP: Standard library package downloader (pysetup)
>> --
>> # Amongst other things, this needs to have a really good security
>> story (refusing to ins
On 20/06/2012 13:31, Tarek Ziadé wrote:
packaging.metadata is the implementation of all metadata versions.
standalone too.
packaging.pypi is the PyPI crawler, and has fairly advanced features.
I defer to Alexis to tell us
is it's completely stable
packaging.pypi is functionally working but
On 20/06/2012 14:53, Nick Coghlan wrote:
3.4 PEP: Standard library package downloader (pysetup)
--
# Amongst other things, this needs to have a really good security
story (refusing to install unsigned packages by default, etc)
packaging.depgraph — Depende
On 20 June 2012 13:53, Nick Coghlan wrote:
[...]
> 3.4 PEP: Simple binary package distribution format
> --
>
> bdist_simple has been discussed enough times, finally seeing a PEP
> for it would be nice :)
I had a PEP for th
On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou wrote:
> Agreed, especially if the "proven in the wild" criterion is required
> (people won't rush to another third-party distutils replacement, IMHO).
The existence of setuptools means that "proven in the wild" is never
going to fly - a whole lot o
On 2012-06-20, at 4:30 AM, Steven D'Aprano wrote:
> On Tue, Jun 19, 2012 at 08:11:26PM -0400, Yury Selivanov wrote:
>
>> So using the signature will be OK for 'Foo.bar' and 'Foo().bar', but
>> not for 'Foo.__dict__['bar']' - which I think is fine (since
>> staticmethod & classmethod instances are
On Wed, Jun 20, 2012 at 9:31 PM, Tarek Ziadé wrote:
> Yeah maybe this subset could be left in 3.3
>
> and we'd remove packaging-the-installer part (pysetup, commands, compilers)
>
> I think it's a good idea !
OK, to turn this into a concrete suggestion based on the packaging docs.
Declare stable
On Wed, Jun 20, 2012 at 6:30 PM, Steven D'Aprano wrote:
> Speaking of non-instance method descriptors, please excuse this silly
> question, I haven't quite understood the implementation well enough to
> answer this question myself. Is there anything needed to make
> signature() work correctly with
On Wed, 20 Jun 2012 12:11:03 +0100
Paul Moore wrote:
>
> I think the first question is, do we need an enhanced distutils in the
> stdlib?
I would answer a different question: we definitely need a better
distutils/packaging story. Whether it's in the form of distutils
enhancements, or another pac
On Wed, Jun 20, 2012 at 7:22 PM, Christian Heimes wrote:
> Am 18.06.2012 17:12, schrieb Guido van Rossum:
>> Ok, banning ru"..." and ur"..." altogether is fine too (assuming it's
>> fine with the originators of the PEP).
>
> It's gone for good. http://hg.python.org/cpython/rev/8e47e9af826e
>
> (My
On Wed, 20 Jun 2012 13:20:04 +0200
Hynek Schlawack wrote:
>
> > and a lack of user interest.
>
> Maybe I'm getting you wrong here, but ISTM that proper packaging is in the
> short list on nearly everybody’s “things I wish they'd fix in Python”.
I agree, but I think people have also been burnt b
On 6/20/12 1:19 PM, Paul Moore wrote:
On 20 June 2012 11:34, Tarek Ziadé wrote:
On 6/20/12 11:54 AM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 09:51:03 + (UTC)
Vinay Sajipwrote:
Antoine Pitroupitrou.net>writes:
Deciding to remove packaging from 3.3 is another instance of the
On 06/20, Antoine Pitrou wrote:
> Let's make things clear: packaging is suffering from a lack of
> developer involvement,
Absolutely.
And to be more precise: solid hands-on leadership. Eric wrote it in his
original mail: both packaging maintainers are burned out/busy. That’s a state
that is ve
On 20 June 2012 11:34, Tarek Ziadé wrote:
> On 6/20/12 11:54 AM, Antoine Pitrou wrote:
>>
>> On Wed, 20 Jun 2012 09:51:03 + (UTC)
>> Vinay Sajip wrote:
>>>
>>> Antoine Pitrou pitrou.net> writes:
>>>
Deciding to remove packaging from 3.3 is another instance of the same
mistake, IMO
On 20 June 2012 10:12, Antoine Pitrou wrote:
> I think the whole idea that distutils should be frozen and improvements
> should only go in distutils2 has been misled. Had distutils been
> improved instead, many of those enhancements would already have been
> available in 3.2 (and others would soon
Am 20.06.2012 12:39, schrieb Antoine Pitrou:
> On Wed, 20 Jun 2012 12:30:51 +0200
> Tarek Ziadé wrote:
>>
>> >
>> > Most of the distutils2 improvements (new PEPs, setup.cfg, etc.) were
>> > totally possible in distutils, weren't they?
>> I started there, remember ? And we ended up saying it was i
On 6/20/12 12:39 PM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 12:30:51 +0200
Tarek Ziadé wrote:
Most of the distutils2 improvements (new PEPs, setup.cfg, etc.) were
totally possible in distutils, weren't they?
I started there, remember ? And we ended up saying it was impossible to
continue wi
On Wed, 20 Jun 2012 12:30:51 +0200
Tarek Ziadé wrote:
>
> >
> > Most of the distutils2 improvements (new PEPs, setup.cfg, etc.) were
> > totally possible in distutils, weren't they?
> I started there, remember ? And we ended up saying it was impossible to
> continue without
> breaking the packag
On 6/20/12 11:54 AM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 09:51:03 + (UTC)
Vinay Sajip wrote:
Antoine Pitrou pitrou.net> writes:
Deciding to remove packaging from 3.3 is another instance of the same
mistake, IMO.
What's the rationale for leaving it in, when it's known to be
incom
On 6/20/12 11:49 AM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 11:22:07 +0200
Tarek Ziadé wrote:
I tried to improve Distutils and I was stopped and told to start
distutils2, because
distutils is so rotten, any *real* change/improvment potentially brakes
the outside world.
If distutils was so r
On Wed, 20 Jun 2012 09:51:03 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> >
> > Deciding to remove packaging from 3.3 is another instance of the same
> > mistake, IMO.
> >
>
> What's the rationale for leaving it in, when it's known to be
> incomplete/unfinished?
As
On Wed, 20 Jun 2012 11:22:07 +0200
Tarek Ziadé wrote:
> I tried to improve Distutils and I was stopped and told to start
> distutils2, because
> distutils is so rotten, any *real* change/improvment potentially brakes
> the outside world.
If distutils was so rotten, distutils2 would not reuse mu
Antoine Pitrou pitrou.net> writes:
>
> Deciding to remove packaging from 3.3 is another instance of the same
> mistake, IMO.
>
What's the rationale for leaving it in, when it's known to be
incomplete/unfinished?
Regards,
Vinay Sajip
___
Python-Dev
On 6/20/12 11:12 AM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 11:05:43 +0200
Dirkjan Ochtman wrote:
On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote:
So I prefer to hold it and have a solid implementation in the stldib. The
only thing I am asking is to retain ourselves to do *anything* in
On 6/20/12 11:04 AM, Antoine Pitrou wrote:
On Wed, 20 Jun 2012 15:00:52 +1000
Nick Coghlan wrote:
On Wed, Jun 20, 2012 at 11:23 AM, Antoine Pitrou wrote:
The question is what will happen after 3.3. There doesn't seem to be a
lot of activity around the project, does it?
I think the desire is
On 6/20/12 11:05 AM, Dirkjan Ochtman wrote:
On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote:
So I prefer to hold it and have a solid implementation in the stldib. The
only thing I am asking is to retain ourselves to do *anything* in distutils
and continue to declare it frozen, because I kno
On Tue, 19 Jun 2012 21:36:35 -0700
Guido van Rossum wrote:
> Nick nailed it (again).
Let's make things clear: packaging is suffering from a lack of
developer involvement, and a lack of user interest.
What makes you think that removing packaging from 3.3, and adding the
constraint of a new PEP to
Am 18.06.2012 17:12, schrieb Guido van Rossum:
> Ok, banning ru"..." and ur"..." altogether is fine too (assuming it's
> fine with the originators of the PEP).
It's gone for good. http://hg.python.org/cpython/rev/8e47e9af826e
(My first push for a very long time. Man, that feels good!)
___
On Wed, 20 Jun 2012 11:05:43 +0200
Dirkjan Ochtman wrote:
> On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote:
> > So I prefer to hold it and have a solid implementation in the stldib. The
> > only thing I am asking is to retain ourselves to do *anything* in distutils
> > and continue to declar
On Wed, 20 Jun 2012 15:00:52 +1000
Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:23 AM, Antoine Pitrou wrote:
> > The question is what will happen after 3.3. There doesn't seem to be a
> > lot of activity around the project, does it?
>
> I think the desire is there,
What makes you think that
On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote:
> So I prefer to hold it and have a solid implementation in the stldib. The
> only thing I am asking is to retain ourselves to do *anything* in distutils
> and continue to declare it frozen, because I know it will be tempting to do
> stuff there
On 6/19/12 11:46 PM, Éric Araujo wrote:
...
I don’t think (a) would give us enough time; we really want a few
months (and releases) to hash out the API (most notably with the pip
and buildout developers) and clean the bdist situation. Likewise (c)
would require developer (my) time that is
On Tue, Jun 19, 2012 at 08:11:26PM -0400, Yury Selivanov wrote:
> So using the signature will be OK for 'Foo.bar' and 'Foo().bar', but
> not for 'Foo.__dict__['bar']' - which I think is fine (since
> staticmethod & classmethod instances are not callable)
There has been some talk on Python-ideas a
> This may be crazy, but just idly wondering: is there an opportunity
> for the PSF to make things better by throwing some money at it?
> Packaging appears to be one of those Hard problems, it might be a good
> investment.
Only if somebody steps forward to take the money - and somebody who can
be
On Tue, Jun 19, 2012 at 12:38:38PM -0400, Yury Selivanov wrote:
> > class Signature:
> > . . .
> > def equivalent(self, other):
> > "compares two Signatures for equality (ignores parameter names)"
> > . . .
>
> I don't think that comparing signatures will be a common operation,
> so
On Wednesday, June 20, 2012 at 2:36 AM, Victor Stinner wrote:
> What is the status of the third party module on PyPI (distutils2)?
> Does it contain all fixes done in the packaging module? Does it have
> exactly the same API? Does it support Python 2.5 to 3.3, or maybe also
> 2.4?
>
> How is the d
On Tue, Jun 19, 2012 at 11:46 PM, Éric Araujo wrote:
> I don’t think (a) would give us enough time; we really want a few months
> (and releases) to hash out the API (most notably with the pip and buildout
> developers) and clean the bdist situation. Likewise (c) would require
> developer (my) ti
Am 19.06.2012 23:46, schrieb Éric Araujo:
Thanks for the detailed explanation, Éric. Just quoting this paragraph,
since it contains the possibilities to judge:
>With beta coming, a way to deal with that unfortunate situation needs
> to be found. We could (a) grant an exception to packaging
56 matches
Mail list logo
