Python moved to GitHub

https://github.com/python/cpython

by c8g • 9 years ago

820 303 9 years ago

github.com

jwilk3• 9 years ago

https://news.ycombinator.com/item?id=13614253

laurentdc2• 9 years ago

Yes!

I quite like the idea of "centralizing" development on GitHub, or similar services. It makes it much easier for everyone to fork, test, make a pull request, merge, etc..

For example, one reason why I gave up contributing to OpenWrt was their absolutely legacy contribution system [1], which required devs to submit code diff patches via email (good luck not messing up the formatting with a modern client) on a mailing list. It took me an hour to submit a patch for three lines of code. It seems like Python wasn't much different. [2]

[1] https://dev.openwrt.org/wiki/SubmittingPatches#a1.Creatingap...

[2] https://docs.python.org/devguide/patch.html

corndoge• 9 years ago

The emailed patch model is still incredibly popular and combined with an application such as Patchwork remains efficient.

good luck not messing up the formatting with a modern client

$ git send-email

GitHub is easier to get started with but both methods have their benefits. I personally prefer GitHub but don't have problems contributing to projects that use the emailed patch model.

laurentdc2• 9 years ago

$ git send-email

Ah, thanks. If I only had known! :)

Maybe someone at OpenWrt (with edit access to the Wiki and such) could write a simple script for git send-email with a wrapper for the [PATCH] [architecture] what subject and Signed-off-by thing. Would speed things up quite a bit imho, especially for newcomers. I see quite a few "not formatted properly" rejections.

LeanderK• 9 years ago

i don't like centralising development on github, but i welcome the competition for more user-friendly systems. I think the pressure is increasing for other service to provide an equal experience both for exploring an contributing to a project.

ycmbntrthrwaway7• 9 years ago

https://gitea.io/

tyteen4a03• 9 years ago

The closest competition to GitHub seems to be GitLab at the moment, but I heard it's slow to some users. The UI also felt a bit "off" to me (primarily because I'm used to having code, not the README, as the index page of a repo)

I have my private projects on GitLab because it's free. (BitBucket before that; good riddance)

ycmbntrthrwaway7• 9 years ago

Centralizing around proprietary software is not a good idea generally.

Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use "issues" feature for good.

One way to avoid email without centralization is setting up Gerrit. That is how Ring [1] and LineageOS (former CyanogenMod) [2] manage their "pull requests".

Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects, such as all suckless [3] projects and Linux itself.

[1] https://gerrit-ring.savoirfairelinux.com/

[2] https://review.lineageos.org/

[3] http://suckless.org/

fake-name7• 9 years ago

Anything is better then e-mail based systems.

The discoverability, browsability, and useability of something with actual markup and design is infinitely better then e-mail.

I've tried several times to make submissions to several e-mail based projects, never with any success. At the same time, I've had zero issues contributing to a dozen or so github hosted projects.

E-mail systems are a shitshow. First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!), send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc....

Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors.

If there's a project where I want to make a few-line change or minor enhancement, and it's on github, I'll generally PR it back into the original. If it's somewhere else, or requires another account, there's no way I'm going to spend the effort.

Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. They all operate on a per-message response-tree structure, so just reading the discussion is a huge pain in the ass.

E-mail is basically dying among younger people, including the ones that code, and with good reason. For actual forum-type discussions, it's a completely shit solution.

Tharre• 9 years ago

If you're worried about losing issues, then just backup them using Github's API and some script[0].

[0] https://gist.github.com/Tharre/706b0d8c3567c1f5346a

mathgeek• 9 years ago

Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker.

While I agree it's a good skill, this statement implies that anyone who doesn't use it it somehow arbitrarily "less important" than someone who does, when it comes to contributing to open source.

ajdlinux8• 9 years ago

Everyone I know who has had to use Gerrit has absolutely, utterly despised it.

Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn't an "absolutely necessary" skill for a good developer these days.

The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives.

But it's still not good. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens all the time). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Doing code review from an email client definitely has its benefits, but it's also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments.

I can't see the Linux kernel ever moving away from email, and honestly it's not too bad once you've figured out your workflow, but I would like to see kernel hackers thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It is disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development better?

theamk• 9 years ago

Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use "issues" feature for good.

um, no? PEP-512 ( https://www.python.org/dev/peps/pep-0512/ ) is pretty clear about it:

"The code review history does not have the same implicit backup mechanism as the repository itself. That means a daily backup of code review history should be done so that it is not lost in case of any issues with GitHub."

cx1000• 9 years ago

I commented on this in another thread, but I'll repeat it here.

The guy in charge of making the decision weighed the fact that it's closed source, and it still won.

But to me, the development process is more important than worrying whether a cloud-based service publishes its source code... This is especially not a worry as GitHub is not a walled garden; its extensive SDK allows for downloading any and all data that goes into the platform.

In summary, his reasons were: github has become a social network of open source devs; gitlab has no killer features github doesn't; and Guido prefers github

https://snarky.ca/the-history-behind-the-decision-to-move-py...

My personal feeing on the matter is that proprietary software can harness a lot of talent and usually delivers a better end user experience. For example, the creator of Twitter Bootstrap works for github full time. How else will you get talented people thinking about how to make a product better all day?

forrestthewoods• 9 years ago

I agree relying on proprietary platforms which may shutdown is a good thing. I'd go so far as to say all platforms inevitably WILL shutdown.

But GitHub issues can be exported pretty easily. Exported and saved in the distributed Git repository even.

I think relying on a platform is perfectly fine if you have an exit strategy. I've moved my blog through multiple platforms. I even maintain the domain so old URLs continue to work. Will Medium shut down? Yes. And when it does I'll move my blog again. It won't be the first time and it won't be the last.

ghostly_s• 9 years ago

Python does not use "issues" feature for good.

Interesting, I didn't even know you could disable 'Issues' for a Github repo. Why do I come across so many projects where the dev lets random issues pile up which they clearly have no intention of responding to, then?

komali2• 9 years ago

I mean, I want to consider myself a hacker, but I have no interest in OS programming, and everything I am interested in is on Github.

mayneack• 9 years ago

If you subscribe to a github repo you get issue emails by default. So issues could still be "backed up" by email on github.

manigandham• 9 years ago

Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects

What? That sounds like a problem with the projects, not the people. Why make it so much harder to get contributions?

newman314• 9 years ago

It's even worse with ddwrt. =(

I've pretty much given up hope that any of these *-wrt devs take security or dev seriously.

aljones• 9 years ago

I agree, but there are risks in using a proprietary platform for this. See sourceforge.

zeveb3• 9 years ago

good luck not messing up the formatting with a modern client

I wonder how 'modern' a client can be if it can't even post source code properly.

di• 9 years ago

More details on the decision:

https://snarky.ca/the-history-behind-the-decision-to-move-py...

fairpx• 9 years ago

this just adds to the mystery

EvgeniyZh2• 9 years ago

I'd really like more big and important projects would move their development to GitHub-styled services. Maybe I'm just not hardcore enough, but I feel they make live easier, both for maintainers, contributors and newcomers.

But it's probably too hard to switch and core developers don't see point in it (since they're totally ok with working their way). Maybe when a new generation developers will take core positions...

hvidgaard• 9 years ago

The idea of GitHub is great, and frightning at the same time. The development community as a whole would be crippled if GitHub went under. Same thing with StackOverflow.

I'm still dreaming of a decentralized GitHub based on something like ipfs.

EvgeniyZh2• 9 years ago

Well, local running copy GitLab (or something other GitHub-styled) with a couple of backups is pretty safe and still gives all the advantages of GitHub.

Decentralized GitHub is a nice idea. We gotta implement this)

payne92• 9 years ago

Part of Github's secret sauce: Web source tree browsing that's front and center, that's relatively decent, with OK search. (versus making the log/history the central part of the Web UI as other tools seem to do)

There are SO many times I need a short peek at something, and am glad don't have to clone/download, etc.

tyingq4• 9 years ago

I wish github would add an option for a case sensitive search. Tired of getting back ThisThing when I specifically want thisthing (lower case).

Also, the search documentation is spread out and seems to be missing guidance on features that are crucial. For example, AND works as you would expect (like: hello AND world), but it isn't mentioned anywhere.

dajohnson892• 9 years ago

This this this. I would spend so much time on GitHub if the search were better. I'm tempted to say that search is less than OK. I do have a huge Java repo, but I'm usually shocked when I quickly find what im querying for.

flamedoge• 9 years ago

why not just full regex

brettlangdon• 9 years ago

I am always amazed at how hard it is to find something with GitHub's search, when `git grep` works so well.

yomly2• 9 years ago

Even just being able to browse code when I'm on the go on my phone is useful!

I am guilty of occasionally even viewing my own projects on github to avoid having to put down what I'm doing to check what's in production...

trevor-e• 9 years ago

It's unfortunate that their mobile site is very watered down compared to desktop. Every time I view something on my phone I have to request the desktop version of the site.

SamReidHughes• 9 years ago

For what it's worth, there are git client apps that you can run on your phone. I've found them to be... usually nicer than GitHub.

mythz2• 9 years ago

GitHub code search + file navigation is so good, that I prefer it to search/navigate code vs opening a VS.NET sln of a repo already cloned locally.

kzrdude2• 9 years ago

git grep is still much better than github's search, when it comes to code. Github search doesn't show enough when there are many matches in the same file.

aub3bhat• 9 years ago

Could not agree more while I was learning to program, it took me months before realizing that it was possible to Browse a Google Code project online.

gioele• 9 years ago

Part of Github's secret sauce: Web source tree browsing that's front and center, that's relatively decent,

Plus decent rendering of README.md at the same base URL.

You get a decent homepage for your project by just pushing your repo.

I wish GitLab just copied the base project page of GitHub.

sytse• 9 years ago

We're thinking about adding the file tab to the default view in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834

sb8244• 9 years ago

Going to second this.

I love the idea of gitlab but I absolutely cannot enjoy the UI. I have trouble understanding the layout of the project from the base URL. I don't have that problem at all on github.

Edit: I'm a fool. I swapped gitlab and bitbucket. BB interface is absolutely bad to me.

tedmiston3• 9 years ago

The "t" key shortcut to do repo wide file search is one off my favorite features.

Jedd• 9 years ago

If you're using chrome / chromium, and you don't know already, then you may be cheered to find out about the Octotree extension: https://github.com/buunguyen/octotree

rickycook• 9 years ago

readme says that it also works in ff and safari

jefffan241• 9 years ago

Thank you for introducing this to me, that is amazing.

wott• 9 years ago

OK search

Damn... I can't even manage to figure out how it works. I consider myself extremely lucky when it returns the expected result, and that seldom happens.

Stratoscope• 9 years ago

Web source tree browsing that's front and center, that's relatively decent, with OK search.

The source browsing feels barely adequate to me. There are so many simple things they could do to make it better.

• Show file sizes. When I'm exploring a repo I'm unfamiliar with, one thing that's helpful for me is to get a sense of what the code is like. To do this, I want to look at some of the larger files; that's where I'll probably find the more interesting code. As it is I just click around on random files hoping to find something interesting.

• Show real dates instead of the vaguely rounded off "how long ago". If it says "a month ago", well, what is it, two weeks or six? And why not show the time? A couple of times I've been looking for a code change and I didn't remember what day it was but I did remember it was right before lunch, maybe around 11:30 or so. It feels like their priority is a "clean and simple" display as opposed to a useful and informative display.

• Fix the display for code that indents with tabs. It still defaults to 8 columns, which hardly anyone (with a few notable exceptions) likes. And you, the user, can't override this. They did recently start honoring the indent_size setting if you have a .editorconfig file, but that really misses the point. Many of us who use tabs don't want to specify an indent_size. That's one of the virtues of tabs: people who read the code can use whatever indentation they prefer. The indent size for tabs should be a user preference setting. As it is, I started adding indent_size=4 to my .editorconfig files just to get a decent looking display on GitHub.

• Use a readable font on mobile. Courier, really? And not such low contrast! Everything is hard to read on mobile, and they even disabled pinch-zoom so I can't make the text a little bigger.

• Show a directory tree on the left. If I'm exploring a repo, I'd like to get the big picture of the directory layout, and also have an easy way to click around to look at the various directories. As it is, I have to do a lot of back and forth. Google Code had this from the beginning.

Edit: Thank you everyone for the helpful replies! I learned some great tips from you all.

fratlas• 9 years ago

I actually prefer the "time since" method. Don't have to do date maths in your head to see how active the repo/file is.

haukur• 9 years ago

Fix the display for code that indents with tabs.

Hidden feature: you can actually add ?ts=2 (or 4) to the URL. It would be nice to be able to configure it, though.

wilg• 9 years ago

Hovering over any time on GitHub shows the absolute time.

timdorr2• 9 years ago

Show file sizes

Those are at the top of the display of file contents. However, they aren't in the tree view, as you've stated. Unfortunately, this is hard because I don't believe Git stores this info in their index of files, which is what is used to generate the tree view. It might be infeasible to gather that data for the tree view.

Show real dates instead of the vaguely rounded off "how long ago".

If you hover over any relative date, the real date is shown. It's on the title attribute for any relative date.

Use a readable font on mobile.

The have Consolas and "Liberation Mono" on the font stack, but those probably aren't on your phone. They are limited in font selection because they have switched to native fonts. This avoids the download of some giant font file that contains all the possible glyphs (which is needed on a site like GitHub's). Unfortunately, the monospace options on mobile are pretty limited: http://iosfonts.com/

Show a directory tree on the left.

Best tip I can offer is to type `t` to search by file name. Works great and has partial matching support, which makes it really quick to navigate to certain key files.

bdcravens• 9 years ago

Show a directory tree on the left

The OctoTree extension is great for this (all browsers, and works for both Github and Gitlab)

netheril963• 9 years ago

What I want most is "jump to definition". Maybe not as full fledged as the true IDE, but just ctags like behavior is immensely helpful.

TACIXAT• 9 years ago

I'd be really happy if they parsed the code and indexed definitions vs usage in search. A lot of times when I'm digging through a project I'll find a function and want to look up the definition. Ok, try searching for the type and function name, nothing, it must be type, a line break, then the function name. A lot of times I end up clicking through pages of search results trying to find something that is a little elusive. It would be awesome if they did it like IDEs and you could filter searches by usage or definitions (go to declaration sort of thing). Given the number of languages they would have to implement that over, I don't think it will happen, but it would be cool.

c8g• 9 years ago

Show file sizes

https://github.com/harshjv/github-repo-size

strictfp• 9 years ago

To me the real killer is that the code formatter is too slow on mobile, with no way (AFAIK) of opting out.

jakub_g• 9 years ago

Show a directory tree on the left.

FYI there's a Chrome extension for that

https://chrome.google.com/webstore/detail/octotree/bkhaagjah...

rbanffy• 9 years ago

• Fix the display for code that indents with tabs. It still defaults to 8 columns

God made the ASR-33 with 8-column tabs for a reason. ;-)

As for style, it is relatively easy to make a browser plugin that overrides the default styles of a site. While working for Canonical, I did one for Launchpad:

https://chrome.google.com/webstore/detail/launchpad-tweaks/p...

whatever_dude• 9 years ago

Fix the display for code that indents with tabs. It still defaults to 8 columns, which hardly anyone (with a few notable exceptions) likes

I still think GH's insistence on 8-space tabs is part of a secret conspiracy campaign to get people to stop using tabs. It always looks bad when you look at tabbed source code in there, so the easier way to avoid it is to start using spaces instead.

findjashua• 9 years ago

"Show a directory tree on the left"

if you use Chrome, try out Octotree

Sohcahtoa82• 9 years ago

disabled pinch zoom

Can anyone explain to me why this is even a feature?

Why did the powers that be decide that web sites should be able to prevent pinch zooming? Why do mobile browsers not provide the option to disable this bug?

celim307• 9 years ago

same reason i like npm 'run this in your browser' feature. lets u play around with the actual implementation

beliu• 9 years ago

Check out Sourcegraph: web source tree browsing with jump to def, find refs, and a bunch of other intelligent features. For example, try diving into the Go std lib: https://sourcegraph.com/github.com/golang/go/-/blob/src/net/...

(Disclaimer: I'm one of the creators. We currently only support Go officially, but other languages soon on the way via the open-source Language Server Protocol standard. Also, big fans of GitHub and glad to see this move!)

TeMPOraL• 9 years ago

with OK search

As far as I can tell, Gitlab (still) doesn't have search within repo. It's one of the most useful features on Github for me; often I want to see the definition or uses of some symbol without having to clone the repo. I don't understand why Gitlab doesn't seem to support it.

jackyb• 9 years ago

I just tried on my Gitlab 8.16 and it seems to be able to do that. If you go to the Code tab, it shows snippets of files that contain the search term.

daxelrod• 9 years ago

It does, but I believe you need GitLab EE with ElasticSearch turned on: https://docs.gitlab.com/ee/integration/elasticsearch.html

agumonkey• 9 years ago

I actually dislike their "tree browsing", which is not a tree .. herein lies the problem.

What I like in github .. it's a multiformat http file viewer.

dbalan• 9 years ago

So python eventually moved to git from mercurial.

xapata2• 9 years ago

It's less about the VCS than the GitHub community.

milesrout4• 9 years ago

I dislike Hg, but I'd much rather use Hg than have anything to do with the GitHub "community".

harry82• 9 years ago

I'm not sure that's correct.

https://hg.python.org/cpython/

kzrdude2• 9 years ago

It is, though

tedmiston3• 9 years ago

Is one a mirror of the other?

gkya4• 9 years ago

This is FUD. There are sensible responses to this comment, so I won't write a new one, but say one thing: You don't know how to use conventional tools, and and go on to blindly rant about them.

Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors.

If those contributors are as incompetent to not be able to mail a patch, I'd rather be happy to have excluded them.

fake-name7• 9 years ago

I think the core issue with your response is, unless the project in question is the "conventional tools", why do you seem to think knowing those tools is even germane to the quality of someone's contributions?

I write python and some C++ stuff for fun in my free time. If your project interests me, but I have to spend said free time to learn esoteric tools to interact with it that aren't needed elsewhere in my life, how do you figure that's valid?

It's not that I couldn't learn to deal with that kind of shit, it's that I don't see why I should bother. If everything else works without e-mailed diffs, all that does is make anyone with more then one hobby project do is look elsewhere.

gkya4• 9 years ago

One way or another, one has to learn the conventional communication tools if they want to contribute to any open-source project, be it GitHub or GitLab, or a mailing list and debbugs. The maintainers get to decide and it's their way or the highway. The project is theirs.

Some skills only serve one purpose. Like shaving. I learnt how to shave when I was a teen, and that skill has only been useful to me in shaving my face, since ten years. And being able to use email and diffs is a transferable skill.

I won't respond to you anymore, as I dislike your language and your contributions are trollish.

sametmax3• 9 years ago

It's not a matter of competence, it's a matter of effort. With github, most things are easily discoverable. With email workflow, you have to relearn a whole black boxed, badly documented custom workflow that you will get wrong several times.

When I spent 15 hours writing a high quality patch for free, I don't want to spend 5 hours more just to send it. I have a life.

mememachine5• 9 years ago

Its really obnoxious how many people hate doing things the easy, simple way, apparently just to feel superior.

Manishearth9• 9 years ago

See https://news.ycombinator.com/item?id=13632352 . It's not a simple matter of just sending an email. You can't send patches via gmail (because it autoconverts tabs to spaces), and setting up a client is involved, hard (impossible for some), and should be totally unnecessary.

I despise this "I'm happy to exclude people too incompetent to do X" attitude. I often mentor people into FOSS. They start off pretty incompetent with the tooling. With a bit of nudging they end up making high quality contributions. A person's usage of email has no bearing on their, say, Python skills. Nor does a person's usage of GitHub. These are tools to get the job done, they are not the job themselves. Tools should be easy to use. Github isn't exactly easy, but it's much easier than patch MLs.

PuercoPop2• 9 years ago

Can't say that matches my experience, I've never encountered any problems with sending patches as an attachment. And find the process simpler than github.

dang• 9 years ago

You don't know how to use conventional tools, and and go on to blindly rant

That crosses into personal attack and incivility, which breaks the HN guidelines regardless of how wrong someone else is. Please don't post like this here.

We detached this subthread from https://news.ycombinator.com/item?id=13631069 and marked it off-topic.

misnome• 9 years ago

Why on earth have they done:

Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017

Rather than just

Copyright (c) 2001-2017

makecheck• 9 years ago

A couple of technical reasons might be: ensuring that you can "grep" for any 4-digit year and find applicable files; or, that a "diff" makes it more obvious what is being added.

I prefer ranges personally. Also, I believe only the year of first publication is technically required anyway.

jobigoud• 9 years ago

Also, I believe only the year of first publication is technically required anyway.

Surely adding later years must have the effect of pushing the copyright expiration date?

sarreph• 9 years ago

Better still - Copyright (c) range(2001, 2018)

;)

ajdlinux8• 9 years ago

I'm not sure why, but I've seen this elsewhere - in particular I think it's FSF policy to number every year individually.

slizard2• 9 years ago

This is why: "For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage."

Source: https://www.gnu.org/licenses/gpl-howto.en.html

uiri• 9 years ago

Every year from 2001 to 2017 inclusive is listed so this is not the reason.

milesrout4• 9 years ago

You don't even have to put the dates at all. Copyright notices with dates are stupid, especially when they're in every file and require you to touch every file yearly to update them.

bbcbasic• 9 years ago

You don't even have to have a copyright notice at all.

IANAL, TINLA

vortico2• 9 years ago

Can anyone point me to a resource of the advantages of including copyright dates? I've worked with IP lawyers who consider them to be legally useless. Copyright is applied to a work upon creation and expires n years after the death of the developer. The year of creation has nothing to do with copyright, unless you're trying to prove who created the work, but a year in the copyright notice is a poor way to do this.

eslaught• 9 years ago

I believe if the work is a "work for hire" (i.e. you were paid by a company to do it instead of doing it for yourself) then the timer for copyright expiry starts on the date the work was put into a tangible medium (rather than after the author's death). So assuming some Python developers do that work on company time, then those copyrights are owned by the company and it is legally relevant to include the year.

mrtbld• 9 years ago

Perhaps because explicit is better than implicit.

Kiro• 9 years ago

OT but why do you need to state any year at all?

gigatexal• 9 years ago

Python 3.7 already in the works. The effort to push python 3.x is picking up steam it seems.

akuchling• 9 years ago

Nothing surprising there. The version bump for 3.7 would have been committed immediately after branching off the 3.6 release branch.

hayd• 9 years ago

and nearly 100k commits... time to start making some PRs!

hexa-• 9 years ago

I was recently hit by an IPv4 routing outtage and had only IPv6 available to connect to the internet.

I was therefore unable to connect to github.com, as there is no IPv6 support available:

% host github.com github.com has address 192.30.253.112 github.com has address 192.30.253.113

agentgt5• 9 years ago

This is a little disappointing for several reasons. I understand the merits of GitHub but I really wish Python at least stuck with Mercurial repository and some decentralization.

It's especially sad because Mercurial is just now starting to be incredibly powerful with evolutions.

I guess I'm an old fart but all the centralization has made me paranoid and I still absolutely prefer Mercurial (albeit with plugins) over git.

jsmeaton• 9 years ago

You mention decentralization a lot, but nothing has really changed. All cpython devs still have a full clone on their machines. GitHub functions as a hub now rather than https://hg.python.org/cpython.

agentgt5• 9 years ago

I must have missed some things but they not only switched repository formats they moved the central to github [1]. All opensource projects on github is centralization in my book creates unfair leverage that github has and will have.

For people to work on Python they now have to share information with github which they may not want (they have to create an account and are probably tracked).

1: https://docs.python.org/devguide/setup.html

dbcurtis• 9 years ago

Bah. Anybody can clone a git repo. It's trivial to move off of github with a git repo if they want, or possible to migrate to another database if they want to go through the disruption.

Going to git is about gaining developer mindshare. There are more people using git now. So being on git will bring in more "drive by pr's". I know for my part, life is too short to keep current on multiple source code control tools. I've done plenty in my time, but git is where I'm at now. I use git now at work, and until now, all of the hobby projects that interested me except for 1, were on git. Now all are on git.

At PyCon 2016 Guido told the story of how Mercurial was selected over git. It seemed like an even match at the time. Guido is very source-code-control-tool-agnostic. But git is the current best path to enabling more people to help with cpython development.

agentgt5• 9 years ago

It is hardly trivial to move off. Bugs would have to be migrated, links updated, documentation, automated build systems, workflow as well as user remapping.

While not being Mercurial is one thing it is really more about being on GitHub that is the problem. Kings will get complacent (remember how long it took to GitHub to add some features).

I also vaguely remember the github guys trashing Mercurial with arguabley a propaganda campaign (something "git is better than X"). All that content is missing now but I do remember (I'll have to look on way back machine later).

glogla• 9 years ago

Yes, this is disappointing on many levels. Github is proprietary, semi-monopolistic (in the way Microsoft holds semi-monopoly on desktops) and it's also nest of reactionary vipers [1].

Python community is full of cool and nice people. I guess I expected more from them.

[1] https://news.ycombinator.com/item?id=9966118

collinmanderson• 9 years ago

Mercurial still doesn't have Python 3.x support. I imagine that's an extra encouragement for the Python devs to switch away from it.

16bytes2• 9 years ago

Why would it matter if mercurial has python 3.x support? For writing hooks and extensions?

The mercurial team prioritized end-user features, like evolve, over moving to Python 3, which would only affect a very small number of mercurial users (mostly devs).

I've personally moved to Python 3 for most development and not once have I encountered a case where I couldn't do something in mercurial that would have been possible if the core code was on python 3.

rectangletangle• 9 years ago

Where is the "issues" section? I wanna read about some gnarly low-level CPython bugs!

Other than that, this is a welcome change.

_ZeD_• 9 years ago

http://bugs.python.org/

anamoulous• 9 years ago

Wow the black bar settled it for them, huh?

ambivalence• 9 years ago

I know you're joking but just for the record: this process was started in late 2015, it's a surprisingly complicated endeavour to switch source control hosting.

tbrock• 9 years ago

Wow if only we could get Gnome and Linux on there and give up this mailing list for patches nonsense we'd be golden.

hueving6• 9 years ago

Sad day. Don't forget that github is a closed source tool. This is equivalent to them announcing they are switching to Jira.

Karunamon2• 9 years ago

Both of those products allow for trivial data import/export. What exactly is the problem?

hueving6• 9 years ago

They are closed source. People that are really serious about open source software from top to bottom have issues with dependencies on closed source tooling because it promotes an ethos they don't support.

a3_nm2• 9 years ago

They are using pull requests on Github, and I don't think that these are trivial to import/export.

echelon• 9 years ago

I can't help but think Gitlab would have been in contention for this move had they not had the recent outage. Can anyone from the Python org comment on what other choices were considered?

detaro2• 9 years ago

All this has been decided for months and the discussion about has been going on for more than a year, so no, no recent outage could have been a factor. PEP 512 mentions why GitHub was choosen over GitLab.

https://www.python.org/dev/peps/pep-0512/

tomcam• 9 years ago

tl;dr -- Devs are more familiar with Github, and Python's creator also prefers it (he modestly agreed to go with whatever the team decided and it appears they very much wanted to grant him the courtesy).

imode• 9 years ago

I'd question why it wasn't GitLab but after the recent outage it would somewhat be in bad taste. :P

what exactly was Python using before/where was it hosted? all I can find are the source archives on python.org. I'm assuming this wasn't a hard transition but I'm genuinely curious as to their development strategy regarding distribution of source.

grzm• 9 years ago

There are at least two comments in this thread that address this issue:

- https://news.ycombinator.com/item?id=13633369

- https://news.ycombinator.com/item?id=13633271

napolux• 9 years ago

Still waiting for WordPress to move. ;)

jaimebuelta• 9 years ago

Background info about why this migration and considered alternatives

https://snarky.ca/the-history-behind-the-decision-to-move-py...

faraggi• 9 years ago

Anbody know what happend to Guido's contributions between 2008-2012?

Maybe he had kids. :P

meneses• 9 years ago

FYI, Python was on Github but it was the read-only version. You still had to go to mercurial to push the updates.

lucidguppy• 9 years ago

I wish PR's on github could be checked off per commit like in bitbucket.

Fice5• 9 years ago

This is scary. For increasingly many potential contributors a project effectively does not exist if it is not on GitHub. And, being a huge centralized service, GitHub is very susceptible to censorship (e.g. repos being taken down via DMCA or Russia blocking GitHub until they started to cooperate with the censors). I see this dependence as very bad and dangerous for the free software movement. Should we even consider convenience of a service that has serious ethical issues?

ianai• 9 years ago

Bitbucket does exist though.

chaostheory4• 9 years ago

Why is it scary? Is it that hard to move to bitbucket, gitlab, or another alternative git host if needed?

wyldfire• 9 years ago

It's not hard, IMO.

But it would be nice if these critical projects created gitlab or bitbucket mirrors.

Fice5• 9 years ago

This is not about how hard or easy it is to move from GitHub. What scares me is that it is increasingly hard to participate in the open source/free software community without using GitHub, and it is increasingly hard to find contributors for your own project if you are not willing to host it there.

bastawhiz• 9 years ago

repos being taken down via DMCA or Russia blocking GitHub until they started to cooperate with the censors

Is this not the case with other hosts? If Gitlab got a DMCA notice, would they not be forced to comply? I don't think this is a good argument against Github.

Fice5• 9 years ago

Being removed from one of many interchangeable hosting services is one thing. Being removed from the one central service that everyone around insists on using is another. GitHub, due to it's extreme popularity and centralized nature, is becoming the global gatekeeper for the programming community.

Python moved to GitHub

Related Stories