But as I said earlier, if we use a PEP 302-like loader, distutils will
be able to consume
several loaders, so setuptools will be able to provide its storage
strategy (naming and egg dir locations)
So I don't understand why you are saying that it will be incompatible
or get confused.
2009/7/6 P.J
> I do want to help, but I believe I'll only have time a week from now.
> If we need/want Roundup tweaks to go with Mercurial, I can work on
> that (keep in mind we have a cool GSoC student working on
> Mercurial-Roundup integration, and I'm willing to work on our needs
> with him).
I think that's
At 07:10 AM 7/6/2009 +1000, Nick Coghlan wrote:
By using a new name for the
directory we *guarantee* that old packaging utilities won't get confused
by the new format (they simply won't acknowledge its existence).
This is incorrect; they will get confused because they will think
that the relev
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 misunderstand me. The whole point o
Nick Coghlan writes:
> 'pydist': accurate, specific and without the disadvantages of the 'egg'
> jargon
>
> PJE points out that existing tools (setuptools, pip, etc) won't be
> compatible with the new format at all if it uses a new name, but I am
> having trouble seeing that as a *bad* thing. By
2009/7/5 P.J. Eby :
> At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> The loader would still work with "DIST_NAME.egg-info" directories for
>> compatibility with
>> existing format in the query APIs, but the Distutils install command
>> would rather create "DIST_NAME.metadata"
>
> Note that t
Tarek Ziadé wrote:
> 2009/7/5 P.J. Eby :
>> If you want a
>> clearer name, '.pydist' or some such would at least be reasonably specific.
>> (It'd still have a backward compatibility problem, but at least then
>> there'd be some benefit to the name change.)
>
> I do find "DIST_NAME.metadata" well
Martin v. Löwis wrote:
> What will need debate and discussion in the PEP is the workflow, ie.
> the order in which changes should be applied to the branches.
Particularly since there isn't even "one true workflow" *now*. I see
three main variants go by on Python-checkins:
- svnmerge based
- com
Hi Martin,
"Martin v. Löwis" wrote:
> In this thread, I'd like to collect things that ought to be done
> but where Dirkjan has indicated that he would prefer if somebody else
> did it.
>
> So far, I have only one item: build identification. If you want to work
> on this, please either provide a pa
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
So far, I have only one item: build identification. If you want to work
on this, please either provide a patch (for trunk and/or py3k), or
(if you are a co
2009/7/5 average :
>>> Is it really that confusing? I have never heard of anyone asking "what
>>> is py3k?"
>>
>> Do you read python-list? It has been asked. Also, some people seem to
>> think that py3k is different from python 3.
>
> Personally, I vote for keeping the "3k" for 3000 (or is it 3072?
>> Is it really that confusing? I have never heard of anyone asking "what
>> is py3k?"
>
> Do you read python-list? It has been asked. Also, some people seem to
> think that py3k is different from python 3.
Personally, I vote for keeping the "3k" for 3000 (or is it 3072?). I
believe that py3k rep
2009/7/5 Tarek Ziadé :
> 2009/7/5 Paul Moore :
>> The PEP says:
>>
>> """
>> get_egginfo_files(local=False) -> iterator of paths
>>
>> Iterates over the RECORD entries and return paths for each line if the
>> path is pointing a file located in the .egg-info directory or one of
>> its subdirectory.
2009/7/5 P.J. Eby :
> At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:
>>
>> def get_distribution(name):
>> for d in get_distributions():
>> if d.name == name:
>> return d
>> return None
>
> Btw, this is broken code anyway, because it's not handling
> case-insensitivity or name
2009/7/5 P.J. Eby :
> At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> The loader would still work with "DIST_NAME.egg-info" directories for
>> compatibility with
>> existing format in the query APIs, but the Distutils install command
>> would rather create "DIST_NAME.metadata"
>
> Note that t
2009/7/5 P.J. Eby :
> At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:
>>
>> def get_distribution(name):
>> for d in get_distributions():
>> if d.name == name:
>> return d
>> return None
>
> Btw, this is broken code anyway, because it's not handling
> case-insensitivity or name
At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
The loader would still work with "DIST_NAME.egg-info" directories for
compatibility with
existing format in the query APIs, but the Distutils install command
would rather create "DIST_NAME.metadata"
Note that this would then break setuptools witho
2009/7/5 Paul Moore :
> The PEP says:
>
> """
> get_egginfo_files(local=False) -> iterator of paths
>
> Iterates over the RECORD entries and return paths for each line if the
> path is pointing a file located in the .egg-info directory or one of
> its subdirectory.
> """
>
> Should this method real
At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:
def get_distribution(name):
for d in get_distributions():
if d.name == name:
return d
return None
Btw, this is broken code anyway, because it's not handling
case-insensitivity or name canonicalization. (I've mentioned t
>> In proposing such a workflow, consider these requirements:
>
> It seems that there is a consensus to separate the 2.x and 3.x repos,
> and that also makes sense to me.
(I think) I wasn't primarily talking about the representation of
branches in hg - to that, I fully trust recommendations from
Bringing python-dev into the discussion at Barry's request. The
summary is that a recent change to unittest.TestProgram breaks nose by
moving self.testRunner initialization from it's old home in
TestProgram.runTests to TestProgram.__init__. The very small patch
attached to the ticket moves it back
The PEP says:
"""
get_egginfo_files(local=False) -> iterator of paths
Iterates over the RECORD entries and return paths for each line if the
path is pointing a file located in the .egg-info directory or one of
its subdirectory.
"""
Should this method really only return filenames noted in the REC
Georg Brandl writes:
> What I really want to see is the common-subset approach for
> maintenance branches.
IMO, this unfortunately unlikely to work as you seem to expect, for a
two technical reasons and for a social reason. The first technical
reason is that a maintenance branch really is a br
On Sun, Jul 5, 2009 at 3:27 PM, Paul Moore wrote:
>>
>> A concrete proposal would be to take back your proposal, but return
>> tuples with the location as the first member.
>> e.g. "(location, relative path[s])"
>
> That sounds reasonable. So we can forget the "local" parameter, and
> return a tupl
2009/7/5 Tarek Ziadé :
> Agreed, the zip case was added afterwards, but in practice, the APIs are still
> dealing with the files are *filesystem files* located in a container (eg a
> directory
> or a zip file) located somewhere on the filesystem.
>
> "local" in that case is a flag that means "tran
On Sun, Jul 5, 2009 at 3:13 PM, Paul Moore wrote:
> 2009/7/5 Tarek Ziadé :
>> Go for it please, and let me know if you set a bitbucket account, so
>> you can push your commits in there directly
>
> My bitbucket account is 'pmoore'.
You're set.
___
Python
2009/7/4 Brett Cannon :
>>
>> P.S. +lots on using 'metadata' in the PEP 376 method names rather than
>> the jargon 'egginfo'. Jargon isn't always bad, but using it seems fairly
>> gratuitous in this case.
>
> Ditto from here. Plus I have an aversion to terminology that goes down the
> reptile route
2009/7/5 Tarek Ziadé :
> Go for it please, and let me know if you set a bitbucket account, so
> you can push your commits in there directly
My bitbucket account is 'pmoore'.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
On Sat, Jul 4, 2009 at 3:04 PM, Paul Moore wrote:
> 2009/7/3 Tarek Ziadé :
>> 2009/7/3 Paul Moore :
>>> Does this sound sensible? Tarek, would you be OK with me attempting to
>>> modify your prototype to support this protocol? Are there any tests
>>> for PEP 376, so that I can confirm I haven't com
2009/7/4 Paul Moore :
> 2009/7/4 Paul Moore :
>> 2009/7/3 Tarek Ziadé :
>>> You can give me a bitbucket account so I can give you write access to the
>>> repo,
>>> There are tests as long as you install Nose.
>>
>> How do I get the tests to work? Just running nosetests gives an error
>> (probably
Martin v. Löwis schrieb:
>> It will handle it, for sure, but I think it would all go easier if we
>> could work with stricter subset branches (and leave the effective
>> cherrypicking for the occasional problem).
>
> So I think the PEP should propose a workflow (or: merge flow) if you
> think we w
Martin v. Löwis schrieb:
>> We could add another value in the tuple that specifies the VCS:
>> ('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that
>> VCSs are not universally the same, but the concept of a revision is
>> universal.
>
> Actually, I think that's not the case. For b
32 matches
Mail list logo
