Expose api for extendability

[FaBrand]

This alloes wo construct the mapping structures of rules_pkg internal representation and to extend based on pkg_* rules

[tonyaiuto]

This feels sort of incomplete. We should lift the code out of private and make sure the stardoc on it works so it shows up in the docs.

[cgrindel]

I am not sure if feel qualified to approve the API change. @tonyaiuto do you want to elevate these to public scope?

[FaBrand]

@cgrindel i'll fix the pre-commit errors. Didn't notice it locally yet.

For context: #996 (comment)

[FaBrand]

Any update @tonyaiuto @cgrindel ?

[cgrindel]

I am deferring to @tonyaiuto on how to proceed.

[aiuto]

Sorry for the slow response.
I don't quite understand why it duplicates so much of process_src in package_content.bzl.
And create_mapping_context_from_ctx seems to have a behavior that should be documented make usage clear.

It looks like it does things like
strip_prefix is used as is, if provided, otherwise it defaults to the value from the original ctx.
But it feels like that should be up to the person writing their own rule wrapper.

Do you have a real world example of the need for that particular API?

[FaBrand]

@aiuto i moved the functions into a public package after the suggestion in: #996 (comment)

I can't share the code directly (internal policy...) but the gist is this:

1. Have a custom rule that uses pkg_* as srcs
2. Do something with it
3. Consume it in e.g. pkg_install

Basically the "pkg-rules sandwich"

My concrete use case is:

Define a rich hirarchy of pkg_files/filegroups/etc, have a pkg_jfrog_* ruleset that generates a jf-cli upload specification from this defined structure.

Afterwards use pkg_install to install it into a defined location instead of having to search and upload "something"

I found myself trying to read the different Providers of rules_pkg in my rule which ended up effectively duplicating e.g. process_src

It works well when buildifiers private visibility check, but of course is always a risk and not advisable to depend on private details

Hence my suggestion to expose these functions as a publicly usable interface to enable interfacing or injecting custom rules in the pkg-dependency graph

Sry for the lengthy text^^