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
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
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
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/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/
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
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/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: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
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
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
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
>> 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
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
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 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 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
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.
>> 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 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?
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
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
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
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
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
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
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
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
> 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
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
32 matches
Mail list logo
