Re: [ELPA] New package: nspawn-tramp

[Brian Cully]

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.