2009/7/6 P.J. Eby :
> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> But if it's based on PEP 302 protocols and if the pkgutil code works
>> with the sys.meta_path hook,
>> setuptools could then provide its loader, based on its EggFormats and
>> act as a provider without being broken.
>
> You
I'm -1 on changing the name. For better or worse setuptools is the
elephant in the room w.r.t. package management and it would IMHO be
better to stay compatible (even if the stdlib only implements a subset
of setuptools/pkg_resources)
Ronald
On 5 jul 2009, at 23:10, Nick Coghlan wrote:
2009/7/6 Paul Moore :
> 2009/7/6 P.J. Eby :
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>>
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based on its EggFormats and
>>> act as a provider
2009/7/6 Ronald Oussoren :
> I'm -1 on changing the name. For better or worse setuptools is the elephant
> in the room w.r.t. package management and it would IMHO be better to stay
> compatible (even if the stdlib only implements a subset of
> setuptools/pkg_resources)
>
I'd rather see the elephan
2009/7/6 Tarek Ziadé :
> 2009/7/6 Ronald Oussoren :
>> I'm -1 on changing the name. For better or worse setuptools is the elephant
>> in the room w.r.t. package management and it would IMHO be better to stay
>> compatible (even if the stdlib only implements a subset of
>> setuptools/pkg_resources)
P.J. Eby wrote:
> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>> But if it's based on PEP 302 protocols and if the pkgutil code works
>> with the sys.meta_path hook,
>> setuptools could then provide its loader, based on its EggFormats and
>> act as a provider without being broken.
>
> You misun
Dirkjan Ochtman wrote:
> In response to some rumblings on python-committers and just to request
> more feedback, a progress report. I know it's long, I've tried to put
> to keep it concise and chunked, though.
Two things:
* We need some form of documentation of how committers are expected
to
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based on its EggFormats and
>>> act as a provider witho
On Mon, Jul 6, 2009 at 5:14 PM, Paul Moore wrote:
> [...]
> And yet, given that PEP 376 is explicitly being designed with a goal
> being to act as the common standard that *all* package management
> formats can use, is it not the whole point that once it's defined and
> we have achieved consensus,
2009/7/6 Tarek Ziadé :
> why can't we just go ahead and continue the work as we started with PEP 376,
> introducing your work on PEP 302-like behavior.
>
> Then if we get a consensus on this PEP and introduce it in 2.7/3.2,
> setuptools will have to follow this consensus.
Essentially, because when
On Mon, Jul 6, 2009 at 5:53 PM, Paul Moore wrote:
> 2009/7/6 Tarek Ziadé :
>> why can't we just go ahead and continue the work as we started with PEP 376,
>> introducing your work on PEP 302-like behavior.
>>
>> Then if we get a consensus on this PEP and introduce it in 2.7/3.2,
>> setuptools will
At 10:32 AM 7/6/2009 +0100, Paul Moore wrote:
I'm +0 on changing the name, as long as it's the *only* "do it this
way because setuptools isn't going to change" issue.
Please note that I never said that. I was the one who suggested
".pydist", remember?
I just don't want to have to complicate
At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based o
On Wed, 17 Nov 2004, Peter Astrand wrote,
> I've made a patch (attached) to subprocess.py (and test_subprocess.py)
> that should guard against EINTR, but I haven't committed it yet. It's
> quite large.
>
> Are Python modules supposed to handle EINTR? Why not let the C code handle
> this? Or, perha
On Mon, Jul 6, 2009 at 6:58 PM, P.J. Eby wrote:
>> My site-packages has a confusing mix of egginfo directories and files.
>> Note that I NEVER use setuptools other than where an existing
>> package's setup.py requires it. In that case, I still only do python
>> setup.py bdist_wininst and install th
At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:
>> So is PEP 376 going to be able to cope with the stuff I have installed
>> at the moment? If not, what's the point???
>
> If I understand Tarek's proposal correctly, then no, it will not cope.
Why that ? Can you detail ? On a system that uses only
2009/7/6 P.J. Eby :
> At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
>> This is getting confusing. Is Phillip saying that setuptools will cope
>> with the file changing to a directory without modification, but it
>> can't handle a change in the name?
>
> The existing versions of setuptools will read
On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg wrote:
> Dirkjan Ochtman wrote:
> > In response to some rumblings on python-committers and just to request
> > more feedback, a progress report. I know it's long, I've tried to put
> > to keep it concise and chunked, though.
>
> Two things:
>
> * We ne
2009/7/6 P.J. Eby :
> At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:
>>
>> >> So is PEP 376 going to be able to cope with the stuff I have installed
>> >> at the moment? If not, what's the point???
>> >
>> > If I understand Tarek's proposal correctly, then no, it will not cope.
>>
>> Why that ? Can
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
- What precisely are the use cases for absolute path names? Concrete
examples are needed. With the current spec, some things can go wrong
(e.g., see below), so we need real u
On Wed, 17 Nov 2004, Peter Astrand wrote,
> I've made a patch (attached) to subprocess.py (and test_subprocess.py)
> that should guard against EINTR, but I haven't committed it yet. It's
> quite large.
>
> Are Python modules supposed to handle EINTR? Why not let the C code handle
> this? Or, perha
Since no one objected, I will give Dirkjan commit privs so he can work on
the hg migration. Now I just need you, Dirkjan, to get a contributor
agreement sent in and then send python-dev your SSH2 key and we will get you
set up.
On Thu, Jul 2, 2009 at 13:08, Brett Cannon wrote:
>
>
> On Thu, Jul 2
On Mon, Jul 06, 2009, Hatem Nassrat wrote:
> On Wed, 17 Nov 2004, Peter Astrand wrote,
>>
>> I've made a patch (attached) to subprocess.py (and test_subprocess.py)
>> that should guard against EINTR, but I haven't committed it yet. It's
>> quite large.
>>
>> Are Python modules supposed to handle E
At 07:15 PM 7/6/2009 +0100, Paul Moore wrote:
My point was that distributions which use setuptools in their
setup.py, *even if there's no runtime dependency on setuptools* end up
with non-standard .egg-info's. There is no good reason for this, from
my POV as a package user. So if setuptools is br
At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
+1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of
stuff as.)
- What precisely are the use cases for
M.-A. Lemburg wrote:
> Dirkjan Ochtman wrote:
> * Our tracker, checkin messages, online documentation and lots of
>Python resources on the web are full of references to the
>Subversion rXYZ notation of changesets.
>
>The PEP has to provide some way to gracefully provide a redirect
>
P.J. Eby wrote:
> So, I'm +1 for no change (obviously), and +0 for "always .pydist in 3.x
> and always .egg-info in 2.x", whether the latter part is achieved by
> making distutils/pkgutil use a version-dependent extension, or by
> refusing to backport distutils/pkgutil to 2.x. I'm -1 for having
>
(I cancelled sending this the first time, so apologies if a half-written
version turns up)
Paul Moore wrote:
> As promised, here are some open questions on PEP 376.
I'd add one more question to the list: is allowing backslash separated
names in the RECORD file actually a good idea, or would it be
> I suggest that we also run a version of that redirection filter to remap
> the old svn.python.org links in addition to making them accessible
> through hg.python.org as Dirkjan proposed.
Not sure what links you are talking about, but we also need to keep the
current svn.python.org up as-is, for
Martin v. Löwis wrote:
>> I suggest that we also run a version of that redirection filter to remap
>> the old svn.python.org links in addition to making them accessible
>> through hg.python.org as Dirkjan proposed.
>
> Not sure what links you are talking about, but we also need to keep the
> curre
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> So, I'm +1 for no change (obviously), and +0 for "always .pydist in 3.x
>> and always .egg-info in 2.x", whether the latter part is achieved by
>> making distutils/pkgutil use a version-dependent extension, or by
>> refusing to backport distutils/pkgutil
2009/7/6 P.J. Eby :
> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>
>> As promised, here are some open questions on PEP 376.
>>
>> - Will the public API names be changed from *egginfo* to *metadata*?
>
> +1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of stuff
> as.)
Thanks.
2009/7/6 Nick Coghlan :
> I'd add one more question to the list: is allowing backslash separated
> names in the RECORD file actually a good idea, or would it be better to
> always use forward slashes?
They do always use forward slashes.
> For the other questions, I don't have anything much to add
Paul Moore writes:
> In fact, the above strongly suggests to me that PEP 376 must NOT
> follow setuptools conventions - otherwise, it will end up clashing
> with the files setuptools is putting on my system.
I think the argument for a separate ‘.pydist’ metadata directory,
normative in PEP 376,
34 matches
Mail list logo
