`mining_device` is blocking the publish of `integration_tests_sv2` to crates.io

[plebhash]

we're currently unable to publish integration_tests_sv2 to crates.io: https://github.com/stratum-mining/sv2-apps/actions/runs/23310666268/job/67796813420

I can see a few options ahead:

1. publish mining_device to crates.io
2. integrate mining_device into integration_tests_sv2 as a submodule

Peronally speaking, I lean towards 2, for a few reasons:

• we haven't maintained mining_device in a long time. The crate is full of technical debt and in my personal opinion, we shouldn't prioritize refactoring it.
• publishing to crates.io is irreversible, which makes it an undesirable strategy for workarounds.
• Mujina already supports CPU mining, and Sv2 support is on its way... it would be great if integration_tests_sv2 could use mujina as a dependency and we do all integration tests with it.

[jayrmotta]

A bit puzzled on the reasoning behind publishing integration_tests_sv2, I would imagine this is part of the proposal/vision.

sv2-apps readme mentions integration-tests/ - End-to-end integration tests validating interoperability between all components which sounds like a test suite apps usually have.

Maybe the idea is to allow future implementations to reuse test patterns or simply run those tests against their forks?

[Shourya742]

A bit puzzled on the reasoning behind publishing integration_tests_sv2, I would imagine this is part of the proposal/vision.

sv2-apps readme mentions integration-tests/ - End-to-end integration tests validating interoperability between all components which sounds like a test suite apps usually have.

Maybe the idea is to allow future implementations to reuse test patterns or simply run those tests against their forks?

Yes, the idea is for different rust implementation following few of our apps API standards like ('start` to spawn service, and couple more) to use the test suite directly.

[plebhash]

this is useful for anyone building Sv2 apps to make basic test assertions

say someone is building a custom Sv2 proxy

by adding integration_tests_sv2 to the dev section of their Cargo.toml, they can write tests that do integration_tests_sv2::lib::start_pool to deploy a pool and leverage Sniffer to assert the message exchange between SRI pool and their custom proxy