Description

It will add an new feature which basically depends on --gemfile option.
The new --gemfile-deps option will only render specified Gems, instead of rendering the whole Gemfile.lock (automatically resolved dependencies) as --gemfile does.

Completed Tasks

• [x] I have read the Contributing Guide.
• [x] The pull request is complete (implemented / written).
• [x] Git commits have been cleaned up (squash WIP / revert commits).
• [x] I wrote tests and ran bundle exec rake locally (if code is attached to PR).

Coverage increased (+0.009%) to 93.527% when pulling c90bbaa13a0c855959000d1065f84c166f20928e on dopykuh:master into 9f14dbf4c140bedb1e0a47f52e350777b7ce9bd9 on lsegal:master.

I still don't see a problem statement here. Why is this needed?

I have a lot of gems which i will automatically generate documentation for, but i don't care about the resolved depencencies. I just want a list of my libaries not tens of others.

I understand this now. I'd prefer a better approach than adding yet another --gemfile* argument that does mostly the same thing as the other with an unclear distinction.

Calling them "dependencies" is not clear. Transitive dependencies are also dependencies, so saying "only dependencies" should not mean anything different. "Ignore transitive dependencies" would be more clear, but that's obviously wordy.

I'd actually be open to changing the behavior of --gemfile slightly to pick direct dependencies if Gemfile is selected, and include all dependencies if the Gemfile.lock is selected. This is technically a breaking change, though I believe this is the behavior that most users will want anyway, so breaking is relative. One could call the inclusion of transitive dependencies a bug in its own right.

Doing that would definitely mean waiting on any feedback though, and some investigation to see how many people might be affected.