Re: [boost] [boost.process] 0.6 Redesign

Subject: Re: [boost] [boost.process] 0.6 Redesign
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-04-20 05:57:38

> It would be great if that interface, arguably nice, could boil down to a
> more template-less and simpler interface.
> Programs that tend to make an heavy use of external process launching
> usually need to setup how the process are launched in different stages. You
> might want to allow an iterative construction (and reuse) of the process
> launch options.
>
> For example:
>
>      struct process_options
>      {
>          boost::optional<boost::filesystem::path> working_directory;
>          boost::optional<std::map<std::string, std::string>> env;
>          struct channel { ... };
>          channel stdin;
>          channel stdout;
>          channel stderr;
>      };
>
> This can be hidden through a nice interface, using some good defaults.

I think the way you can do it is too diverse to cover it with defaults, 
and I actually don't know what good defaults would be. We already had 
the discussion here about making everything async.

I.e. we would sacrifice a lot of flexibility. Of course you can 
implement the example above very easily with the process library:

struct my_process
{
     //btw: that's in, but not yet documented
     filesystem::path working_dir = this_process::pwd();
     process::environment env = this_process::environment();

     process::pipe in;
     process::pipe out;
     filesystem::path err;
     process::child launch(const std::string & cmd)
     {
        return process::execute(cmd, process::start_dir = working_dir,
                                process::std_in < in,
                                process::std_out > out,
                                process::std_err > err, env);
     }
};

BUT you can also use a functional style if you want to:

auto in_setting = process::std_in < null;
auto c = execute("thingy", in_setting);

>
> But when you need to setup dynamically how a process should be launched,
> there is no other choice than aggregating the setup options until the
> launch point. The previous version of boost.process did not allow it[1],
> and forced me to come up with my own thing[2]. Also, do you plan to port
> back the type erasure PR[3] to your new version ?
>
> Cheers,
>
> [1] https://github.com/BorisSchaeling/boost-process/issues/2
> [2]
> https://github.com/hotgloupi/configure/blob/master/src/configure/Process.hpp
> [3] https://github.com/BorisSchaeling/boost-process/pull/8

No and no. So first of all, I don't really get it: you have a few 
settings which will be aggregated like environment settings or args. Now 
those can already be joint before the call of execute, i.e.

execute("thingy", args+="para1", args+="para2", env["PATH"]+="/path1", 
env["PATH"]+="/path2");

//can be written as
environment env = this_process::environment();
env["PATH"] += "/path1";
env["PATH"] += "/path2";
vector<string> args = {"para1", "para2"};

execute("thingy", args, env);

The Problem with [2] and [3] is, that I now have the 
initializer-sequence as a template parameter of the executor. I did this 
so initializers can access the sequence, which was necessary for the 
async stuff (i.e. so they can access the io_service). This renders any 
virtualization impossible, because the handler-functions now have to be 
tempalted.
Also: though not yet implemented, I'd like to have a few compile-time 
checks, e.g. that you don't redirect a pipe twice etc. That would be 
completely impossible with a initializer sequence built at runtime.

Now: since we have a finite amount of initializers, it would be possible 
to implement some polymorphic sequence with boost.variant, but I still 
fail to see why that must be determined at runtime. Keep in mind: you 
would not determine the value of some initializer but which initializers 
you set. Do you have an example where it has to be done at runtime? That 
maybe helpful for me to understand the actual problem here. I really 
don't like to use runtime-polymorphy when it can be done at compile-time.