HSL Env: Introduction

[azjezz]

👋

I wanted to bootstrap the work on HH\Lib\Env, so this is PR is more of a "meta PR" to keep the discussion going.

This API is borrowed as-is from PSL, and it was initially inspired by the std::env crate from Rust.

The component contains common functions that are needed for day-to-day operations especially when writing CLI applications, such as dealing with process environment variables, retrieving args, and retrieving the current directory/script.

I'm not sure if this is the API we want in Hack, but so far, it has served it's purpose really well in both PHP and Rust.

Note: this PR missing the Env\current_exec() implementation, as it's a bit messy in PHP ( see current_exec.php ), so I'm wondering if there's a better way to do that here.

[fredemmott]

Sorry, we're not able to review this until we are able to review request data as a whole: query strings, environment variables, POST data, headers, ... . We're not just looking for a good solution for environment variables or 'the environment', but want a consistent solution regardless of request type (http/CLI/thrift/xbox/...) and we also want to be sure we've found the right definition of 'the environment'.

Some implications there:

• we will likely consider the environment variables to be request data
• they will likely be immutable, but modified forms can be passed to new subprocesses. This is actually already the case but HHVM hides this by maintaining its' own map per request/thread, and using that instead of the true environment variables when Hack code attempts to access environment variables or spawn subprocesses. This is because environment variables are per-process, and HHVM runs different requests in different threads in the same process, and they need an independent set. If you called a C function that printed the true environment variables, it would not match what Hack code shows. Now that we no longer are compatible with PHP, that faking no longer needs to be built-in, and frameworks can add their own emulation instead if they desire.
• I know this is based on the rust design, but the working directory is unlikely to be there
• working directory has similar thread vs process issues/HHVM fakery
• it's not clear how environment variables should be handled for fastcgi requests: the current behavior is we emulate the classic CGI environment variables, but that should probably stop, and they should be filtered out/exposed directly through an alternative API