I think I've seen the concept of meta gems to include options. i.e. there is already an NUnit gem, so make a sharptests gem without either of the optional pieces, then a sharptests+nunit gem that includes a dependency on sharptests and nunit. You might give that a go.
(BTW, thanks for doing this one! I've been hoping to see sharptestsex packaged up.)
then we'd have, castle-core and sharp_tests_ex
It'd be confusing to try and infer the rule from examples, but once you know the rule I think this would be pretty nice. (it would also enable searching tricks like "castle-" for all the castle projects)
Sent from my iPad
This is also why we only package releases. A release is a specific point in time with specific dependencies.
So your sharptestsex-nunit v1.2.3 (made up version) is version 1.2.3 of sharptestsex and it has a dependency on say nunit 2.5.5. sharptestsex-nunit v1.2.4 may have a dependency on nunit 2.5.7. But it's two releases/versions of the same gem, not two different gems.
- v1.2.3 (dependency on nunit 2.5.5)
- v1.2.4 (dependency on nunit 2.5.5)
These dependencies are decided by the project committers, not the users. When you are a user of the gem, you get presented with options when you have a different version of nunit versus what the version of sharptestsex requires. You have to then choose to downgrade nunit, try to use the different versions and manually resolve the incompatibilities, or not use the new library you wanted to import. This feature of nu is what we are working on now. Right now it should automatically downgrade nunit to the version the library requires.
Does all this make sense?
"Be passionate in all you do"
> Right now it should automatically downgrade nunit to the
> version the library requires.
This raised a question in my mind. I hope when you say "downgrade"
you mean only in the scope of the current project and not globally.