Add FromIterator<Process> for Launch

[joshwlewis]

Currently, collecting a dynamically created list of Processes into a Launch has to be done manually. Something like this:

let mut launch = Launch::new();
let procs: Vec<Process> = ["web", "worker"]
    .iter()
    .map(|name| ProcessBuilder::new(name.parse().unwrap(), name.to_string()).build())
    .collect();
for proc in procs.iter() {
    launch = launch.process(proc.clone());
}

With a FromIterator, it gets a bit easier:

let launch: Launch = ["web", "worker"]
    .iter()
    .map(|name| ProcessBuilder::new(name.parse().unwrap(), name.to_string()).build())
    .collect();

[Malax]

I'm not 💯 sold on the idea that an iterator of Process should be collectable into a CNB launch config - from a semantics standpoint. A launch config is more than just a list of processes and when we add SBOM support, the non-process bits of the launch config become more important.

I however do agree that it should be easier to construct a launch config when you just have a collection of processes.

What do folks think about adding a Launch::processes that allows users to add anything that can be turned into an Iterator of Process (via the appropriate traits) as the list of processes for a launch config? I've seen this pattern for builders before where you can either add single items or multiples using a different function. The most prominent example is probably std::process::Command (arg and args). See code below:

#[must_use]
pub fn processes<P: Into<Process>, I: IntoIterator<Item = P>>(mut self, processes: I) -> Self {
    for process in processes {
        self.processes.push(process.into())
    }

    self
}

Using the API above, the launch_from_iterator test from this PR would look like this:

#[test]
fn launch_from_iterator() {
    let launch: Launch = Launch::new().processes(
        ["web", "worker"]
            .iter()
            .map(|&name| ProcessBuilder::new(name.parse().unwrap(), name).build()),
    );

    assert_eq!(launch.processes[0].command, "web");
}

IMO, this is not worse in terms of verbosity than the original API proposal from this PR as this only adds one line, but also removes the collect call. But we are much more explicit about what happens here.

[Malax]

See comment on the PR.

[edmorley]

I've seen this pattern for builders before where you can either add single items or multiples using a different function. The most prominent example is probably std::process::Command (arg and args).

Plus several similar APIs in libcnb, eg env vs env in libcnb-test:
https://docs.rs/libcnb-test/latest/libcnb_test/struct.PrepareContainerContext.html#method.env

[joshwlewis]

A launch config is more than just a list of processes and when we add SBOM support, the non-process bits of the launch config become more important.

Great point.

This seems fine:

    let launch: Launch = Launch::new().processes(
        ["web", "worker"]
            .iter()
            .map(|&name| ProcessBuilder::new(name.parse().unwrap(), name).build()),
    );

Though, I've kind of developed a taste for chaining methods over nested arguments. I guess I'm noticing a pattern in my buildpacks that looks like

ThingBuilder::new(
  Other::new(
    Blah::new().build()
  ).build()
).build()

These just read inside out to me compared to a chained approach, and I guess that was partly motivating the FromIterator for me. I think I may just wanting a |> type operator for Rust.