Add rcutils_set_env function

[cottsay]

This change adds a simple function for setting or un-setting an environment variable for the process.

The existing environment variable functions in rcutils are under a header called get_env.h. It might be good to deprecate that header and move the functionality to the more generically-named env.h. I'd love to hear feedback on that.

If we decide to keep a separate get_env.h header moving forward, I should probably rename this one to set_env.h.

• Linux
• Linux-aarch64
• macOS
• Windows

[ahcorde]

LGTM, just check the env vars in the CMake

[clalancette]

The existing environment variable functions in rcutils are under a header called get_env.h. It might be good to deprecate that header and move the functionality to the more generically-named env.h. I'd love to hear feedback on that.

Yes, I'd be all for that.

[cottsay]

The existing environment variable functions in rcutils are under a header called get_env.h. It might be good to deprecate that header and move the functionality to the more generically-named env.h. I'd love to hear feedback on that.

Yes, I'd be all for that.

It's too late to deprecate get_env.h in Foxy, but we can at least make the new header compatible in Foxy. We can deprecate get_env.h in G and remove it in H.

I added get_env.h to env.h in 9c67776.

[dirk-thomas]

What is the reason to add this function at all? What is it needed for?

[cottsay]

What is the reason to add this function at all? What is it needed for?

I need to modify the environment for some feature testing in another package, where changing the environment for the entire test isn't desirable. This change clearly demonstrates that there isn't a foolproof cross-platform solution for doing it. If I'm going to do the work to create that mechanism and the accompanying tests, I thought it best to put it somewhere others can use it, especially because there are already some other environment functions to accompany it.

[cottsay]

I had another thought while reading the MSDN docs: Since you can't create an empty environment variable on Windows (setting it to "" just removes the variable), should I replicate that behavior on *nix as well, so that the behavior is always consistent across platforms?

[dirk-thomas]

I don't think prevent users on Linux to do what is possible on that platform is a good idea. I would rather document the difference in the docblock.

[cottsay]

I don't think prevent users on Linux to do what is possible on that platform is a good idea. I would rather document the difference in the docblock.

Perfectly acceptable to me. Thanks for the feedback.

[cottsay]

I would rather document the difference in the docblock.

Done in 4ba9470

[fujitatomoya]

lgtm,

[clalancette]

The code looks good to me.

Are you intending to land this for Foxy, or can we defer this to after that?

[cottsay]

Are you intending to land this for Foxy...?

It's a well-reviewed and tested addition to the API, and I'd like to use it in some tests in a downstream package, so it would be nice to land in Foxy. This package hasn't bumped to 1.0.0 yet, so I think there is another release that needs to happen anyway. Sound okay, @jacobperron?

[jacobperron]

@cottsay I think since this is an addition (not modifying existing API), it's fine to land it for Foxy.

[cottsay]

...it's fine to land it for Foxy.

Grazie!