Emacs does not need to bundle Magit (or most other packages for that matter). What it needs is better package manager - built in!
As of recently, I'm an Emacs user (long time Vim user, just wanted some change) and I still have not completely comprehended how MELPA works. If anything should be more closely built in (and documented and standardised) to Emacs, package manager should. Everything else is better placed into outside packages.
If we look at Python world, here and there we can find discussions to include some library into stdlib and there are good reasons not to do it. Yes, batteries included is cool at first but it's no wonder that pythonistas say that "stdlib is place where packages go to die". We can think the same of Emacs and its package system.
What's the issue with the builtin package manager? After configuring your desired sources, any of the hundreds of packages available are literally an M-x package-install away (or package-list-packages if you want to browse around).
One of my biggest issues is that you can't request specific versions. Without that, the standard "big distributions" like spacemacs are doomed to constantly break. It's no accident quite a few Emacs power users plain don't use it.
> What it needs is better package manager - built in!
Er… it does? package.el has been included in Emacs since Emacs 24[0], and there's an official package repository[1] which is included by default, alongside the older MELPA and Marmalade which you can add to 'package-archives if you want packages from there.
> I still have not completely comprehended how MELPA works.
MELPA is just a repository for package.el.
> If anything should be more closely built in (and documented and standardised) to Emacs, package manager should.
Just like other built-in things, the package.el is way too basic, both in terms of features and interface. It's also useless for packages you'd like to closely follow, as it cannot deal with git/bzr/hg/whathaveyou. Inability to pin some package to the given version is also a major pain.
It's kind-of OK for beginners, but for more advanced users it's disappointing. It's better, IMHO, to think about package.el as a low-level library implementing some functions useful for package management - but calling it a package manager, while technically correct, seems like a bit of a stretch.
There are other projects however, like el-get, which work. So it's not like Emacs has no package manager. It's just that the "real" package managers are far away from being built-in.
I think one reason why people don't know about the emacs package manager is a lot of people know emacs from Linux servers, many of which run ancient versions of CentOS (for "reliability"). I ended up installing my own version of emacs in my home directory because the installed version in /usr/bin is 23.1.1.
Speaking as a Debian user; so maybe not part of the majority, but the last problem that the world faces is not enough package managers.
As far as I know, even Windows and MacOS have made moves towards implementing package managers AKA App Stores. I know iOS has it in spades. The Linux distributions have the problem of packet management figured out to their tastes.
Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.
> Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.
The central problem is that from an upstream author's perspective, distro package management is a nightmare.
Once upon a time, I tried maintaining Debian and RPM packages for my software. The process to become a Debian package maintainer was incredibly onerous and bureaucratic. Furthermore, dpkg is designed around the idea that you really should have exactly one version of each dependency across an entire system, for every piece of software that depends on it. And finally, the Debian stable version was usually years out of date.
RPM-based distributions had their own problems: Different, incompatible RPM features, dependency hell, etc. And of course, between dpkg and RPM, there were a half-dozen popular Linux distros, and two popular "distro" package managers on the Mac.
So I gave up. I distribute virtually all of my software using "language" package managers like bundler, npm and cargo. (And the rest as statically linked musl-libc binaries or Docker images.) These have top-notch support for dependency management, semantic versioning, and cross-platform builds. They're about a decade more advanced that dpkg or RPM for the things I care about. And if for some reason I need a GUI app, there's always Electron.
With cargo, TravisCI and AppVeyor, I can package a CLI tool for every popular system (including Windows) in a weekend, with automated cross-platform tests, and I'll rarely ever think about it again. And all my users can always get the latest versions, not three-year-old versions.
Anybody who wants to package my software for a distro is welcome to do so. I wash my hands of it all, and I'm extremely unlikely to provide any support.
I concur, el-get is quite nice and can install/manage packages from a wide variety of sources, sort of like Arch's AUR. It's at https://github.com/dimitri/el-get.
As of recently, I'm an Emacs user (long time Vim user, just wanted some change) and I still have not completely comprehended how MELPA works. If anything should be more closely built in (and documented and standardised) to Emacs, package manager should. Everything else is better placed into outside packages.
If we look at Python world, here and there we can find discussions to include some library into stdlib and there are good reasons not to do it. Yes, batteries included is cool at first but it's no wonder that pythonistas say that "stdlib is place where packages go to die". We can think the same of Emacs and its package system.