Re: [ELPA] New package: nspawn-tramp

[Brian Cully <bjc@spork.org>]

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