* [ELPA] New package: nspawn-tramp
@ 2022-02-19 14:09 Brian Cully
2022-02-19 15:05 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Brian Cully @ 2022-02-19 14:09 UTC (permalink / raw)
To: emacs-devel
This is a package that allows TRAMP to use systemd-nspawn based
containers (typically used with machinectl).
I've been dogfooding this myself for about a year now, and I hope that
others in the community will find it useful.
The package source can be found at: https://github.com/bjc/nspawn-tramp
If it gets accepted to ELPA, I'll adjust the README.org to include
instructions for how to install it from there.
-bjc
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-19 14:09 [ELPA] New package: nspawn-tramp Brian Cully
@ 2022-02-19 15:05 ` Stefan Monnier
2022-02-19 15:13 ` Andreas Schwab
2022-02-19 15:27 ` Brian Cully
0 siblings, 2 replies; 8+ messages in thread
From: Stefan Monnier @ 2022-02-19 15:05 UTC (permalink / raw)
To: Brian Cully; +Cc: emacs-devel
> This is a package that allows TRAMP to use systemd-nspawn based
> containers (typically used with machinectl).
>
> I've been dogfooding this myself for about a year now, and I hope
> that others in the community will find it useful.
>
> The package source can be found at: https://github.com/bjc/nspawn-tramp
>
> If it gets accepted to ELPA, I'll adjust the README.org to include
> instructions for how to install it from there.
I'd be happy to add it to GNU ELPA, but I have a few questions/comments
some of which may affect this decision, so I haven't done it yet:
- It's usually spelled "Tramp" rather than "TRAMP", AFAIK.
- I suggest you clarify that this is not about Tramp using (internally)
nspawnd to increase its security. So instead of "allows TRAMP to work
with containers", I'd say something like "teaches Tramp to access
nspawnd containers"?
- `nspawnd-tramp` suggests this adds Tramp support to nspawnd rather than
the reverse.
- Any reason why you want to have it as a separate package rather than
add it to Tramp?
- `nspawn-tramp-machinectl-path` does not hold a "path" (like $PATH and
`load-path`) but a "file name", please follow the GNU convention.
Stefan
diff --git a/nspawn-tramp.el b/nspawn-tramp.el
index e5233406fe..9b1cb0c795 100644
--- a/nspawn-tramp.el
+++ b/nspawn-tramp.el
@@ -1,6 +1,6 @@
;;; nspawn-tramp.el -- TRAMP integration for systemd-nspawn containers -*- lexical-binding: t; -*-
-;; Copyright © 2021 Free Software Foundation, Inc.
+;; Copyright © 2021-2022 Free Software Foundation, Inc.
;; Author: Brian Cully <bjc@kublai.com>
;; Maintainer: Brian Cully <bjc@kublai.com>
@@ -39,11 +39,11 @@
;;
;; Open a file on a running systemd-nspawn container:
;;
-;; C-x C-f /nspawn:user@container:/path/to/file
+;; C-x C-f /nspawn:USER@CONTAINER:/path/to/file
;;
;; Where:
-;; ‘user’ is the user on the container to connect as (optional)
-;; ‘container’ is the container to connect to
+;; USER is the user on the container to connect as (optional)
+;; CONTAINER is the container to connect to
;;
;; ## Privileges
;;
@@ -70,7 +70,7 @@
:link '(emacs-commentary-link :tag "Commentary" "nspawn-tramp"))
(defcustom nspawn-tramp-machinectl-path "machinectl"
- "Path to machinectl executable."
+ "File name of machinectl executable."
:type 'string
:group 'nspawn-tramp)
@@ -93,7 +93,7 @@ see its function help for a description of the format."
(defun nspawn-tramp--add-method ()
- "Add TRAMP method handler for nspawn conainers."
+ "Add TRAMP method handler for nspawn containers."
(push `(,nspawn-tramp-method
(tramp-login-program ,nspawn-tramp-machinectl-path)
(tramp-login-args (("shell")
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-19 15:05 ` Stefan Monnier
@ 2022-02-19 15:13 ` Andreas Schwab
2022-02-19 15:27 ` Brian Cully
1 sibling, 0 replies; 8+ messages in thread
From: Andreas Schwab @ 2022-02-19 15:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Brian Cully
On Feb 19 2022, Stefan Monnier wrote:
> - `nspawn-tramp-machinectl-path` does not hold a "path" (like $PATH and
> `load-path`) but a "file name", please follow the GNU convention.
Or rather a command or program.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-19 15:05 ` Stefan Monnier
2022-02-19 15:13 ` Andreas Schwab
@ 2022-02-19 15:27 ` Brian Cully
2022-02-19 18:11 ` Michael Albinus
1 sibling, 1 reply; 8+ messages in thread
From: Brian Cully @ 2022-02-19 15:27 UTC (permalink / raw)
To: emacs-devel
On 2/19/22 10:05, Stefan Monnier wrote:
> I'd be happy to add it to GNU ELPA, but I have a few questions/comments
> some of which may affect this decision, so I haven't done it yet:
>
> - It's usually spelled "Tramp" rather than "TRAMP", AFAIK.
The info page for it has it spelled as "TRAMP", although the link to it
from the list in the top-level (from "M-x info") has it as "Tramp". I
assume the former is correct given its specificity.
>
> - I suggest you clarify that this is not about Tramp using (internally)
> nspawnd to increase its security. So instead of "allows TRAMP to work
> with containers", I'd say something like "teaches Tramp to access
> nspawnd containers"?
What do you think of "... allows TRAMP access to environments provided
by systemd-nspawn"? I'll admit I'm having a hard time coming up with
language that addresses your concern and sounds natural.
> - `nspawnd-tramp` suggests this adds Tramp support to nspawnd rather than
> the reverse.
I did, initially, call it "tramp-nspawn", but changed it after
reviewing other packages which added container support to TRAMP, like
"docker-tramp" and "lxc-tramp". It doesn't matter much to me, so I went
with what seemed like existing convention.
> - Any reason why you want to have it as a separate package rather than
> add it to Tramp?
TRAMP provides a plugin capability, which is being used by other
packages, and it's already a behemoth. I see no need to include this
directly within TRAMP itself, as its needs are perfectly addressed without.
> - `nspawn-tramp-machinectl-path` does not hold a "path" (like $PATH and
> `load-path`) but a "file name", please follow the GNU convention.
I've renamed the variable to `nspawn-tramp-machinectl-file-name` and
adjusted its documentation.
Thank you for your patch. I've applied them and will push them up to my
repository when the current discussion concludes.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-19 15:27 ` Brian Cully
@ 2022-02-19 18:11 ` Michael Albinus
2022-02-19 20:21 ` Brian Cully
0 siblings, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2022-02-19 18:11 UTC (permalink / raw)
To: Brian Cully; +Cc: emacs-devel
Brian Cully <bjc@spork.org> writes:
Hi Brian,
> On 2/19/22 10:05, Stefan Monnier wrote:
>> I'd be happy to add it to GNU ELPA, but I have a few questions/comments
>> some of which may affect this decision, so I haven't done it yet:
>> - It's usually spelled "Tramp" rather than "TRAMP", AFAIK.
>
> The info page for it has it spelled as "TRAMP", although the
> link to it from the list in the top-level (from "M-x info")
> has it as "Tramp". I assume the former is correct given its
> specificity.
In tramp.texi, we use @value{tramp}. This variable is declared in
trampver.texi as
--8<---------------cut here---------------start------------->8---
@set tramp @sc{Tramp}
--8<---------------cut here---------------end--------------->8---
Therefore, it appears in info pages as "TRAMP". In Elisp docstrings and
comments, we use "Tramp". It looks a little bit inconsistent, but it is
... history. This texinfo variable was declared long before I've ever
heard about Tramp.
>> - Any reason why you want to have it as a separate package rather than
>> add it to Tramp?
>
> TRAMP provides a plugin capability, which is being used by
> other packages, and it's already a behemoth. I see no need to
> include this directly within TRAMP itself, as its needs are
> perfectly addressed without.
I understand your ressentiments. OTOH, living outside the Tramp source
tree let you miss changes. For example, Tramp meanwhile doesn't hardcode
"/bin/sh" any longer, but uses tramp-default-remote-shell instead. Not a
big deal for now, but these little adaptions make a Tramp package more
consistent, because you would get such a change for free if your package
is bundled with Tramp directly.
Best regards, Michael.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-19 18:11 ` Michael Albinus
@ 2022-02-19 20:21 ` Brian Cully
2022-02-20 13:37 ` Michael Albinus
0 siblings, 1 reply; 8+ messages in thread
From: Brian Cully @ 2022-02-19 20:21 UTC (permalink / raw)
To: emacs-devel
On 2/19/22 13:11, Michael Albinus wrote:
> Therefore, it appears in info pages as "TRAMP". In Elisp docstrings and
> comments, we use "Tramp". It looks a little bit inconsistent, but it is
> ... history. This texinfo variable was declared long before I've ever
> heard about Tramp.
Ok, I can change it to "Tramp". Thanks for filling me in.
>>> - Any reason why you want to have it as a separate package rather than
>>> add it to Tramp?
>>
>> TRAMP provides a plugin capability, which is being used by
>> other packages, and it's already a behemoth. I see no need to
>> include this directly within TRAMP itself, as its needs are
>> perfectly addressed without.
>
> I understand your ressentiments. OTOH, living outside the Tramp source
> tree let you miss changes. For example, Tramp meanwhile doesn't hardcode
> "/bin/sh" any longer, but uses tramp-default-remote-shell instead. Not a
> big deal for now, but these little adaptions make a Tramp package more
> consistent, because you would get such a change for free if your package
> is bundled with Tramp directly.
All the same, I think it makes more sense for this package to live
separately. In general, I much prefer to use plug-in mechanisms for
extension when possible, as I believe the separation of concerns to lead
to a more overall maintainable system. In this particular case, I think
the functionality I'm providing is fairly niche. Even in the container
space, systemd-nspawn containers aren't particularly popular.
On a personal note, I'm not willing to maintain this code if it's
integrated directly into Tramp, because I don't feel that I currently
have the needed expertise to do so. I've assigned copyright to the FSF,
however, so if someone wants to take the code and integrate it with
Tramp, rather than maintain a separate package, they are free to do so
and have my blessing.
-bjc
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-19 20:21 ` Brian Cully
@ 2022-02-20 13:37 ` Michael Albinus
2022-02-20 14:51 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2022-02-20 13:37 UTC (permalink / raw)
To: Brian Cully; +Cc: emacs-devel
Brian Cully <bjc@spork.org> writes:
Hi Brian,
> On a personal note, I'm not willing to maintain this code if
> it's integrated directly into Tramp, because I don't feel that
> I currently have the needed expertise to do so.
Well, this is not mandatory for you. There are Tramp citizens, which were
written by somebody else, and which are maintained by the Tramp
maintainer now. See for example tramp-adb.el.
> I've assigned copyright to the FSF, however, so if someone wants
> to take the code and integrate it with Tramp, rather than
> maintain a separate package, they are free to do so and have my
> blessing.
It's a while ago that I have played with containers. So I don't believe
I will be the guy who puts this package into Tramp proper. Personally, I
can live with both approaches, an integrated package or a GNU ELPA
package.
> -bjc
Best regards, Michael.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ELPA] New package: nspawn-tramp
2022-02-20 13:37 ` Michael Albinus
@ 2022-02-20 14:51 ` Stefan Monnier
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2022-02-20 14:51 UTC (permalink / raw)
To: Michael Albinus; +Cc: Brian Cully, emacs-devel
> It's a while ago that I have played with containers. So I don't believe
> I will be the guy who puts this package into Tramp proper. Personally, I
> can live with both approaches, an integrated package or a GNU ELPA
> package.
It should appear on GNU ELPA soonish.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-02-20 14:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-19 14:09 [ELPA] New package: nspawn-tramp Brian Cully
2022-02-19 15:05 ` Stefan Monnier
2022-02-19 15:13 ` Andreas Schwab
2022-02-19 15:27 ` Brian Cully
2022-02-19 18:11 ` Michael Albinus
2022-02-19 20:21 ` Brian Cully
2022-02-20 13:37 ` Michael Albinus
2022-02-20 14:51 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).