Bazaar branches available (again) on Launchpad
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
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, David Lyon wrote:
Hi Barry,
That looks very interesting...
Hi David,
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). You can use Bazaar to branch any of the 4 Python series and use all the modern DVCS goodness to develop your updates. You can share your branches with others via e.g. Launchpad and even request reviews (called "merge proposals") to get feedback from others. 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, and that you have a modern version of Bazaar and the bzr-svn plugin. It might even be possible to commit your Bazaar branch to a local Subversion branch, and then commit the latter to get it pushed up to svn.python.org. At worst, you would use Bazaar's features to get your patch into a state you and your reviewers are happy with, then you would generate a diff for application to your copy of the svn.python.org branch. -Barry
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 Tue, Jan 19, 2010 at 7:51 PM, David Lyon <david.lyon@pythontest.org> wrote:
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 sincerely doubt that a source control system will be included in the standard library in the future. Especially 3. A SCM is not a "package management system". Barry was talking about mirrors of the python code. It is true a "package manager" could be developed based on a SCM, however you need to implement this far away from the stdlib and get traction with it within the community long before inclusion would be considered. 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.
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).
Python 3 is still modularized, still has a standard library, etc. If you're really interested in helping with the standard library, get on stdlib-sig, and get ready to write code and PEPs.
Were you offering me an experimental branch somewhere for python 3 SCM integration ?
Barry made bzr mirrors of the python svn tree. Not a python with bzr included. jesse
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 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
Okay, last follow up on this and then I'm going to bed. :) On Jan 20, 2010, at 03:29 PM, David Lyon wrote:
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.
Actually, you're not. It's not up to the Python community to initiate this. If you really want this, you should engage with the relevant DVCS communities and push them to request it.
Side benefits are that it can update everything else along with it at the same time. User Apps, Packages, whatever.
I get that. Heck, I still run one Gentoo server which I think is as close to the edge you're describing as I'm comfortable with. It's all great until the wheels come off and then it can take *days* to get a functioning system again. The big difference is that I rely on my DVCS to keep one small thing, or a few variants of the same thing, all sane. But I rely on my distribution vendor to keep a thousand complex, interdependent, interacting, sometimes conflicting things sane and working.
Point : The fact that SCMs are two way is great in a production environment. No packaging solution can come close.
Try talking with some hard-core operations guys, the folks with the keys to the data centers, who work tireless, insanely hours keeping incredibly complex systems running with very little downtime. I think you'd get a different perspective to put it mildly. :) to-sleep-perchance-to-dream-ly y'rs, -Barry
Barry Warsaw <barry@python.org> writes:
On Jan 20, 2010, at 03:29 PM, David Lyon wrote:
So here I am as a user doing things the 'right' way.
Actually, you're not. It's not up to the Python community to initiate this. If you really want this, you should engage with the relevant DVCS communities and push them to request it.
Where “push” must be strictly limited by a continual awareness that the whole idea could just be bad. If you find yourself in a tiny minority pushing for a change, it *could* be that you have a great idea and the vast majority don't realise it yet. But you must be realistic about the likelihood that the change is a very *bad* idea, and frequently evaluate it for signs of that. -- \ “I used to think that the brain was the most wonderful organ in | `\ my body. Then I realized who was telling me this.” —Emo Philips | _o__) | Ben Finney
On Tue, Jan 19, 2010 at 7:51 PM, Jesse Noller wrote:
Python 3 is still modularized, still has a standard library, etc. If you're really interested in helping with the standard library, get on stdlib-sig, and get ready to write code and PEPs.
Thank you for your direction to move these items forward to PEPs and Code.
i sincerely doubt that a source control system will be included in the standard library in the future. Especially 3.
Yeah and who twenty years ago thought you would get a 1GB memory card for $3 when all we had was 10Meg hard disks and they were the full 8" platter.
A SCM is not a "package management system".
Exactly. It almost makes the need for a "package management system" pretty much obsolete if you can update your code directly from the developers sources. That's what all these SCMs provide. Plus it's addictive. It's hard to go back to 'package' style technology once you have all your code on an SCM based feed.
Barry was talking about mirrors of the python code. It is true a "package manager" could be developed based on a SCM, however you need to implement this far away from the stdlib and get traction with it within the community long before inclusion would be considered.
I think I'll have better chances with PEPs. 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. 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.
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.
Barry made bzr mirrors of the python svn tree. Not a python with bzr included.
I can't resist asking for that again.. I heard it only in Monty speek. Did you just say ?: "Barry made a bizarre mirror of the python suvern tree. Not a python with a buzzer included." Anyway.. Maybe I do get what your talking about. Even if you do talk with a strange accent. :-) David
On Tue, Jan 19, 2010 at 10:43 PM, David Lyon <david.lyon@pythontest.org> 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
"David Lyon" <david.lyon@pythontest.org> 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. -- \ “If you pick up a starving dog and make him prosperous, he will | `\ not bite you. This is the principal difference between a dog | _o__) and a man.” —Mark Twain, _Pudd'n'head Wilson_ | Ben Finney
"David Lyon" <david.lyon@pythontest.org> 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" <david.lyon@pythontest.org> 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
On Tue, Jan 19, 2010 at 21:43, David Lyon <david.lyon@pythontest.org> 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 20, 2010, at 02:43 PM, David Lyon wrote:
On Tue, Jan 19, 2010 at 7:51 PM, Jesse Noller wrote:
A SCM is not a "package management system".
Exactly. It almost makes the need for a "package management system" pretty much obsolete if you can update your code directly from the developers sources.
That's what all these SCMs provide. Plus it's addictive. It's hard to go back to 'package' style technology once you have all your code on an SCM based feed.
Well... I'm not so sure. A package management system like apt does a /ton/ of additional bookkeeping and work to ensure a robust, highly consistent, functioning system. And while both Python and most Linux distributions have their own notion of "package management", they don't always play nicely together. Tarek and the distutils-sig's work is trying to make the world a better place by bridging this gap better, and there is code out there that makes it easier to say import a Python package from the Cheeseshop and .deb-ify it for use on Debian and Ubuntu. There's also work being done in Launchpad that will allow you to "build-from-branch" so that in a sense you could let a build farm take your Bazaar branches and automatically build the packages from them. I've strayed off-topic I suppose, but I see SCMs and package managers as complementary technologies that help with important parts of the process of delivering software to end-users, but I don't quite see how one can make the other obsolete. -Barry
David Lyon <david.lyon <at> pythontest.org> writes:
I think I'll have better chances with PEPs.
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. [snip]
This is python-ideas material, can you take it there? Thank you. Antoine.
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. Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
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
That's only two points. :-)
In French, we say that several starts with 2 ;)
On 1; If that's true, I won't mention git again.
I tis, you can check on the git repository (it's a mix of C, perl, shell scripts, Python, ...)
On 2; Who knows what their life cycle is.
You can check on their websites, their cycles are far shorter than Python minor releases (several months vs several years). Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
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 ---------------------------------------------------------------
participants (9)
-
Antoine Pitrou -
Barry Warsaw -
Ben Finney -
Brian Curtin -
David Lyon -
Jesse Noller -
Matthieu Brucher -
Nick Coghlan -
Stephen J. Turnbull