hpr-knowledge-base/hpr_transcripts/hpr0534.txt

Episode: 534
Title: HPR0534: Mercurial Transition and comments on the Python Package Index
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0534/hpr0534.mp3
Transcribed: 2025-10-07 22:39:40

---

music
Hello everybody and welcome back, assuming that you heard any previous recordings.
You've got a number of interesting topics that we'd like to discuss today.
And the first one is the Python move or rather the mooted Python move of the development team
to a distributed version control system, the nominated tool being mercurial, sometimes known more briefly as HG.
So Brett, since you're the infrastructure chair, would you like to maybe let us know what the current state of play is on the DVCS adoption move?
Sure, I should probably give a little bit of technical background of why we're kind of doing this and what's led to that stall.
So about Python 2008, I started to think about what it would take and what to move to to get us off subversion, which is Python's current choice of version control system onto a distributed one.
Mainly so that non-core developers would have a proper tool to allow them to do their own commits, etc.
Compared to subversion, where unless you're a core developer, you don't really get to have commits and a real proper tool chain to do your development work.
So it was the hope to lure the bear eventually for people who don't quite have core commit access yet.
Fast forward to Python 2009, Guido and I finally make the call to switch the material.
And this was after basically a year long chat and look and trying to decide between bizarre, git and material itself.
Shortly after meeting that announcement, though, some of the Windows developers stepped forward and said, we have line ending issues that we're not happy with how Mercurial handles it.
It turns out that the plugin or extension for Mercurial that is typically used is called 132 text and it's a sub-automal solution for what some of the core developers are after.
It is a personal setting. It is not in any way controlled by the version control system.
So if you're at all familiar with Mercurial, think of your .hgignore file. That's a version controlled.
When 32 text actually uses a file that's only local to your checkout.
So there's no way to tweak a setting and be applied to everyone else who happens to have a clone of your branch.
And so when into pampering was we went to the Mercurial developers and said, do you guys have something else we can use for this or how other people handled it.
And they basically said, well, all of their window developing developer teams are just fine.
They don't really need anything else or they just make sure they don't check anything that's busted with wrong line endings.
But the people who from the core development team who were the big windows developers have said, that's not really acceptable.
And basically they want something equivalent to subversions line ending support. They're EOL support.
So at the moment, we're trying to get a extension that works much more like SVN EOL develops and going.
And we actually have some of the curial developers themselves helping to contribute to that to try to get that going.
Okay, so there's a couple of important points there. One that you mentioned, you're trying with the distributed version control system to lower the barrier of entry as you put it.
And it sounds as though what you're saying is that with a proper DVCS like Mercurial, you can actually accept a commit from an individual user without having to give them a global commit bit or anything like that.
It's all down to assessing somebody's changes and differences from your revision, your current version, and then accepting them if you want. Is that correct?
Yeah, I mean, that's a very good way to look at it. In the world of subversion, the master copy of any branch or any chunk of code is what's on the subversion server.
But in a distributed version control system, everyone's on equal footing. It's just you haven't had a blessed location of code that people kind of socially decide is the master copy.
So by having technically equal to everyone, for instance, if you Steve didn't have commit privileges, you could still have a clone of Python's code and make local commits and have it work.
As if you work or developer, just you don't automatically get to push it to Python or to have the world recognize it as the authoritative copy of Python, which is quite frankly knowing my coding skills, probably in the work to the world's direct advantage.
Oh, I don't know if many of my own botches myself. Well, not too worry, not too worry. So Andrew, you've been involved with core development quite a long time.
How do you feel that the DVHCS will improve things? Have you used Mercurial at all?
As it happens, yes. And in fact, I just this past week read Mercurial the definitive guide, which is the O'Reilly book describing Mercurial, but you can find the complete book available on the web.
So I think the big hope for the transition to Mercurial is that it will make it easier for people to become contributors.
Because right now people submit patches and the patches are submitted on bugs.python.org, and there's a very small pool of people processing these patches.
And in the bright new distributed version control future, hopefully people can make a change, publish their changes using bitbucket.org or their own personal website or something like that.
And they can be more productive and not be dependent on one of the small number of Python committers to integrate their change.
So yeah, I'm really looking forward to it. And I'm disappointed that it's really taking so long.
Well, okay, this brings me to the second important point that came out of Brett's initial description, which was it sounds to me as though despite what was a fairly lengthy evaluation period for get versus Mercurial versus Bazaar.
People who were developers in the Windows world don't seem to have got involved with that process. And so therefore were taken by surprise by this issue.
In a way which they wouldn't if they'd been more involved with the transition earlier. Michael, you do a lot of development on Windows.
One of the big reasons why Mercurial was chosen over gets, I mean, there were various reasons, but Windows support being better was one of the big reasons.
Yes, that's actually was one of them.
Well, I think honestly what happened was so I wrote the PEP or Python enhancement roles for this and that took ages.
And I got that out and everything. And I think kind of the Windows developers thought I'd covered it.
And when I mentioned one 32 Texas potential solution, they thought, okay, great.
And no one really realized because I'm not a Windows user myself that the solution that I picked out from the Mercurial community that had been used really wasn't up to the bar that Python wants in terms of UL solutions.
So it was just kind of essentially a miscommunication on everyone's part.
Yeah, after we did the decision, it's just the hold up at the moment.
Sure.
I'm sorry.
I didn't want to say that issue is now that specific issue is now fixed.
If it's up to the case, what's the hold up now?
No, Martin was miss.
Martin was wrong basically.
Okay.
Right. So just so everyone has a URL to follow along with this.
If you go to Mercurial's Wiki, there's a page called EOL translation plan.
You can also Google for HGEOL one word and look for the first hit for the Mercurial Wiki page.
Basically, the plugin has been started.
As I said, it is an active development.
It just isn't quite finished yet.
I think they're also looking for a little more input from Windows developers and such before they really
fully committed because it is being developed mainly by Martin Geisler,
who is a Mercurial developer, a court developer.
And I think there are looking at actually having this replace 132 text as their primary line ending solution
so that I don't think they want to mess it up.
So they're not rushing it to try to get out the door.
So if people want to help, it's still an active development or want to provide input they can.
And I'm sure they'd be happy to hear from people on it.
Yeah, I have to say the communications I've seen from the Mercurial development community.
Not that I've seen them all, but the ones I have seen do seem quite positive and helpful.
Yeah, I actually talked with them when I was doing the review process for all this.
And they were always very nice, very helpful, fairly prompt in their responses.
So they're definitely not in any way an acidic group or anything like that.
And although you wrote the pattern, right,
it's a shackled Dirk Young, who's actually planning the migration itself.
Is that right?
Yeah, so what ended up happening was after I announced that this was going to happen,
I took a three month hiatus from Python development to work on my PhD thesis proposal.
And Dirk Young stepped forward saying, well, I'm actually a court developer.
And I'd like to handle the transition himself.
So he took over the actual handling of the transition from serverism to material.
Well, I, well, I disappeared off the face of the earth.
And that's unfortunately roughly when this whole line anything kind of exploded.
The mercurial mirror of the Python source tree is visible at hg.python.org.
I believe so, yes.
But so it looks like the conversion was last executed about three months ago.
Yeah, so there's actually two mirrors.
The one in hg.python.org is the test one that I'm sure I'm mispronouncing Dirk's name.
Dirk Young uses to test the conversion from the version in terms of fidelity.
And what it would, what it will look like when the, when the switch is flipped to turn off the version and move to material.
There is though another mirror that is a read only mirror that if you commit to nothing will happen that is available.
I honestly can't remember the URL right now, but I'm sure if you Google for Python hg.python.org you can find it.
That is actually up to date within usually five minutes of subversion.
The deal is this is just not exactly what it would look like when we flip the switch to go to Mercurial and it's read only and there's no attempt to support read right on it.
So if you do prefer Mercurial, you can use it.
I do know some of the core developers do use the Mercurial read only mirror to do their development.
And I looked up to URL and the read only mirror is at code.python.org slash hg.
And it does you to be up to date the last committed 62 minutes ago.
I think the reason for going to code.python.org instead of hg.python.org is sort of if we change version control clients in the, in the future, the, the subdomain doesn't have to change completely.
Yeah, that actually was a discussion of whether or not we should make code.python.org the default from now on or not and people said no, we should stick with the version control specific subdomain.
So that if we do make the switch yet again in the future like we did from CBS to subversion and now hopefully near future to hg.
Everyone will suddenly have, it'll be very obvious what version control system to use.
Yeah, because suddenly your branch will become older and older and older as time goes by and you'll eventually realize that nobody's updating this thing anymore.
Exactly.
That's, yeah, that's, that's not bad at all.
Anything else on this do you think or have we beaten this particular, flock this particular host to death?
No, nothing else.
As I said, if you are interested in the whole EOL win any issue and want to help get the material switch tap and faster, please do have a look at the material extension.
If you're interested, it's in their wiki at EOL translation plan or just Google for HG EOL one word and go to the first hit on the material wiki for the page.
And especially if you're a Windows developer because most of the core development team is not on windows and those that are tend to be very unix line ending friendly people so they don't really run into the issues that we do.
And that's pretty much it. Hopefully it'll happen in the near future.
I'm planning to take a crack at it fairly soon. Hopefully before I come if not right there at the conference and hopefully we'll have it done in the near future in 2010.
Cool. Thanks everybody.
So the next big thing of note, the next bit happening of note recently has been the release of the first in the series of alpha releases for Python 2.7.
And Andrew, you've been tracking the development to make sure that the what's new in Python 2.7 notes are up to date. So what can you tell us is coming down the pipe with this version?
2.7 alpha 1 came out on December 5 about two weeks ago now. And the release plan is to have a new alpha and then a series of betas basically one per month.
And the first beta is expected to be in April 2010. And then there would be two or three betas and one or two release candidates and then a final release in June.
And this is much slower than the normal pace of development, right?
No, I think it's about the same as usual.
Alpha's come along every so often. And the release candidates come very close together perhaps only a week or so apart because at that point the number of changes is quite small.
For Python 2.7, the language moratorium, which we previously discussed is in effect. And so there aren't really any lane changes to the Python language itself.
And sorry.
Oh, I just like to say that the moratorium in terms of there's nothing new that's not already in Python 3.1.
There's still back parts of features from 3.1, but there's nothing completely unique leaning to 2.7 that does not already exist in Python 3.1.
So it just represents a further convergence of the two language lines in so far as not, I mean, I know not all 3.0 features are going to be backported into the Python 2 series, but it's just getting Python 2 closer to Python 3 and therefore making the transition that much easier if you if and when you decide to bite the Python 3 bullet, right?
Exactly.
Yes, there are a few features backported from 3 and there are also some new features that are going to be new in 2.7 and in the next 3.2 release.
So for example, one one new item is an ordered dictionary type, which is something that people tend to rebuild themselves a lot.
And there are a number of unit test improvements that I think Michael will be able to talk to tell us about.
And there are some small things like a few new math functions to compute the gamma function and the error function and a few new physics functions have gotten wrapped and there are various changes to the libraries.
The two big backports from Python 3.
First is the IO library was rewritten in C and I think Python 3.1.
That's correct.
Yeah, that was the release because the pure Python implementation works suck, but it imposed a lot of overhead and was relatively slow.
Yes, when I said suck, I was talking purely about the performance. It was actually a complete implementation as far as I know.
Yeah, it was and it's a very nice library, by the way, for those who have not used it.
So a guy rewritten in C for Python 3.1 and that set of changes was backported to 2.7.
And the other big change is to the code which takes a floating point number and calculates its string representation.
Mark Dickinson has been doing a lot of work on this code to make it produce more readable output so that instead of getting 0.029999, you get 0.03 or something more reasonable.
And so it improves accuracy in a few cases and just generally makes floating point numbers more reproducible in the sense that if you have a floating point number, convert it to a string and convert that string back to a floating point number, you get out the same set of answers.
So basically it makes it, we could say an abbreviation, it makes it a bit more calculator-like.
I suppose yes.
Because that was why originally, Greedo justified moving away from pure integer division in 3, wasn't it?
And basically because it doesn't agree with the way calculators work and most people who come to programming from another discipline find it rather counterintuitive that they put 82.2 in.
They get 82.2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7 out.
This change, though, is only going to delay the pain point for a lot of new developers.
I mean, you can't get round the fact that at some point you have to learn about floating point numbers and learn about the limitations.
But it's going to be less surprising to people who are just starting with the language, I think.
Not sure, if you're doing serious significant scientific calculations, then you have to do enough numerical analysis to be confident in your results.
But people who come to it completely knew won't be quite so confused.
I was about to ask Michael if he wanted to talk about the enhancements to the unit test module.
Oh yes, yes.
I'm quite excited by 2.7 because I became a Python Core developer, or at least I got the commitment to the last Python.
And most of what I've done has been working in the unit test library.
And most of that gets released in 2.7.
And so there are a whole bunch of improvements, some of which come from Google.
And we're integrated by Guido and a developer called Greg and myself.
But if they work on it, we've got things like test discovery.
So that you don't have to use something like knows if you don't want to,
if you don't want to just want to find all your test unit tests in a project and run them.
You can do that from the command line using unit tests.
We've got a whole bunch of type specific comparison functions.
When you do a certain equal and you give it two sets, for example, or two lists, then unit test knows how to compare them.
But also it knows how to nicely format the error message when it fails.
So it can say, right, when you have a list and you have this extra member,
rather than just blasting out everything onto the screen.
Oh, very good. So that saves you that focuses on the differences for you.
Yeah, that's right.
A lot of the changes are about better presentation of familiar messages.
I'm trying to look through the list as a whole.
Yeah, but it's generically speaking.
It's a usability focus rather than, I mean, the test suite did pretty much everything that it needed to do, didn't it?
Right, right. In terms of core changes, there's a new protocol that has been sort of built in to go with the test discovery
so that you can customize your modules when test discovery is happening.
I don't imagine too many people will need to use it.
And the rest really is just about usability of the library.
There's a big list of the changes, the new certain methods, and so on in the works of new documents.
So that's the best place to go and find out about them in the moment.
Great. And since we're talking about 2.7 and since you're an ironpison developer as well,
I wondered if you know whether the ironpison team have specified any particular time frame during which they want to bring ironpison up to the 2.7 standard?
I always feel sorry for the developers of these other implementations.
I'm not a new sound partner lot, but I'm not an ironpison developer.
And they're just like something like about a week ago.
I brought out 2.6.
About the same time, I'll forget 2.6. We're on 2.7 now.
So the ironpison guys, they would love to do Python 3 because particularly the new IO stuff that's in Python 3
and Unicode strings much more closely matches the .NET framework.
Sure, it makes their life easier.
The problem is that they have the same problem that the Python community has that all of the users and the libraries are mainly 2.x focused.
And I'm only gradually migrating over to Python 3.
So if they went straight to Python 3 and dropped 2.x, I think they'd get a lot of protests.
So I think for the moment, their plan is to track 2.7 compatibility, probably start working on that soon.
Okay, switch to 3 soon.
And Brett, Andrew gave us a timeframe for the 2.7 development.
That's going to be roughly parallel with 3.2.
Do you happen to know that the 3.2 schedule is so far as it's been set?
Yeah, so we were actually originally planning to do a simultaneous release.
But thanks to the mortarium, it's not quite a such a big deal because we wanted to make sure that 2.7 and 3.2 didn't diverge very far.
Yeah.
But with the mortarium in place, there's really no way to diverge because we're locked down to 3.1 language semantics until Python, I think 3.4 roughly, I mean, years and years out.
So we're going to do a normal 18 month delayed release.
So with Python 3.1 having come out in June of this year 2009, there won't be a release until I suspect December 2010, if not January 2011.
Yeah, so around a year from now.
Yeah, exactly about a year from now because it's been six months since 3.1 came out.
Okay.
And before we move too far forward, I want to publicly thank Michael for his changes to unit test.
Yeah.
One of the perks of getting to work off of the development branches of Python is I get to play with the new toys immediately.
And Michael's changes to the new test framework are really nice and handy.
And also just to let people know at least in Python 3, we've deprecated all those fail unless methods.
Okay.
So if you're out there writing new unit test code, use the assert versions.
If you want to make your future code a little easier to deal with, and I have to switch those methods at some point in the very far future.
So people will begin to assert equal rather than assert equals again, removing some of the duplication, which is the same.
I prefer to say equals, but we don't rule the cert equal.
It says that that's what that's what we usually in a cert equals.
The plural officially is deprecating in the long run, we'll get rid of all this duplication in the library.
Okay. So there's no more assert greater than either than.
I don't think that was there in the first place.
No, I just invented it to confuse people.
You're right about that.
Okay. So I think then we're pretty clear on what's happening in the 2.7 world.
And I would say for people interested in learning more, you can read the nightly build version of the what's new in Python 2.7 document at docs.python.org slash dev.
And if you follow a few links, you'll get to the document.
Okay. I suppose as well, we should also make a plea for windows users, particularly, but all Python users to at least download the 2.7 alpha releases and give them an initial testing with their software if they have the time because that kind of feedback is invaluable at this point in the development cycle.
Yeah, we've had some that the twisted guys, particularly a very good at running their tests on sort of almost daily builds of Python and they picked up on some problems that I can to know about in unit test.
And it's great to be able to fix things before we release them.
Exactly.
Yeah.
Exactly. Yeah. We don't want we don't want to have to issue a micro release four weeks after the initial 2.7, you know, 2.71 should be like June the following year or something like that if it needed at all.
And just as we finished the topic, just to say there are some treasures in Python 2.7. We've got the memory view object.
We've got import lead coming in. We've got the IO library. So the order dictionary, there are a whole bunch of interesting things worth digging into and of course they'll all be in Python 3 as well.
Well, there's also a bunch of GC optimizations to I mean 2.7s got a bunch of nice optimizations in there. So it's definitely going to be a nice little care for those who are still on to on the 2 series to not stop at 2.6.
So keep moving on to 2.7 because as we discussed in a previous episode, 2.7 quite possible be the end, but we've made sure that it's a good end to the Python 2 series.
Okay. So to do one thing I want to clarify, I believe the import lib module in Python 2.7 is just a tiny, tiny little compatibility subset that doesn't actually do everything that the 3.1 package.
Does bread is is my understanding correct, because that's certainly what I wrote.
Yeah, no, you wrote exactly what you should have written, Andrew, just to keep it short and sweet. Yes, the complete import lib package with all the code to help you write custom importers, et cetera, is only in the Python 3 branch.
It's came into 3.1 and I'll continue to add new features until it's got all the bells and whistles you possibly want.
But what I did backport into 2.7 and actually subsequently into Django 1.1 is a function called import module to basically make it really easy for people to programmatically import modules.
Yeah, the Django guys are going to love you for that. They do that all over the place.
Oh, is that oh yeah, yeah, I actually wrote the patch to backport it into Django 1.1 and to actually go through and change their code and it cleaned up a lot of their spots.
So basically if you're using under under import under under directly anywhere, as a Django 1.1 if you're a Django user or if you're a Python developer using 2.7, don't anymore.
Definitely pulled the import module function. It's a heck of a lot cleaner and simpler to use and it gets rid of a lot nicer edge cases and such.
There's also a version in Pi PI. If you search for import lib, you'll find a version that's been back ported to I believe 2.3. I had to do that for the Django guys.
So even if you're not using 2.7, as long as using 2.3 newer, go to Pi PI search for import lib and you'll find the exact same function available.
And I would definitely use it because it makes it a lot easier to programmatically import.
Good. Thanks very much everybody.
So lastly today, we decided it would be a good idea to talk about the Python package index Pi PI as it's sometimes confusingly known because it can be confused with PYPY, Python and Python.
But recently, the code to support the Python package index had new functionality added to it, which allowed users to comment on packages that they found in the package index.
And this has been, I think we could say, a surprisingly controversial addition to the genre. So Michael, I wonder if you could summarize what happened and the emotions that stirred up in the Python user community.
And the developers too, of course.
The Python package index is a PYPY.python.org and I guess most people who develop or use Python regularly will have heard of it because this is the standard place where Python package is listed and can be downloaded from.
And particularly in recent years, it's become a really important part of the Python infrastructure, a bit like Cpan for Pearl, because you can use the easy install or various other tools to actually automatically download.
And install packages from PYPY.py.
But the whole development of the package index has pretty much been done by one developer, one of the Python core developers called Marcel von Morrison.
And he decided it would be nice for users to be able to comment on packages and write them.
And so he implemented that and added that.
And then various, well, it all kicked off on the Python develop mailing list, I think, is that right?
At least one developer noticed that he got negative comments on his package that he felt sort of didn't make sense and weren't fair.
And there was very little he could do about this.
And so he started a big debate and it rounds very strong feelings and a lot of developers who felt that having comments that turning the Python package index into a social network was not the direction they wanted to see.
And subsequently, there was a lot of debate and Martin and I think also Guido weighed in on several the points of the Python package index is not really there for the developers.
It's really there for the users.
But as a compromise, they had a vote of users to see whether users were generally in favor of the future or not.
Has it been changed as a result of this fight?
Well, I mean, before we discuss the outcome of the vote, let me say that the Python community and I do mean the community at large, not just the PSF seems to have this propensity to call for elections for deciding matters.
And I remember that this happened when decorators were introduced into the language, which is not necessarily an appropriate way to proceed.
Particularly since we get the immediate initial bias of one poor individual having to come up with the options that are chosen, that people are presented with in this election.
But I mean, you know, democracy is not the way I suggest to get sensible software development. And the fact that Python has done so well in the past has been mostly because everyone on the decorate exactly.
The reason the reason that Python has succeeded so well is because it has had a benevolent dictator who's got pretty good software design skills, I think.
Anyway, that's all I want to say, but I'm interested to hear what everybody else has got to say about it.
It really brought out different viewpoints on this. For instance, as Michael pointed out, it kind of makes Pi PI or as I will always call it the G shop, which was the original name just for historical interest anyone, but there was people didn't like that because of business suits wouldn't like the G shop.
So that's why it's Pi PI. Anyway, it was really interesting because as Michael pointed out, some people like the idea of adding kind of social aspect so people could rate.
Some people wanted the G shop Pi PI to be this kind of very just store bits of data for people to download and continue to be this very authoritative and that's completely owned by a storage place.
Some people wanted to balance the people choose what to do, etc.
And it was I found it just really interesting to see the different viewpoints people had of Pi PI and just where they how they viewed it.
Like I just always viewed it as the place where stuff was stored, but we added a social aspect to it fine.
Other people are totally against it wanted to be this like I reach our white list of all packages that are Python and it was just a view I personally never even thought of.
Well, that's certainly true. Oh, by the way, being one of the people who wasn't really terribly happy with the cheese shop name, it was not to appease the suits.
The only reason I didn't think the cheese shop was a good name for Pi PI was because it doesn't really tell you what it does.
You know, when you're looking for a piece of software, I've never heard anyone say, ah, I know I'll go and look in the cheese shop because you just don't think about it.
I think it's a perfectly fine name and it's got, as those of us who follow Monty Python know, it's got a very honorable derivation from a Monty Python sketch.
But it just doesn't help people, you know, when you say, oh, and of course you will find things in the cheese shop. Well, it's not enough course, is it? That's all.
And you feel bad for the Pi PI project because I've heard so many people call Pi PI Pi and at least always takes me a minute to go, oh, they actually mean they're the package index, not the Python and Python.
I like the Pi PI pronunciation, but it doesn't seem true course on.
I think that's a good idea. I think Pi PI would be excellent or we could even just call it the package index, I suppose, since we know where Python programmers.
That's true. Andrew, you've been very quiet about all this.
I think at least some of the initial poor reaction to it stemmed from the fact that it was sort of a unilateral decision that meant the developers had one more information source to follow, something else they had to pay attention to.
And I think a lot of people are feeling kind of oversubscribed to things. You have your Twitter and your Facebook and your mailing lists.
And if you pile on one more thing that well, now you have to watch the comments on your packages on Pi PI, that's one more thing that they.
I can sympathize with that. I'm releasing a package and I've forgotten about the source for a page.
And just before doing the release, two more bug reports on source forage that I hadn't accounted for.
So I delayed the release and had to go and fix those as well.
Yeah, it's difficult. I mean, there's not only that I have seen very inappropriate comments in certain places, including one against a package that I'm not going to name because I think it was very,
this was a piece of really unfair usage of Pi PI.
And that was where one database developer had complained about one of the database support packages.
And then the maintainer actually came back with a very cogent reply as to why the complaints weren't actually justified.
And after several back and forth exchanges, the original commenter eventually revealed that the only reason he'd made the comment was so that he could publish his own details of his own package, which was completing.
And thereby released the URL as well, which I thought was both juvenile and somewhat unfair.
Yeah, that was another worry that some people had such as our absentee, but sometimes regular member Jesse was that there was no real, at least the way it was originally built, there was no way to protect against spam or just totally off topic comments.
So some people, for instance, said this is fine, but we don't think some people thought that they shouldn't add commenting unless we have a proper system in place to like flag comments is inappropriate, a way to deal with spam, et cetera, et cetera, so that it's not just this total wild west open internet comment system.
I don't know if we were even okay with it, they just wanted a better system to control it to make sure it was properly used, not used for like a for bug tracking by some complete newbie who just didn't quite realize where to go to report a bug, for instance, or someone who as you point out Steve's trolling around just to up his link camp.
Absolutely, yeah, right. The whole thing was a little bit fraught and I think it was a bit unfair that people jumped on Martin because all he was really doing was trying to improve the facilities that were offered without really, I think he probably didn't realize the implications of the change.
And one good thing to come out of this is that hopefully we've got a bunch of people interested in the development of the Python package index now, and I think there's a bit of a call for a sprinter.
The next Python which is coming soon, and hopefully we should see a few more people involved.
Absolutely, yes.
And people have made noise about writing a complete new package index.
The existing package index code, it started out life as a CGI, and so the code still bears a lot of evidence of this, and it isn't written using any particular web framework.
I'll believe these projects when I actually see them live, of course.
Right, plus the fact, I think that you have to be careful when people are suggesting that it's a completely new implementation is appropriate, because if Guido had ignored his own feeling to fork Python 3 from Python 2 point whatever, I think we've ended up with a lot more bugs in Python 3 than we actually did.
And the Mozilla guys learned that lesson when they try when they re-implemented net scape instead of forking the existing code base.
My personal worry is that what will happen is, as was mentioned, the code for PyPi is fairly ancient, it was started as a sprint at PyCon 2005.
So this is pretty whiskey, I think 2005 was actually where Jingle kind of got publicly announced.
Is it one of the existing measures?
Exactly, so this is way back before PyThon's web legs really got up and going.
So the code is pretty old, and that's why Martin Bonlose, Godbusson, has been the only guy who's really kept the code up and running and consistently improved.
My worries, people are going to just toss the code, develop their own version, but then not get that pushed to PyPi.python.org, and some of them are going to have a slight forking packaging dexes, which will be unfortunate.
Now luckily, Terrick Zioli, who's developing Distribute, which is the new, pretty replacement.
Yeah, the fork of set of tools.
Yeah, the fork of set of tools, which by the way, if you're out there and you don't know about Distribute, stop using set of tools, start using Distribute.
He has made sure that there's a port to specify, for instance, what package index to use.
So God forbid we actually do end up with competing package indexes, it's taken care of, but at least for me personally, I hope that we can always, this will stay resolved and stay more.
And if PyPi will stay the authoritative one and any new strictly index that comes along can get their code pushed to PyPi, and we can keep having the kind of authoritative URL.
Well, what we, yeah, but what we, okay, but don't we need to distribute it version control system or rather distributed package distribution system as well.
So long as they carry the same packages, I mean, mirroring has been something that's really been needed in the Python package index for a long time, and I think that's what it's been looking at.
But we need, if we have various indexes, they only need to carry the same packages and the same information.
And yeah, that's my big way. It's not the display of it. It's that, oh, I decided to post my package at foodbar.org while someone decides to use PyPi and someone uses some other one.
We ended up with three different package indexes we have to follow. So it's no longer this.
Let's use Distribute and just say distribute or PIP install sphinx or some other really popular library.
But I have to say install from this package index because this is the only package index that has it.
Well, clearly, whatever tool we end up using for this is going to have to have a path setting so that you can add 15 different repositories places to look.
Yeah, I think it's a good idea to avoid that situation.
I think that isn't really a big problem because the bulk of the metadata for a package comes in a file called package info that's inside the tarball.
Yeah. And so I think it will be relatively straightforward to mirror all the tarballs and read the package info files and then have alternate displays for them.
We should, I think, talk a bit about the fix that Martin committed to after the vote.
Oh, go ahead.
The change you committed is that PI PI now has a flag for each package, which is allow comments.
And you can turn this flag on and off at least through the web interface.
I don't think you can provide an argument in your setup PY that says disallow comments.
So it's now possible to turn comments off for a package.
That may still annoy people because they need to do this for every single release of every single package they maintain, which for some people is a big number.
And you can't, I believe, you don't have a setting on the user, which says just turn off commenting for all my packages.
But if people call for that, that could certainly be added.
This has been a bit of a little bit of Python episode three with Michael Ford, Andrew Kuchling, Brett Cannon and me Steve Holden.
And we hope you've enjoyed it.
Thank you for listening to Half Republic Radio.
HPR is sponsored by Carol.net.
So head on over to C-A-R-O dot anything for all of us need.
You
You