Publishing nitrocli-ext

[robinkrahl]

How should we publish nitrocli-ext? From my understanding, it is intended to be used both by our core extensions and by third-party extensions. Therefore it should be published on crates.io.

[d-e-s-o]

I try to go the minimal route first and see where it fails us (given that we are talking functionality that we need to support long term). My thinking was that it's an implementation detail, not a means for third-party extensions to be written. As such, I'd not want to publish it to crates.io.

Extensions can do what they want with the interface we have defined, and that interface is currently comprised of a few environment variables, including the path to nitrocli, the invocation of which we intend and for which we in turn also define certain behaviors (not a lot at the moment that could be worked with, but that's where the stable format would come into play). Any particular implementation of this interface (as nitrocli-ext provides), is of no concern to third party extensions.

So to answer your question:

How should we publish nitrocli-ext?

It's published in the form of a source code archive on GitHub, comprising the contents of the repository when a release is cut.

[robinkrahl]

My problem with this is that it effectively discourages writing extensions. We don’t have to support nitrocli-ext 0.1.0 forever. If we find issues with it, well, we release 0.2.0 and make changes. But once we think it is good enough to be used for our core extensions, I don’t see why we wouldn’t release it.

[d-e-s-o]

My problem with this is that it effectively discourages writing extensions.

I don't think of it this way. For one, writing an extension is driven by a need: if someone wants to interface with a Nitrokey for a specific purpose then this can be one way to go. Whether there is a crate that takes up a small part of the work should be secondary and an implementation detail.

The way I see it, we have defined the interface we want extensions to use so we should make them stick to it. If we now say that it's unlikely that people will actually use it because it's too cumbersome to do so, then perhaps the interface is bad/too low level/whatever the reason.

In any case, given that it seems that over in #166 we determined a need for publishing extensions we would also need to publish nitrocli-ext in that case. So we should probably first wrap up this discussion.

[robinkrahl]

The way I see it, we have defined the interface we want extensions to use so we should make them stick to it. If we now say that it's unlikely that people will actually use it because it's too cumbersome to do so, then perhaps the interface is bad/too low level/whatever the reason.

I don’t really get this point. Publishing nitrocli-ext would not mean that all extensions would have to use it, or that it would somehow replace the extension interface specification. It would just be a tool for authors that happen to want to use Rust to implement their extensions.

Of course they could implement it from scratch, but why not provide an easy interface if we already did the work to implement it? That does not mean that the underlying interface is bad.

[d-e-s-o]

The way I see it, we have defined the interface we want extensions to use so we should make them stick to it. If we now say that it's unlikely that people will actually use it because it's too cumbersome to do so, then perhaps the interface is bad/too low level/whatever the reason.

I don’t really get this point. Publishing nitrocli-ext would not mean that all extensions would have to use it, or that it would somehow replace the extension interface specification. It would just be a tool for authors that happen to want to use Rust to implement their extensions.

Yeah, but it would mean that in addition to the "lower" specification we already have we now have to support yet another one (in the form of code) in a stable API kind of sense. I'd want to keep that API surface as small as possible.

Of course they could implement it from scratch, but why not provide an easy interface if we already did the work to implement it? That does not mean that the underlying interface is bad.

For me it mostly ties into the above: the need to maintain a stable API, but it appears we have differing views in this regard.

Anyway, I think we can safely close this issue with #169 merged. I suggest we create a new one once we feel more confident about the Rust extension interface and have ironed out the various versioning/compatibility challenges that it introduces on even core extensions that we ship.