Assignment of environment variables.

[amcgregor]

Friendly tl;dr warning.

Use Case

With scripts in language bundles (truffles), regardless of the underlying language for the script (JS, BASH, Ruby, Python, etc.) it is a requirement for my projects to have environment variables set to simulate a UNIX "chroot" at the language level. I primarily program Python, in which case my packages and their dependancies are isolated using a system called virtualenv. Virtualenv is usable one of two ways:

• System-native Python interpreter but with PYTHON_PATH set.
• Virtual environment-specific Python interpreter via a defined PATH.

There are other useful environment variables to control SCM systems, for use in truffle-based templates and snippets (e.g. my name, organization name, etc.) and can be used to configure more advanced truffle scripts on a per-project basis without modifying the truffles themselves.

Behaviour

This mockup[1] demonstrates a simple addition to the project sidebar as a new collapsable section called, appropriately, "ENVIRONMENT". Behaviour would be thus:

• Hidden completely if no environment variables are set in the project.
• A new section (separator + menu item) in the context menu labelled "New Environment Variable…"
• The name of the environment variable is treated as its "file name" for when file renaming is implemented. (Click, delay, click and/or right-click "Rename".)
• Environment variables are edited just like files using the standard editor and BASH variable highlighting. (Colouring $ variables, e.g. /some/path/bin:$PATH) This includes multiple-selection based vertical splitting. [2]
• In the case of Actions → Build submenu items the BASH wrapper will need to be updated to export the variables defined in the project.
• In the case of JavaScript executed within Chocolat, these variables can be made available (after merging with the standard environment and expansion) as ENV or some-such.
• These are saved within the Chocolat project file as a dictionary of strings with the key CHEnvironment or some-such and sub-keys being the names of the variables.

  Notes

  1. This section should probably go first, considering it will almost universally remain collapsed and relatively unchanging after initial setup
  2. Yes, some environment variables can contain multiple lines or whole files. It's weird, but it happens. (Run set in a terminal for many examples.)

[CarterA]

I like this idea. What do you think, @fileability?

[kraih]

+1

There needs to be a way to edit environment variables.

[blaflamme]

+1

[amcgregor]

The way I've coded my replacement build.sh and friends for Python allows you to run a custom script instead of the default behaviour by setting CHOC_RUN, CHOC_REPL, CHOC_DEBUG, CHOC_BUILD, etc. These are placed in a temporary file and exec used to pass control. The contents of these variables is the script.

[amcgregor]

Now I have this need for my LaTeX documents: most need to be compiled with lualatex, some don't care. Some need additional command-line arguments to the compiler. Per-project environment variable support would solve this.

[locks]

+One

[amcgregor]

As some use cases, I need to provide the following variables for the system Python to understand the project I'm working on:

• PYTHONHOME
• PYTHONPATH
• DJANGO_SETTINGS_MODULE

If I can set VIRTUAL_ENV, I don't need to set PYTHONHOME or PYTHONPATH.

Python alone understands several additional environment variables:

• PYTHONSTARTUP
• PYTHONCASEOK (useful for those porting Python code from Windows)
• PYTHONENCODING (determines how encoding errors are treated)

For C~ projects, being able to override LDPATH, CFLAGS, and CXXFLAGS are important. For larger C~ projects, MAKEOPTS is useful. Additionally, the standard build scripts can be extended (like the Python ones) to support environment variable configuration or replacement. For example, defining CHOC_TEST on a Python project then choosing Check from the Actions menu would execute the contents of the variable as a BASH script.

The latter is useful in my case as setup.py test won't work… our project has no setup.py file. I need to direct 'check/test' execution through fab unittest; fab integration test, while the default behaviour is quite acceptable for the majority of Python projects… unless you develop using virtualenvwrapper, in which case the build scripts won't be able to auto-detect the correct Python executable to run. (Solved by setting a PATH environment variable.)

[amcgregor]

Bump.