I am creating a jRuby gem at the moment and I may need to expose different commands (from the bin folder) to different type of users. Is that a good standard to create different gems for that, such as "_userX" or "_userY"? (And also the gem name may be different from the project name, which I know it's not a standard)
So I my need something like "mygem_for_admin_users" vs. "mygem_for_normal_users".
It definitely works, and there are definitely people doing it (example: https://github.com/mongodb/mongo-ruby-driver).
This is obviously very subjective, but I personally feel that it's bad practice to have a gemspec that doesn't match the project name, or multiple gemspecs in a single project. Ultimately, if it's the cleanest solution to the problem, it's the cleanest solution, and you should go for it, but first consider other ways of going about it:
You could have one base gem and 2+ interface gems that expose different sets of commands from the base gem.
You could somehow identify the different classes of users from the library itself, making all the commands available, but some of them restricted unless the right user type is set
You could build everything into one command with many subcommands (like bundle or git) that does the same reasoning about user types
There may be more options.
TL;DR: It's not great practice, but people do it and nothing will catch on fire. Just make sure that there isn't an easy way to avoid it first.