$cb = CPANPLUS::Backend->new( [CONFIGURE_OBJ] )

Provide a valid "CPANPLUS::Configure" object

This will be used verbatim.

No arguments

Your default config will be loaded and used.

New will return a "CPANPLUS::Backend" object on success and die on failure.

$href = $cb->module_tree( [@modules_names_list] )

If you give it any arguments, they will be treated as module names and "module_tree" will try to look up these module names and return the corresponding module objects instead.

See CPANPLUS::Module for the operations you can perform on a module object.

$href = $cb->author_tree( [@author_names_list] )

If you give it any arguments, they will be treated as author names and "author_tree" will try to look up these author names and return the corresponding author objects instead.

See CPANPLUS::Module::Author for the operations you can perform on an author object.

$conf = $cb->configure_object;

See CPANPLUS::Configure for operations you can perform on a configure object.

$su = $cb->selfupdate_object;

See the CPANPLUS::Selfupdate manpage for the operations you can perform on the selfupdate object.

@mods = $cb->search( type => TYPE, allow => AREF, [data => AREF, verbose => BOOL] )

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.

See CPANPLUS::Module for the operations you can perform on a module object. See CPANPLUS::Module::Author for the operations you can perform on an author object.

$backend_rv = $cb->fetch( modules => \@mods )

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.

$backend_rv = $cb->extract( modules => \@mods )

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.

$backend_rv = $cb->install( modules => \@mods )

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.

$backend_rv = $cb->readme( modules => \@mods )

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.

$backend_rv = $cb->files( modules => \@mods )

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.

$backend_rv = $cb->distributions( modules => \@mods )

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.

$mod_obj = $cb->parse_module( module => $modname|$distname|$modobj|URI|PATH )

Text::Bastardize

Text-Bastardize

Text/Bastardize.pm

Text-Bastardize-1.06

AYRNIEU/Text-Bastardize

AYRNIEU/Text-Bastardize-1.06

AYRNIEU/Text-Bastardize-1.06.tar.gz

http://example.com/Text-Bastardize-1.06.tar.gz

file:///tmp/Text-Bastardize-1.06.tar.gz

/tmp/Text-Bastardize-1.06

./Text-Bastardize-1.06

.

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.

See CPANPLUS::Module for the operations you can perform on a module object.

If even this fancy guessing doesn't enable "parse_module" to create a fake module object for you to use, it will warn about an error and return false.

$bool = $cb->reload_indices( [update_source => BOOL, verbose => BOOL] );

If "update_source" is set to true, this will fetch new source files from your CPAN mirror. Otherwise, "reload_indices" will do its usual cache checking and only update them if they are out of date.

By default, "update_source" will be false.

The verbose setting defaults to what you have specified in your config file.

Returns true on success and false on failure.

$bool = $cb->flush(CACHE_NAME)

• "methods"

  The return status of methods which have been attempted, such as different ways of fetching files. It is recommended that automatic flushing be used instead.

• "hosts"

  The return status of URIs which have been attempted, such as different hosts of fetching files. It is recommended that automatic flushing be used instead.

• "modules"

  Information about modules such as prerequisites and whether installation succeeded, failed, or was not attempted.

• "lib"

  This resets PERL5LIB, which is changed to ensure that while installing modules they are in our @INC.

• "load"

  This resets the cache of modules we've attempted to load, but failed. This enables you to load them again after a failed load, if they somehow have become available.

• "all"

  Flush all of the aforementioned caches.

Returns true on success and false on failure.

@mods = $cb->installed()

See CPANPLUS::Module for the operations you can perform on a module object.

$bool = $cb->local_mirror([path => '/dir/to/save/to', index_files => BOOL, force => BOOL, verbose => BOOL] )

It takes the following arguments:

path

The location where to create the local mirror.

index_files

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.

Defaults to true.

force

Forces refetching of packages, even if they are there already.

Defaults to whatever setting you have in your "CPANPLUS::Config".

verbose

Prints more messages about what its doing.

Defaults to whatever setting you have in your "CPANPLUS::Config".

Returns true on success and false on error.

$file = $cb->autobundle([path => OUTPUT_PATH, force => BOOL, verbose => BOOL])

    ### using the default shell:
    CPAN Terminal> i file://path/to/Snapshot_XXYY.pm

    ### using the API
    $modobj = $cb->parse_module( module => 'file://path/to/Snapshot_XXYY.pm' );
    $modobj->install;

It will, by default, write to an 'autobundle' directory under your cpanplus home directory, but you can override that by supplying a "path" argument.

It will return the location of the output file on success and false on failure.

$bool = $cb->save_state

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.

%files = $cb->list_custom_sources

    /full/path/to/local/index => http://remote/source

Note that any file starting with an "#" is being ignored.

$local_index = $cb->add_custom_source( uri => URI, [verbose => BOOL] );

Returns the full path to the local index on success, or false on failure.

Note that when adding a new "URI", the change to the in-memory tree is not saved until you rebuild or save the tree to disk again. You can do this using the "$cb->reload_indices" method.

$local_index = $cb->remove_custom_source( uri => URI, [verbose => BOOL] );

To find out what "URI"s you have as part of your own sources list, use the "$cb->list_custom_sources" method.

Returns the full path to the deleted local index file on success, or false on failure.

$bool = $cb->update_custom_source( [remote => URI] );

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

  file:///path/to/sources       =>  file:///path/to/sources/packages.txt
  http://example.com/sources    =>  http://example.com/sources/packages.txt
  ftp://example.com/sources     =>  ftp://example.com/sources/packages.txt

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 "CPANID" "LOCAL". You can use this id to search for all added packages.

$file = $cb->write_custom_source_index( path => /path/to/package/root, [to => /path/to/index/file, verbose => BOOL] );

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.