Mandrel, by design, is heavy handed in its expectations when you invoke its bootstrap machinery.

However, there are cases where it's nice if you don't have that heavy-handedness, and could instead just tell it where the project root lives.

So let's impose an environment variable: MANDREL_ROOT.

If given, then bootstrapping should automatically treat that as the root.
In so doing, it should process a Mandrel.py file if one exists in the specified root.
If no such file exists, that should not cause an error; the default search path and defautl logging behavior should all work fine.

The millisecond formatting stupidly uses an extra decimal digit making them all a factor of ten smaller than they should be.

Want to be able to specify classes or functions or whatever by name in configuration files and have them map to the actual python-space objects on access.

I'd like to port treehouse, which uses Mandrel, to python 3, but ran into problems because Mandrel isn't python 3 compatible.

The default logger configuration has some annoyances:

• Too verbose -- use INFO level instead of DEBUG
• Awful format -- Use a saner format that is less miserable

In particular, get an ISO timestamp of the %Y-%m-%dT%H:%M:%SZ variety, so it's sortable and less than hideous.

Including the pid as well would be nice.

Use a less awful delimiter so the log entries are more readable, too.

This is an odd use case, but if you're trying to import mandrel on a virtual machine with your current working directory being a mapped volume from OSX, it fails because OSX is a case-insensitive filesystem. When python is attempting to load the bootstrap module, it finds Mandrel.py in my current working directory (/mnt/hgfs/atebbe1/Documents/code/thingy/) and seems to load that instead of the installed package.

In this case, I am running mandrel-runner from a directory that contains a Mandrel.py bootstrap file

Traceback (most recent call last):
  File "/home/adam/virtualenv/bin/mandrel-runner", line 9, in <module>
    load_entry_point('mandrel==0.2.0', 'console_scripts', 'mandrel-runner')()
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 558, in load_entry_point
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2682, in load_entry_point
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2355, in load
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2361, in resolve
  File "/mnt/hgfs/atebbe1/Documents/code/thingy/mandrel.py", line 1, in <module>
    bootstrap.SEARCH_PATHS.append("/etc/conf")
NameError: name 'bootstrap' is not defined

To get around this, I would propose not naming the bootstrap file Mandrel.py, and adding support for an environment variable to override mandrel.bootstrap.__BOOTSTRAP_BASENAME

Mandrel should offer a configuration class variant that expects to get its attributes from environment variables.

There are a number of ways one could go about this. Certainly would could provide functionality to reduce environment variables down to a basic native (nested) dictionary, which could be used as the initial dict for a Configuration instance. However, it would probably be more idiomatic if the thing were a configuration class in its own right, which all other configuration extensions could use just by chaining.

The point is we want to be able to say things like:

• this variable is this attribute, and it should be an integer
• this variable is this attribute, and it should be a comma-separated list of strings
• variables with this prefix are a nested dict (which is a complicated case)

And so on.

This requires some thought.

In some uses, you want to be able to, in configuration, say a setting widget: foo means that you want an auto-loaded, auto-configured app.widgets.foo_widget.Widget instance or whatever, and simply changing "foo" should change the widget module accessed or whatever.

This is useful as a general utility object (a loader that provides the plugin naming scheme and post-import callback invoker), and as a property helper function on the Configuration class.

Purpose

Mandrel should provide runner utilities that allow the execution of arbitrary code/scripts but give an initial pass at bootstrap configuration.

These runners would let us do things like customize the configuration search path, or specify the logging configuration file, as highest-priority command-line options, and would overrule or extend whatever took place in the usual bootstrap file.

Approach

Have two runners:

• mandrel-runner should allow execution of an arbitrary callable specified by fully-qualified name.
• mandrel-script should allow execution of an arbitrary python script, specified by path.

In each case, the first step should be to parse mandrel-specific options to allow:

• full setting of search path
• setting of logging configuration path
• prepend to search path
• append to search path

Each runner would bootstrap, then apply the changes implicit in the options. The name of the thing to run, in both cases, should be the first positional parameter (and is required). All other items on sys.argv can be passed along to the thing that is run in a manner idiomatic to the type of thing being run:

• for the callable, the remaining items should simply be handed as a list to the callable as its first (and only) positional parameter)
• for the script, the script name should be set as sys.argv[0] and the remaining items to sys.argv[1:].