Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote: > Although this has come up in the past, I don't recall a resolution. > > What is your plan to handle svn:eol-style?  We have some files in the tree > which need that support and it isn't clear to me how that would work with > the existing win32text

Re: [Python-Dev] PEP 376

On 2009-06-22 at 14:23, Tarek Ziadé wrote: Hello, We have polished out PEP 376 and its code prototype at Distutils-SIG. It seems to fullfill now all the requirements, so I am mailing it here again, for a new round of feedback, if needed. Hello. I have read the current version of the PEP fro

[Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman writes: > Mercurial has two basic ways of using branches: cloned branches, where > each branch is kept in a separate repository, and named branches, > where each revision keeps metadata to note on which branch it belongs. > The former makes it easier to distinguish branches, at

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 9:28 PM, Dirkjan Ochtman wrote: On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote: Although this has come up in the past, I don't recall a resolution. What is your plan to handle svn:eol-style? We have some files in the tree which need that support and it isn't clear to me how

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote: > So we must work without effective EOL support?  I fear we will end up like > the mozilla hg repo with some files in windows line endings and some with > linux.  While my editing tools are good enough to preserve existing EOL > styles, I've found m

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote: > I'll have to try them again now that 1.3 is out, but I found Mercurial > named branches fundamentally unsuited to release management. Can you explain why, please? It's not clear from what you say below. > Ditto named branches.  The proble

Re: [Python-Dev] PEP 376

2009/7/3 Łukasz Langa : > > On 2009-06-22 at 14:23, Tarek Ziadé wrote: > >> Hello, >> >> We have polished out PEP 376 and its code prototype at Distutils-SIG. >> It seems to fullfill now all the requirements, >> so I am mailing it here again, for a new round of feedback, if needed. > > > Hello. > I

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Mark Hammond wrote: > So we must work without effective EOL support? I fear we will end up > like the mozilla hg repo with some files in windows line endings and > some with linux. While my editing tools are good enough to preserve > existing EOL styles, I've found myself accidentally checking in

Re: [Python-Dev] PEP 376

Paul Moore wrote: > To be honest, this is a major can of worms. But if PEP 376 is not > going to support PEP 302, then it must state that fact explicitly, to > avoid giving people false expectations - particularly with Brett's > importlib in Python 3.1, which will make it far easier for people to >

Re: [Python-Dev] PEP 376

2009/7/3 Paul Moore : > This is a good point. Distutils only installs files in the filesystem > - it has no facilities for installing packages based on any other sort > of PEP 302 based importers. Hence, PEP 376 in principle should only > relate to filesystem-based distributions. But it also mentio

Re: [Python-Dev] PEP 376

On Fri, Jul 3, 2009 at 4:28 PM, Nick Coghlan wrote: > I will note (and I believe this is also the main point that Lukasz was > making) that having the distribution metadata outside the distribution > as currently proposed in PEP 376 is going to make any eventual PEP 302 > integration much harder -

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman schrieb: > - Fifth, here's a list of things, off the top of my head, that still need > doing: > > * Get agreement on branch strategy and branch processing (list of > branches + proposed handling at > http://hg.python.org/pymigr/file/tip/all-branches.txt) <--- PLEASE > REVIEW Do

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (06/26/09 - 07/03/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2231 open (+26) / 16000 closed (+38) / 18231 total (+64) Open issues with patches: 890 Average

Re: [Python-Dev] PEP 376

2009/7/3 Tarek Ziadé : > On Fri, Jul 3, 2009 at 4:28 PM, Nick Coghlan wrote: >> I will note (and I believe this is also the main point that Lukasz was >> making) that having the distribution metadata outside the distribution >> as currently proposed in PEP 376 is going to make any eventual PEP 302

Re: [Python-Dev] PEP 376

At 02:54 PM 7/3/2009 +0100, Paul Moore wrote: Eggs are fundamentally a PEP 302 zip file format. There are some extra bits of metadata for setuptools/easy_install in there (as I understand things) but essentially they are zip files. When you say "decoupling the egg format", I assume you mean "de

Re: [Python-Dev] PEP 376

2009/7/3 Nick Coghlan : > I agree that even if the reference implementation of PEP 376 only > handles normal directories and zipfiles, the PEP itself needs to explain > how the developer of a custom PEP 302 importer or loader can hook into > the mechanism in order to provide metadata that distutils

Re: [Python-Dev] PEP 376

2009/7/3 P.J. Eby : > Well, we could always resurrect PEP 365, since pkg_resources already has > documented extensible support for arbitrary importers.  That solves backward > *and* forward compatibility.  Then PEP 376's uninstall facilities could be > implemented using pkg_resources' existing meta

Re: [Python-Dev] PEP 376

At 12:28 AM 7/4/2009 +1000, Nick Coghlan wrote: I suspect this limitation of the PEP 302 APIs is the origin of the setuptools format that embeds the metadata inside the distribution - it lets you get at the metadata without having to assume that it exists directly on the filesystem anywhere. I

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Thu, Jul 2, 2009 at 13:42, 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. > > - First of all, I've got the basic conversion down, I

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) repo might live at http://hg.python.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Terry Reedy wrote: Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) repo might live

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 03, 2009, Brett Cannon wrote: > > Should we consider adding a sys.revision attribute and begin the deprecation > of sys.subversion? +1 -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "as long as we like the same operating system, things are cool." --p

[Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

This post basically follows on from the previous thread about PEP 376 (Changing the .egg-info structure) where it was pointed out that the PEP doesn't cover PEP 302 import hooks (except in the explicit special case of zip files). This is likely to be a fairly long posting, but I'd like to try and c

Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

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 completely broken > something? If I can, I'll knock up some simple prototype importers

Re: [Python-Dev] PEP 376

On Fri, Jul 3, 2009 at 7:02 PM, P.J. Eby wrote: > At 02:54 PM 7/3/2009 +0100, Paul Moore wrote: >> >> Eggs are fundamentally a PEP 302 zip file format. There are some extra >> bits of metadata for setuptools/easy_install in there (as I understand >> things) but essentially they are zip files. When

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> So we must work without effective EOL support? If that's the case (i.e. no effective EOL support, the way svn supported it), then I think the PEP should make that clear (e.g. in a discussion section). For the server-side hooks: it would be good to know exactly what they check, wrt. line endings

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> 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 would be better off with a differen

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> Should we consider adding a sys.revision attribute and begin the > deprecation of sys.subversion? I wouldn't mind killing sys.subversion "right away" (i.e. in trunk and 3k - obviously it has to stay in 2.6 and 3.1, and all the older branches). I'm -1 on calling it "sys.revision", as this makes

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

MRAB wrote: Terry Reedy wrote: Dirkjan Ochtman wrote: It needs to be decided where the hg repositories will live. I'd like to propose to keep the hgwebdir instance at hg.python.org. This is an accepted standard for many organizations, and an easy parallel to svn.python.org. The 2.7 (trunk) rep

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

>> This is exactly why I was asking for your advice - I can't work out how to >> work effectively with win32text as it stands myself, so remain stuck >> accidently checking in files with inappropriate line endings and stuck >> working out how to move pywin32's CVS repo with abandoning the very >> p

[Python-Dev] 3.1 buildbots

I have now turned the 3.0 buildbots off, and created new builders for 3.1. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-de

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 14:00, "Martin v. Löwis" wrote: > > Should we consider adding a sys.revision attribute and begin the > > deprecation of sys.subversion? > > I wouldn't mind killing sys.subversion "right away" (i.e. in trunk > and 3k - obviously it has to stay in 2.6 and 3.1, and all the old

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 11:22, Terry Reedy wrote: > Dirkjan Ochtman wrote: > > It needs to be decided where the hg repositories will live. I'd like >> to propose to keep the hgwebdir instance at hg.python.org. This is an >> accepted standard for many organizations, and an easy parallel to >> svn.

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> 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 bzr, the usual way of identifying

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 14:52, "Martin v. Löwis" wrote: > > 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,

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> So are you saying we should drop the idea of a revision value > altogether, or just embrace the differences and add a sys.mercurial > attribute? That's what I would propose. It should be a best-effort(*) approach at providing all information that is needed to really find the source used for the

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 23:41, Brett Cannon wrote: > If we make it universal I say it should be '2.x' and '3.x'. The whole 'py' > prefix is redundant. Right, I was aiming for /python/2.x and /python/3.x as well. Actually, I currently have /cpython to also make CPython less special among it's peers

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Fri, Jul 3, 2009 at 15:00, Dirkjan Ochtman wrote: > On Fri, Jul 3, 2009 at 23:41, Brett Cannon wrote: > > If we make it universal I say it should be '2.x' and '3.x'. The whole > 'py' > > prefix is redundant. > > Right, I was aiming for /python/2.x and /python/3.x as well. > > Actually, I curre

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote: I'm -1 on calling it "sys.revision", as this makes it difficult to tell what the actual versioning system was, and hence how the data should be interpreted. It will already be a problem for 2.6, when 2.6.3 will currently have a sys.subversion[2]

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> - First of all, I've got the basic conversion down, I've done it a few > times now, with progressively better results. You can view some > results at http://hg.python.org/, which has a preliminary cpython > repository. *** The changeset hashes for that repo will change, so you > won't be able to

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Barry Warsaw wrote: > On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote: > >> I'm -1 on calling it "sys.revision", as this makes it difficult to >> tell what the actual versioning system was, and hence how the >> data should be interpreted. It will already be a problem for 2.6, >> when 2.6.3 will

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Jul 3, 2009, at 6:15 PM, Martin v. Löwis wrote: I'm fine with that plan - but the original problem remains. We will surely release 2.6.4 at some point, and it will have a different version identification (based on hg rev ids). So those existing applications (which are probably few) will t

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 4/07/2009 12:04 AM, Nick Coghlan wrote: However, I expect that would still be painful to work with for Windows developers, even if it prevented any line ending problems from making their way into the main repository. I believe that is where the win32text extensions can help. Looking at the Wi

Re: [Python-Dev] PEP 376

Tarek Ziadé wrote: > On Thu, Jul 2, 2009 at 5:44 AM, Stephen J. Turnbull wrote: >> Another general principle: even in the draft PEP, say "is", not "will >> be". > > Ok I'll fix that. That's a French stuff : in french, "will be" isn't > speculative at all. > I don't think "will be" is necessarily

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote: On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote: So we must work without effective EOL support? I fear we will end up like the mozilla hg repo with some files in windows line endings and some with linux. While my editing tools are good enough to

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

> Doesn't Mercurial support an Subversion bridge? Would it be possible to > provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6, > and 3.1? If so, then the release managers would simply have to cut > their releases from the svn copy instead of the hg master. /All/ other > wor

Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

Tarek Ziadé wrote: > 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 completely broken >> something? If I can, I'll knock up some si

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Mark Hammond wrote: > On 4/07/2009 12:04 AM, Nick Coghlan wrote: > The big problem I have with win32text is that the rules are not > versioned, meaning we will rely on every (windows only?) developer > manually enabling the win32text extension, then manually adding these > rules to an unversioned h

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote: As long as the difference between \r\n- and \n-based files is clear and can be reasoned about, I don't see why having some of both (I'm assuming an overwhelming majority will have one, and only a few the other) is a big problem. But feel free to enli

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Brett Cannon wrote: > On Fri, Jul 3, 2009 at 15:00, Dirkjan Ochtman > wrote: > Actually, I currently have /cpython to also make CPython less special > among it's peers, but that idea was met with some resistance on > #python-dev. > > Don't worry about doing

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 4/07/2009 11:20 AM, Nick Coghlan wrote: I didn't realise Mercurial didn't have a way for a repository to provide versioned extension settings, but in this case I think using our own server side hook can deal with the problem (either adding it to the existing whitespace hook that checks for ta

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: > I would drop the roundup integration from the things that need to > be done pre-migration - there currently is no svn integration, so > not having it for hg is not a step backwards. That's not quite true - the tracker turns text like "r64537" into a link to the appropriate

Re: [Python-Dev] PEP 376

Scott Dial wrote: > Someone feel free to correct me if I am incorrect about the desired tone > and use of the document.. I don't think we're particularly consistent. For example, I actually ending up adding a note to PEP 343 indicating that people shouldn't read too much into the verb tense in tha

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Mark Hammond wrote: > This *appears* to be correct at first glance, but in practice it doesn't > interact well with wildcards specifications - particularly > '**=cleverencode'. I started a thread on the ML and submitted a patch a > few months ago to fix this and it was accepted, but sadly it seeme

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Dirkjan Ochtman writes: > On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote: > > I'll have to try them again now that 1.3 is out, but I found Mercurial > > named branches fundamentally unsuited to release management. > > Can you explain why, please? It's not clear from what you say > b

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Nick Coghlan wrote: > Martin v. Löwis wrote: >> I would drop the roundup integration from the things that need to >> be done pre-migration - there currently is no svn integration, so >> not having it for hg is not a step backwards. > > That's not quite true - the tracker turns text like "r64537" i

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On Sat, 4 Jul 2009 04:22:57 am Terry Reedy wrote: > I would very much like the 'k' dropped from the py3 name. It was a > funny joke when py3 was vaporware, now it is excess baggage which > only puzzles non-insiders and newcomers. +1 Some day we'll be using Python3.7 and wondering what the "k" me

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

On 4/07/2009 12:30 PM, Nick Coghlan wrote: ... I think there needs to be a solid answer in place for these use cases before the actual migration to Mercurial takes place. A hand-waving "use win32text" isn't enough - it needs to be "use win32text with these exact settings" (with server side hook s

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Nick Coghlan writes: > I'm not clear on the rationale for the explicit CRLF line ending on the > email test message, but I would guess it is to ensure that the email > module can handle CRLF line endings correctly regardless of platform. IIRC, that's just the standard for text email. Lines mu

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

At 12:20 PM 7/4/2009 +0900, Stephen J. Turnbull wrote: IME, Mercurial strongly encourages a non-branching style. Although I can't fully explain in concrete terms what makes me feel that way, it's certainly consistent with your own inclination to advise "subset branches". Part of it comes from t

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

Martin v. Löwis wrote: > Ah, right. That must be done, of course (although I suppose there is > little hope to have the existing references continue to work). I'd guess that the only way to keep those functional is to keep svn.python.org around in read-only mode. Although I'm not entirely sure ab

Re: [Python-Dev] Mercurial migration: progress report (PEP 385)

P.J. Eby writes: > Wouldn't the simple thing to do in Mercurial, just be to use > different repositories for long-lived branches? I mean, if you're > not merging them that much anyway, what's the point? I basically agree with that, and so does Dirkjan, I think. I'm not sure why he brought