> Open Source has become synonymous with GitHub, and we are too small to change that.<p>It's kind of sad that this is true.<p>I'm guilty myself, I contribute to projects on GitHub more often than on any other platform.<p>And when I search for open source projects the first page I use is GitHub.
If you are confused (like me) that this was about PyPI (Python packages repository) then no. It is about a project called PyPy (one can argue it is bad name) that is an implementation of python interpreter but without cpython. Instead they rely on a JIT compiler. And it is syntax compatible but if your code uses any library or method relying on C extensions then you are out of luck (Goodbye NumPy.. etc).<p>Edit: They have C-layer emulation, but I don't know its limitations or current status, but you can use those libraries [1][2]<p>[1] <a href="https://www.pypy.org/posts/2018/09/inside-cpyext-why-emulating-cpython-c-8083064623681286567.html" rel="nofollow">https://www.pypy.org/posts/2018/09/inside-cpyext-why-emulati...</a><p>[2] <a href="https://pythoncapi.readthedocs.io/cpyext.html" rel="nofollow">https://pythoncapi.readthedocs.io/cpyext.html</a>
I've been using git happily for many years. Strangely enough the provenance of a commit i.e. which branch did a commit originally come has not really mattered to me very much. Mercurial provides this and they are using `git notes` to add this provenance meta-data to each commit during migration to git.<p>I would have thought I'd need this much more, but I have not. In plain git I'll just `git log` and grep for the commit in case I want to make sure a commit is available in a certain branch.
But 33% of PyPy packages contain the potential for extreme security flaws and you don't know which ones until it gets you. How bad do you have to want to use Python to tolerate that?<p>"“When we actually examined the behavior and looked for new attack vectors, we discovered that if you download a malicious package — just download it — it will automatically run on your computer,” he told SC Media in an interview from Israel. “So we tried to understand why, because for us the word download doesn’t necessarily mean that the code will automatically run.”<p>But for PyPi, it does. The commands required for both processes run a script, called pip, executes another file called setup.py, that is designed to provide a data structure for the package manager to understand how to handle the package. That script and process is also composed of Python code that runs automatically, meaning an attacker can insert and execute that malicious code on the device of anyone who downloads it." <a href="https://www.scmagazine.com/analysis/a-third-of-pypi-software-packages-contains-flaw-to-execute-code-when-downloaded" rel="nofollow">https://www.scmagazine.com/analysis/a-third-of-pypi-software...</a>
Speaking of git, for mega monorepro performance, we're gonna need synthetic FSes and SCM-integrated synthetic checkouts. Sapling (was hg in the past but was forked and reworked extensively) will be able to do this if EdenFS will ever be released, but Git will need something similar. This will require a system agent running with a caching overlay fs that can grab and cache bits on-the-fly. Yes, it's slightly slower than having contents already, but there is no way to checkout a 600+ GiB repo on a laptop with a 512 GiB SSD.
Every provider out there can talk a standard Git protocol, but all the features that don't have a standard Git protocol become a proprietary API. I think if Git (or a project like it) made a standard protocol/data format for all the features of a SCM, then all those providers could adopt it, and we could start moving away from GitHub as the center of the known universe. If we don't make a universal standard (and implementation) then it'll remain the way it is today.
I used to use Mercurial as well and greatly preferred it, but for better or worse, Git won. I started using Git several years ago and haven't looked back.<p>No matter what people might say, I think this stuff matters for contributors and users who might be looking at your project, and git/github is the typical expectation. This is likely the right decision, as they are now ubiquitous.
This is a tragic, wrongheaded move, and I say that as a big Git enthusiast (but a Github hater, to be fair...)<p>I don't think PyPy gains anything from this, not even a reduction in the annoying messages that have been psychologically torturing the maintainers. If anything, you're just opening yourself up to more common and frequent low-investment pestering.
> foss.heptapod.net is not well indexed in google/bing/duckduckgo search, so people find it harder to search for issues in the project.<p>SEO : WWW structure :: gravity : orbital mechanics