search enables you to search for either module or author objects, based on their data. The type you can specify is any of the accessors specified in CPANPLUS::Module::Author or CPANPLUS::Module. search will determine by the type you specified whether to search by author object or module object.

You have to specify an array reference of regular expressions or strings to match against. The rules used for this array ref are the same as in Params::Check, so read that manpage for details.

The search is an or search, meaning that if any of the criteria match, the search is considered to be successful.

You can specify the result of a previous search as data to limit the new search to these module or author objects, rather than the entire module or author tree. This is how you do and searches.

Returns a list of module or author objects on success and false on failure.

Returns a list of module objects representing all releases for this module on success. @mods can be a list of distribution names, module names or module objects, basically anything that parse_module can understand.

See the equivalent method in CPANPLUS::Module for details on other options you can pass.

Since this is a multi-module method call, the return value is implemented as a CPANPLUS::Backend::RV object. Please consult that module's documentation on how to interpret the return value.

These items would all come up with a CPANPLUS::Module object for Text::Bastardize. The ones marked explicitly as being version 1.06 would give back a CPANPLUS::Module object of that version. Even if the version on CPAN is currently higher.

The last three are examples of PATH resolution. In the first, we supply an absolute path to the unwrapped distribution. In the second the distribution is relative to the current working directory. In the third, we will use the current working directory.

If parse_module is unable to actually find the module you are looking for in its module tree, but you supplied it with an author, module and version part in a distribution name or URI, it will create a fake CPANPLUS::Module object for you, that you can use just like the real thing.

Creates a local mirror of CPAN, of only the most recent sources in a location you specify. If you set this location equal to a custom host in your CPANPLUS::Config you can use your local mirror to install from.

Enable/disable fetching of index files. You can disable fetching of the index files if you don't plan to use the local mirror as your primary site, or if you'd like up-to-date index files be fetched from elsewhere.

Explicit command to save memory state to disk. This can be used to save information to disk about where a module was extracted, the result of make test, etc. This will then be re-loaded into memory when a new session starts.

The capability of saving state to disk depends on the source engine being used (See CPANPLUS::Config for the option to choose your source engine). The default storage engine supports this option.

Most users will not need this command, but it can handy for automated systems like setting up CPAN smoke testers.

The method will return true if it managed to save the state to disk, or false if it did not.

Besides the sources as provided by the general CPAN mirrors, it's possible to add your own sources list to your CPANPLUS index.

The methodology behind this works much like Debian's apt-sources.

The methods below show you how to make use of this functionality. Also note that most of these methods are available through the default shell plugin command /cs, making them available as shortcuts through the shell and via the commandline.

Updates the indexes for all your custom sources. It does this by fetching a file called packages.txt in the root of the custom sources's URI. If you provide the remote argument, it will only update the index for that specific URI.

Here's an example of how custom sources would resolve into index files:

The file packages.txt simply holds a list of packages that can be found under the root of the URI. This file can be automatically generated for you when the remote source is a file:// URI. For http://, ftp://, and similar, the administrator of that repository should run the method $cb->write_custom_source_index on the repository to allow remote users to index it.

For details, see the $cb->write_custom_source_index method below.

All packages that are added via this mechanism will be attributed to the author with CPANIDLOCAL. You can use this id to search for all added packages.

Writes the index for a custom repository root. Most users will not have to worry about this, but administrators of a repository will need to make sure their indexes are up to date.

The index will be written to a file called packages.txt in your repository root, which you can specify with the path argument. You can override this location by specifying the to argument, but in normal operation, that should not be required.

Once the index file is written, users can then add the URI pointing to the repository to their custom list of sources and start using it right away. See the $cb->add_custom_source method for user details.