-
Notifications
You must be signed in to change notification settings - Fork 18
Added some overview to the docs - would have helped me get my head around it faster #18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
The add() method can now accept a "modules" (plural) argument that is a hasref containing ModuleName => ModuleVersion pairs. This can be used as an alternative to (but not in conjunction with) the "module" (singular) and version arguments. In practice, any non-trivial distribution is going to contain multiple modules. And those modules could all have different version numbers. But the old "module" (singular) and "version" interface did not support that reality. In fact, mcpi[1] worked around this limitation by calling add() for each module in the distribution. Not only did this seem odd, it causes the tar.gz file to be needlessly copied several times. I would even sugges that the old "module" (singular) and "version" interface sould be deprecated. I added test cases to cover the new interface. Also added test cases to cover the argument validation logic for the add() method. And I updated the POD accordingly.
I decided to just keep the old name for this subroutine, just to minimize churn. Although this sub is only useful for the add() method.
Now I just have to make the code actually behave that way.
You may now specify the version argument with the modules (plural) argument. This serves as the default version of any modules that you did not specify an explicit version number for. This is convenient for module authors (like me) who assign the same version number to all modules in a particular release.
The --module option for mcpi[1] now takes MODULE_NAME=MODULE_VERSION arguments and can be repeated for multiple modules. If you do not specify a MODULE_VERSION for any given MODULE_NAME, then the value of the --version option is used as the default. Here are some examples: # Adds Foo-1.2 and Bar-2.3 mcpi --add --module Foo=1.2 Bar=2.3 --author ME --file Distro.tar.gz # Adds Foo-1.2 and Bar-4.1 mcpi --add --module Foo=1.2 Bar --version 4.1 --author ME --fle Distro.tar.gz # Adds Foo-5.2 and Bar-5.2 mcpi --add --module Foo --module Bar --version 5.2 --author ME --file Distro.tar.gz Notice that this is still perfectly compatible with the old style of using --module and --version to add a single module.
Instead of having separate module (singular) and modules (plural) arguments, the module argument is now polymorphic, and will accept either a stirng (for one module) or a hashref (for multiple modules).
|
@wchristian I'm reviewing the PRs as part of my contribution to the Pull Request Challenge in September 2017. This PR is obsolete, as it has already been included in #12. It seems @timbunce created a PR against Jeffrey's branch, which he consequently merged. We can close this PR and not merge it as it's only relevant to #12. |
|
I've cherry-picked 5b6e80a into briandfoy/cpan-mini-inject@66e65bc, and the rest of the commits from #12 I'll look at later as part of briandfoy/cpan-mini-inject#1. |
|
This is part of 1.002. I can't close this issue though. Thanks, |
Hi Andy. I was tidying up my old git repos and found this one I hadn't sent a pull request for.