search

d-e-s-o / nitrokey-test

Supporting test infrastructure for the nitrokey crate and others using it.
GNU General Public License v3.0
0 stars 1 forks source link

Fix error code for new nitrokey version #2

Closed robinkrahl closed 5 years ago

robinkrahl commented 5 years ago

In nitrokey 0.4, the connect functions will return a Result<_, Error> instead of a CommandError. Connection failure will be indicated by the CommunicationError::NotConnected variant. This patch changes the nitrokey error handling to use these new error types.

Could you release this as 0.2.0 so that I can use it in nitrokey-rs?

d-e-s-o commented 5 years ago

Will get to it today. Thanks for the adjustment!

d-e-s-o commented 5 years ago

Merged & new version published!

robinkrahl commented 5 years ago

Thanks!

d-e-s-o commented 5 years ago

Do you have a rough timeline for the release of the new nitrokey version, @robinkrahl? I have a couple of changes for nitrokey-test in the works, but given that the new version of the crate requires a yet-to-be-released version of nitrokey I can't really release anything.

robinkrahl commented 5 years ago

Do you have a rough timeline for the release of the new nitrokey version, @robinkrahl?

I want to include the changes discussed in the preconditions thread, and possibly remove the re-exports from the lib module. Then I’ll release 0.4.0. I think this won’t take longer than a week. If it helps you, I can publish a release candidate that you can use for nitrokey-test.

d-e-s-o commented 5 years ago

If it helps you, I can publish a release candidate that you can use for nitrokey-test.

That would be awesome! All I care about is that the error code refactoring be included.

robinkrahl commented 5 years ago

On 2019-01-27 07:49:06, Daniel Müller wrote:

That would be awesome! All I care about is that the error code refactoring be included.

I can do that. But there might be additional breaking changes in the next version (connection refactoring, re-exports from lib). Is that a problem? Do you want me to keep the current API as a fallback for some time?

d-e-s-o commented 5 years ago

Those breaking changes should not affect me. All I plan on doing is to depend on nitrokey for running an empty test as part of the nitrokey-test suite. So I don't think you need to keep the fall back.