Hi Barry, That looks very interesting... So does that mean we could update the stdlib for a given python version using this ? David

I've just updated the Launchpad mirrors for the 4 active Python branches, trunk, py3k, 2.6, and 3.1. These used to mirror the defunct Bazaar branches on code.python.org but it's probably been 7 months or so since those were regularly updated. Now the Launchpad branches sync against the read-only Subversion branches at http://svn.python.org, so they should remain up-to-date (within the re-sync timeframe of about 4 hours).

This means you can once again use Bazaar to get local branches of Python, and you can of course push your own branches to Launchpad. I believe you can even use the bzr-svn plugin to commit changes back to the Subversion master, though I have not yet tried this.

To get a local branch, just do any of the following:

% bzr branch lp:python (for trunk) % bzr branch lp:python/2.6 % bzr branch lp:python/py3k % bzr branch lp:python/3.1

(It's fairly easy to create new mirrors for other Subversion branches, e.g. Python 2.5; just drop me an email if you want them.)

If you're going to create a lot of branches you probably want to put them in a shared repository. E.g.

% bzr init-repo pythonbzr % cd pythonbzr % bzr branch lp:python/py3k

Bazaar 2.0 or better is recommended. For me, it took about 5m to check the first branch out from Launchpad, and then about 30s or so for each subsequent branch.

Enjoy, -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/david.lyon%40pythontest.or...

On Jan 20, 2010, at 10:16 AM, Barry wrote:

...

So does that mean we could update the stdlib for a given python version using this ?

In a sense, yes (if I understand your question correctly).

Yeah, it just needs an implementation.

The one thing I am unsure about, mostly because I have not tried it, is whether your Bazaar branch can be used to commit directly back to the Python Subversion master branches. I /think/ the answer is yes, assuming of course that you have permission to do so...

Well I'm too Senior and my stuff is too forward looking to qualify for that just yet. I'd be happy to see bzr and mercurial and git all made it together into the stdlib for python 3. That would give a superb updating mechanism for python that would propel python well beyond the dinosaur badlands of CPAN and other languages. I was actually reading from (http://en.wikipedia.org/wiki/Python_%28programming_language%29): "Rather than requiring all desired functionality to be built into the language's core, Python was designed to be highly extensible. .. .. This design of a small core language with a large standard library and an easily extensible interpreter was intended by Van Rossum from the very start because of his frustrations with ABC (which espoused the opposite mindset).[5]" To me, the source code control systems seem to be fully in tune with the original design of python. That is, to be able to easily pull external libraries in. I think what has changed is that the mechanisms now (the SCMs) are way more highly developed than before. Apart from that though, after reading the full wikipedia article I'm left with the distinct impression that things are still pretty much the same (in that python design philosophy is advanced), just that the landscape (of external C libraries) has changed. Now all the libraries are external (on the internet) and all externally managed. So with just a tiny amount of work, imho we could pull it all together to bring python 3 *back* to being that cool tool that it once was (not saying it isn't now). Were you offering me an experimental branch somewhere for python 3 SCM integration ? David

On Jan 19, 2010, at 08:09 PM, Jesse Noller wrote:

The decision to move python's source control from SVN to mercurial was controversial enough; including 3 or more scm libraries into core would be an intractable uphill mountain of bike sheds.

I'd be surprised if any of the big 3 DVCS developers would actually /want/ their stuff in the stdlib. Being in the stdlib has its advantages and disadvantages. I think for rapidly developing technology, the latter can actually outweigh the former. (Besides, git in the stdlib doesn't make much sense :).

Barry made bzr mirrors of the python svn tree. Not a python with bzr included.

Bingo. -Barry

On Tue, Jan 19, 2010 at 10:43 PM, David Lyon wrote: [snip]

Being honest, if wonderful libraries like Sphinx and Mercurial and Git and BZR can't make it into the stdlib, then there is no hope for even newer code to get in there.

Did you ever stop to think that some package authors do not want their code in the standard library? That throwing random shiny things in there just makes it a junk drawer? Besides: Show us the PEP to include Sphinx, and it's dependencies in the standard lib, with Georg's signature at the bottom. The authors of modules have to want things to be in there, they have to be best of breed, tested or common-enough patterns to warrant a slot. We have things in the standard lib which still need more TLC and maintenance, or they need to be shunted into space. Adding random things, which may or may not help packaging, and installing things from random places in someone source repository won't make things better.

Plus, promoting all sorts of new and fangled tools however good they may or may not be just confuses users and ends up being a waste of time imho. It isn't good management of volounteers time and effort.

If you could imagine disaster relief coordinated this way, it would just be a disaster in itself.

That's why it has taken some 5 years to get PEP-345 done.

I'm going to assume that you're trolling now, or intentionally misrepresenting facts. Maybe a little of both. A PEP, and an implementation and the ability to rationally debate, discuss and defend your proposal is what is needed to enact changes on policies, python-core or the standard library.

...

The decision to move python's source control from SVN to mercurial was controversial enough; including 3 or more scm libraries into core would be an intractable uphill mountain of bike sheds.

Not at all.

It would be a very fair thing to do. Not to mention being great for users.

There should be one-- and preferably only one --obvious way to do it.

Anyway.. Maybe I do get what your talking about. Even if you do talk with a strange accent. :-)

My sense of humor has been disabled by repeated stunning at your hands. I admire your enthusiasm, even if I do think some of it is misplaced, or at guided into the proper channels at very least. Please, you seem to have the time and willingness to help, please go about this the right way. Discuss things on the proper lists, make concrete proposals. If you have have standard lib changes, discuss them on stdlib-sig, if you have ideas about python-the-language, or the interpreter, etc - please discuss it on python-ideas. jesse

On Tue, Jan 19, 2010 at 21:43, David Lyon wrote:

Being honest, if wonderful libraries like Sphinx and Mercurial and Git and BZR can't make it into the stdlib, then there is no hope for even newer code to get in there.

I'm not entirely sure I see why the inclusion of a SCM into the stdlib is necessary. Just because pieces of software are mature and proven in their fields doesn't mean we should add them, or that them *not* being in the stdlib should be a basis for other projects making it in.

On Jan 19, 2010, at 08:09 PM, Barry Warsaw wrote:

I'd be surprised if any of the big 3 DVCS developers would actually /want/ their stuff in the stdlib.

If they ask, they'll get told they're motorbike-shedding. "It's better if their users ask". So here I am as a user doing things the 'right' way.

Being in the stdlib has its advantages and disadvantages. I think for rapidly developing technology, the latter can actually outweigh the former.

If it's about being able to do updates, then I think this resolves an old and circular argument. As the SCM implementation would, one would expect, to be able to update itself. Side benefits are that it can update everything else along with it at the same time. User Apps, Packages, whatever. It's even better having SCM in an Industrial/Scientific environment. Here's an example: - a machine breaks.. (I mean the software for/in it) - you fix the code, maybe on the spot - you commit and push back to the repository - your code gets checked in and run through the testbot and then you get blamed and have to do the whole thing again properly with a test case. Oh well.. Well anyway, whatever you guys might say, that's a whole lot more efficient than running back to the development machine and going through some obscure build and test and publish process to do a fix on a production machine. Point : The fact that SCMs are two way is great in a production environment. No packaging solution can come close. So why not have python SCMs included as batteries in python.. All these arguments I can take off to the stdlib list when I get the chance.. David

"David Lyon" writes:

...

Being honest, if wonderful libraries like Sphinx and Mercurial and Git and BZR can't make it into the stdlib, then there is no hope for even newer code to get in there.

Those are applications, not libraries. Applications don't belong in the standard library.

Haha funny.. Well using that logic, distutils is an application.. Are you saying that distutils should be removed? That is most certainly an application. Lets not get too pedantic here. Mercurial and bzr have a built in API that can be called in a library like way. It's true they also have a command line interface in the same way that distutils does. I'm not saying anything negative about distutils. Given that Tarek has an upcoming Pycon presentation where the program talks about a distutils revamp. I'm hoping that he can find some young 20 yr olds and put a cool web interface on that thing. Given that there are empty sprints at pycon. It couldn't hurt to throw that challenge out. Anyway, we'll see.. David

"David Lyon" writes:

Well using that logic, distutils is an application..

Distutils is an application, the function of which is essential to allowing sane development of Python packages. It's a special case. We need to strictly limit the number of special cases, not gleefully add to them. -- \ “I'd take the awe of understanding over the awe of ignorance | `\ any day.” —Douglas Adams | _o__) | Ben Finney

Matthieu,

...

I'd be happy to see bzr and mercurial and git all made it together into the stdlib for python 3. That would give a superb updating mechanism for python that would propel python well beyond the dinosaur badlands of CPAN and other languages.

I think there are several points that make them not includable in Python: - git is not written in Python - bzr and mercurial have a life cycle much shorter than Python's, it's the same issue than with other libraries where another community develops them.

That's only two points. :-) On 1; If that's true, I won't mention git again. On 2; Who knows what their life cycle is. CVS is pretty much dead, and svn looks like it is on the way out. I can't think of how anything could be better than mercurial or bzr but I know I will be proved wrong. At the end of the day, we are making a decision about whether the language is 'set-in-stone' or whether it is still evolving. To me, Python 1.x had it's own distinct "era", as has Python 2.x Hoping that the Python 3 era can be a little more flexible and perphaps "cleaner" than the 2.x era is all that I am thinking here. Have a nice day David

Barry Warsaw writes:

(Besides, git in the stdlib doesn't make much sense :).

"Dulwich."

David Lyon wrote:

On 2; Who knows what their life cycle is. CVS is pretty much dead, and svn looks like it is on the way out. I can't think of how anything could be better than mercurial or bzr but I know I will be proved wrong.

I believe you misunderstood what Matthieu meant by life cycle there: think "release cycle". If a project pushes out new releases significantly more often than every 18-24 months (as is currently true for all of the major SCM tools), then that fact alone makes it a very bad fit for the Python standard library. And centralised source control will be going strong for years. The DVCS approach may be great for the open source world, but the gains are far more limited in a closed source shop (especially a group writing internal corporate applications which doesn't need to keep many, if any, maintenance branches going). If we weren't dealing with 4 active branches, the DVCS discussion would have got a lot less traction with the core developers - aside from better handling of multiple lines of development, most of the benefits of the switch to a DVCS accrue to people without commit access to the SVN repository. Anyway, we've wandered far afield from legit python-dev topics now. Any further ideas about super_mega_easy_install functionality that can pull code from source control systems and build it rather than requiring prebuild source tarballs should be directed to python-ideas (they probably need to bake more even before they make an appearance on distutils-sig). Cheers, Nick. P.S. As Jesse said... your enthusiasm is great, but please don't assume that some inherent conservatism on the part of other developers is automatically evil or the result of a failure to see your point. A lot of people around the world rely on our stuff every day. We owe it to them to be measured in our actions and to put serious thought into any major changes or additions we make to the language and the standard library. For the current stage of its development, Python 3 is in a good place from our point of view - its major carrot has really always been the better Unicode support it offers, and the ever-increasing globalisation of the web will create more and more pressure pushing developers in that direction as the years go by. Sure, Python 3 cleans up assorted other things as well, but the change to the text processing model is the big one that is fundamentally incompatible with the architecture of the 2.x series. Compared to that change, everything else is just tinkering. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------