Include specs in published gems

[thesamesam]

Describe the feature

Would it be possible to include the specs/tests for each component/module within their respective gems?

Right now, downloading these from rubygems.org doesn't contain the tests, and with no git tags, it's hard to automatically grab the corresponding tests for a given version.

Use Case

Having specs in the published gems on rubygems.org would be real helpful for packaging in a Linux distribution because we try to run test suites for software wherever possible to verify compatibility with new versions of dependencies, new Rubies, etc.

Proposed Solution

No response

Other Information

I originally went looking for #2229 but realised that I don't really need tags, I just want the specs/tests to be easily accessible for a given version.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

3.170.0

Environment details (OS name and version, etc.)

Gentoo Linux

[mullermp]

Thanks for opening an issue. Did you encounter any compatibility issues? The SDK follows semantic versioning and tries to guarantee compatibility with Ruby > 2.3. IIRC it's not standard to really include tests in the gems and it would also greatly increase gem size.

[thesamesam]

No, but we have a lot of exotic platforms, so we generally want to be able to run tests to find them. Right now, we rely on people telling us if something breaks.

As for standard/not: yeah, I've seen a real mix of approaches to this. In Python land, it's a bit more likely that a PyPi dist will include tests, but in Ruby, I see it sometimes, but I often have to fall back to github tags (which isn't a big deal if they're available).

If this'd bloat the gems too much, I totally understand, and it'd probably be better for me to try think of a way to handle the git tagging instead like folks discussed in #2229. Thank you for replying quickly and explaining the issue here!

[mullermp]

That makes sense. Including the specs in the gems is definitely something we don't want to do. I've re-opened #2229 as I think we might be able to use release dates as git tags. We cannot really do git tags based around versions of our 300+ gems.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.