4 ms·

Why would it be important to distribute Magit as part of Emacs? Why not just install it via MELPA?

gh02t 9y ago
No need to install it on remote systems. I'm more of a Vi guy and I have a decent selection of plugins on my primary system, but I appreciate being able to use the built in Vim features without installing stuff on remote machines. Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.
- Myrmornis 9y ago
  And you can use the built-in emacs features via emacs -nw on a remote system. Core vim doesn't come with a git client I assume? So I'm not seeing the difference. The other answer is apt-get install emacs-core-plus-standard-packages or apt-get install emacs-core emacs-magit emacs-org-mode i.e. people produce linux packages that set up emacs with its MELPA packages. If we don't put stuff like org-mode and magit in emacs then the community will produce emacs distributions bundling the standard add-ons.
- Grue3 9y ago
  There's no need to install Magit on remote systems. It works flawlessly over TRAMP and I use it every day like that.
0xcde4c3db 9y ago
> Why not just install it via MELPA? Specifically addressing this point (since major distros already package magit): There are environments where it's not allowed to install software that hasn't been cleared by site/department/company IT, let alone software from a rolling repository where packages aren't signed and upstream maintainers can get code in just by tagging it on GitHub. In such an environment it's a lot easier to say something like "I need Debian 12 with build-essential and emacs26". As cool and handy as it is, MELPA is kind of scary from a security standpoint.
- jhbadger 9y ago
  That's true in terms of many Linux systems being locked down to normal users (no installing in /usr or even /usr/local). But emacs extensions install in your home directory. I've never heard of a system where users couldn't write to their own home directories.
  - _jal 9y ago
    > I've never heard of a system where users couldn't write to their own home directories. Neither have I, but I have heard of (and been subject to) policies that don't allow installing unapproved 3rd party executable code, and have not seen one that made exceptions based on path.
    - JoshTriplett 9y ago
      I've heard of such policies, but only in the context of working for TLAs or certain high-risk positions in financial institutions. But also, if such policies were based on (for instance) "noexec", you don't have to be able to run executables to install elisp code.
      - _jal 9y ago
        Mine was neither, just a contract gig at a crappy company. There were no technical measures in place to stop me from compiling my own binaries (that was in part what I was there to do), and bringing my own elisp also would have worked. Except for the "breaking my contract" part, if it was unapproved 3rd party code. Given that actual FTEs respected the rule, it seemed unwise to test it.

No need to install it on remote systems. I'm more of a Vi guy and I have a decent selection of plugins on my primary system, but I appreciate being able to use the built in Vim features without installing stuff on remote machines. Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.

Myrmornis 9y ago
And you can use the built-in emacs features via emacs -nw on a remote system. Core vim doesn't come with a git client I assume? So I'm not seeing the difference. The other answer is apt-get install emacs-core-plus-standard-packages or apt-get install emacs-core emacs-magit emacs-org-mode i.e. people produce linux packages that set up emacs with its MELPA packages. If we don't put stuff like org-mode and magit in emacs then the community will produce emacs distributions bundling the standard add-ons.
Grue3 9y ago
There's no need to install Magit on remote systems. It works flawlessly over TRAMP and I use it every day like that.

0xcde4c3db 9y ago

> Why not just install it via MELPA? Specifically addressing this point (since major distros already package magit): There are environments where it's not allowed to install software that hasn't been cleared by site/department/company IT, let alone software from a rolling repository where packages aren't signed and upstream maintainers can get code in just by tagging it on GitHub. In such an environment it's a lot easier to say something like "I need Debian 12 with build-essential and emacs26". As cool and handy as it is, MELPA is kind of scary from a security standpoint.

jhbadger 9y ago
That's true in terms of many Linux systems being locked down to normal users (no installing in /usr or even /usr/local). But emacs extensions install in your home directory. I've never heard of a system where users couldn't write to their own home directories.
- _jal 9y ago
  > I've never heard of a system where users couldn't write to their own home directories. Neither have I, but I have heard of (and been subject to) policies that don't allow installing unapproved 3rd party executable code, and have not seen one that made exceptions based on path.
  - JoshTriplett 9y ago
    I've heard of such policies, but only in the context of working for TLAs or certain high-risk positions in financial institutions. But also, if such policies were based on (for instance) "noexec", you don't have to be able to run executables to install elisp code.
    - _jal 9y ago
      Mine was neither, just a contract gig at a crappy company. There were no technical measures in place to stop me from compiling my own binaries (that was in part what I was there to do), and bringing my own elisp also would have worked. Except for the "breaking my contract" part, if it was unapproved 3rd party code. Given that actual FTEs respected the rule, it seemed unwise to test it.