Possible to have dataclass-like parameters?

[blakeNaccarato]

If I have a cappa.command-decorated class (e.g. Binarize below), which I intend to be a terminating command with no subcommands, but one of its fields/attributes happens to be dataclass-like, I believe Cappa assumes it to be an incomplete continuation of CLI structure, e.g. an unsatisfied dependency in the CLI structure.

Dataclass-like structures are special in that they are promoted to command/subcommand status, but is there a way to tell Cappa "treat this not as a subcommand/unsatisfied dep, but rather treat it as a dict-like argument but with dotted attribute access"?

In the workaround below, the Deps TypedDict mirrors the _Deps BaseModel, indicating this is a "leaf" node of the CLI, and a plain old dict becomes a parameter to the leaf command Binarize. If I were to place _Deps directly in Binarize instead, the CLI fails to parse/build.

Of course you might suggest unwrapping Deps and placing its args raw and other directly into Binarize, though here I'm implementing a common "pipeline stage" concept with each stage having a certain shape (e.g. all having a Deps argument which is a namespace of paths).

I also see the point of keeping dataclass-like classes single-purpose, so if there's no way to make dataclass-like classes act like arguments instead, I would understand the intent behind a design decision like that, especially if undoing that invariant adds overhead to every single class inference made in CLI parsing.

from __future__ import annotations
from pathlib import Path
from typing import TypedDict

from cappa import command, invoke
from pydantic import BaseModel

class _Deps(BaseModel):
    raw: Path = Path("raw")
    other: Path = Path("other")

class Deps(TypedDict):
    raw: Path
    other: Path

def main(args: Binarize):
    print(args.deps["raw"], args.deps["other"])

@command(invoke=main)
class Binarize(BaseModel):
    deps: Deps = _Deps().model_dump()

invoke(Binarize)

[DanCardin]

So cappa doesn't automatically infer dataclass annotated things are commands/subcommands, beyond the top-level class being parsed against, i.e. Binarize in this case. You need to annotate Subcommands[Deps] if you wanted it to be a subcommand.

But i think there are a couple of problems going on here.

1. Cappa is currently mapping against the default value also. e.g. this works:

   from __future__ import annotations
   
   from dataclasses import dataclass
   from typing import Annotated
   
   from cappa import Arg, command, invoke
   from pydantic import BaseModel
   
   
   @dataclass
   class Deps:
       raw: str
   
   
   def main(args: Binarize):
       print(args.deps.raw)
   
   
   @command(invoke=main)
   class Binarize(BaseModel):
       deps: Annotated[Deps, Arg(default="foo")]
   
   
   invoke(Binarize)

   `binarize.py` yields `foo`

   Whereas with `deps: Deps = Deps("foo")` (which is what you'd want to write, to be type-correct) it yields `Deps(raw='foo')`

   It's probably the case that we shouldn't be performing the type coersion when the default value is selected...? If you agree, that's definitely something I can almost certainly address quickly.

2. Pydantic doesn't allow positional arguments

    The same example above, with pydantic will fail because we perform `Deps(<the-parsed-cli-input>)`, and this will fail pydantic's constructor. I dont see an obvious way around **this**, other than you providing a dedicated `parse` (or by using dataclasses/pydantic.dataclasses, which **does** allow positional arguments) e.g.

   ```python
   class Deps(BaseModel):
       raw: str
       @classmethod
       def new(cls, raw: str):
           return cls(raw)

   ...

   deps: Annotated[Deps, Arg(action=Deps.new)]

...although having said that, i suppose there's a world where we add a default inference for `BaseModel`s, but it sort of leads into my next point

3. It's not clear to me what you expect the CLI shape/behavior to be.

   Both of my above examples simplify your example to a class with one input, which corresponds to that one input on the CLI.

   What are you anticipating the user would input on the CLI and how that would translate into a constructed Deps instance?

   For example, one option i could imagine, is introspect the annotated classes' input fields (lets say 2 arguments raw and other), and from that inferring that that means num_args=2, so that the CLI parser for binarize.py 1 2 gets ("1", "2"). and then the mapping stage uses the same inference to splat the arguments over the input space Deps(1, 2) (or Deps(raw=1, other=2) for BaseModel)

   I'm not sure if that's what you're expecting, but i feel like there might be other obvious interpretations and that any automatic choice might be confusing.

I think, depending on your answer to number 3, it should be possible to arrive at the expected CLI shape and behavior, just by explicitly supplying some combination of num_args and parse. but there may or may not be a sensible automatically inferable option.

[blakeNaccarato]

Okay after reading your (very thorough, thanks!) explanation I see what you mean. I've written an example below that operates on an assumption that all bottom-level/leaf commands have arguments Params, Deps, and Outs. I've written an ice-cream maker example where Deps are file paths to household appliances (a stretch, I know), Outs are file paths where the ice cream will be placed, and Params affect ice cream color and flavor. In the proper implementation I'm using this pipeline layout to define different data processes for image processing.

In the example below, I've passed a quick-and-dirty custom backend to cappa.parse in order to get the behavior I'm looking for, but in a brittle way.

• I'm trying to get very similar behavior to "Pydantic settings" CLI parsing which can parse list/set/dict values provided as CLI arguments as JSON-encoded strings. A few things I had to do to get Cappa to play along...
• My custom backend first runs the default cappa.parser.backend and gets parser, parsed_command, and parsed_args, then further massages those.
• I see how if the parser gets a BaseModel/dataclass instance, it feeds the instance back to the class constructor. So my custom backend does arg.parse = arg.parse.model_validate (blindly, so they all have to be BaseModels), so that later during map_result, value = arg.parse(value) doesn't explode.
• The parser grabs the default (cappa.arg.Arg.default) for every argument (it will fail if there is no default)
• It merges these defaults with vanilla parsed_args from the standard backend to control behavior downstream (this only works if every argument is in long=True form)
• Now value = arg.parse(value) becomes basically value = my_model_instance.model_validate(value_dict) and doesn't fail
• Finally return command.cmd_cls(**kwargs) at bottom of Command.map_result succeeds

The example in the collapsed "details" fold below exercises Cappa in a few different ways, and also shows how Pydantic settings' CLI works with the same argv. Now that I've got the behavior correct in a quick-and-dirty way, I think the following things are notable:

• The backend parameter of cappa.base.invoke is the escape hatch I needed! However, this escape hatch can't be special-cased for certain parts of the CLI, e.g. the Stage sub-branch of my CLI which has this Params/Deps/Outs "shape" and behavior. Maybe a given CLI model class could have an optional backend on its @command decorator that is dispatched for processing that node downward, for instance.
• Is it safe for the user's custom backend to modify arg.parse on cappa.arg.Arg instances?

I will probably expose this "special" part of my CLI with a bunch of uniform "pipeline stages" from a different entry point so that this wonky custom backend doesn't have to handle too much. Imagine a CLI of depth 2 with the root command having each subcommand be a "stage" (and no deeper).

Details

"""Pipeline stage for making ice cream."""

from __future__ import annotations

import sys
from contextlib import suppress
from json import loads
from pathlib import Path
from typing import Annotated, Any, TypeVar

from cappa.arg import Arg
from cappa.base import command, invoke, parse
from cappa.command import Command
from cappa.output import Output
from cappa.parser import backend
from pydantic import BaseModel
from pydantic_settings import BaseSettings


def main(stage: MakeIceCream | PydanticSettingsMakeIceCream):  # noqa: D103
    print(  # noqa: T201
        f"Here's your {stage.params.color.upper()} ice cream in a {stage.outs.waffle_cone.stem.upper()} waffle cone!\n"
    )


class Params(BaseModel):  # noqa: D101
    color: str = "yellow"
    flavor: str = "vanilla"


class Deps(BaseModel):  # noqa: D101
    freezer: Path = Path("freezer")
    stand_mixer: Path = Path("stand_mixer")


class Outs(BaseModel):  # noqa: D101
    waffle_cone: Path = Path("waffle_cone")
    bowl: Path = Path("bowl")


class MakeIceCream(BaseSettings):
    """Make ice cream."""

    params: Annotated[Params, Arg(long=True)] = Params()
    deps: Annotated[Deps, Arg(long=True)] = Deps()
    outs: Annotated[Outs, Arg(long=True)] = Outs()


class PydanticSettingsMakeIceCream(MakeIceCream, cli_parse_args=True): ...  # noqa: D101


T = TypeVar("T")


def defaults_backend(
    command: Command[T],
    argv: list[str],
    output: Output,
    prog: str,
    provide_completions: bool = False,
) -> tuple[Any, Command[T], dict[str, Any]]:
    """Backend that injects defaults and makes `model_validate` the parse callable."""
    parser, parsed_command, parsed_args = backend(
        command=command,
        argv=argv,
        output=output,
        prog=prog,
        provide_completions=provide_completions,
    )
    extra_args = ["help", "completion"]
    defaults: dict[str, dict[str, Any]] = {}
    for arg in parsed_command.arguments:
        if arg.value_name in extra_args:  # pyright: ignore[reportAttributeAccessIssue]
            continue
        arg.parse = arg.parse.model_validate  # pyright: ignore[reportAttributeAccessIssue, reportFunctionMemberAccess, reportOptionalMemberAccess]
        defaults[arg.value_name] = arg.default.model_dump_json()  # pyright: ignore[reportAttributeAccessIssue, reportOptionalMemberAccess]
    return (
        parser,
        parsed_command,
        {k: loads(v) for k, v in {**defaults, **parsed_args}.items()},  # pyright: ignore[reportArgumentType]
    )


def main2(stage: InvokeMakeIceCream):  # noqa: D103
    print(  # noqa: T201
        f"Here's your {stage.params.color.upper()} ice cream in a {stage.outs.waffle_cone.stem.upper()} waffle cone!\n"
    )


@command(invoke=main2)
class InvokeMakeIceCream(BaseModel):  # noqa: D101
    params: Annotated[Params, Arg(long=True)] = Params()
    deps: Annotated[Deps, Arg(long=True)] = Deps()
    outs: Annotated[Outs, Arg(long=True)] = Outs()


if __name__ == "__main__":
    if len(sys.argv) != 1:
        invoke(InvokeMakeIceCream, backend=defaults_backend)
        sys.exit()
    with suppress(SystemExit):
        print("\nCAPPA HELP:")  # noqa: T201
        main(parse(MakeIceCream, backend=defaults_backend, argv=["--help"]))
    with suppress(SystemExit):
        print("\nCAPPA NO ARGS:")  # noqa: T201
        invoke(InvokeMakeIceCream, backend=defaults_backend)
    sys.argv = [
        "make_ice_cream.py",
        "--params",
        '{"color": "blue"}',
        "--outs",
        '{"waffle_cone": "chocolate_dipped"}',
    ]
    with suppress(SystemExit):
        print("\nCAPPA WITH CUSTOM BACKEND:")  # noqa: T201
        main(parse(MakeIceCream, backend=defaults_backend))
    with suppress(SystemExit):
        print("PYDANTIC SETTINGS:")  # noqa: T201
        main(PydanticSettingsMakeIceCream())

[DanCardin]

I'm not entirely sure whether i'm fully grasping the complexities in this example or not. But if it's just a matter of making singular CLI inputs parse into arbitrary shapes, then you ought to be able to use Arg.parse to specify the custom mechanism required to turn that string input into the object you want.

I've simplified your example into what seems like the minimal request here.

from __future__ import annotations

from collections.abc import Callable
from json import loads
from typing import Annotated, TypeVar

from cappa.arg import Arg
from cappa.base import command, invoke
from pydantic import BaseModel

T = TypeVar("T", bound=BaseModel)


def main(stage: MakeIceCream):
    print(
        f"Here's your {stage.params.color.upper()} {stage.params.flavor.upper()} ice cream!\n"
    )


class Params(BaseModel):
    color: str = "yellow"
    flavor: str = "vanilla"


def from_json_str(model: type[T]) -> Callable[[str], T]:
    def map(json_str: str):
        value = loads(json_str)
        return model.model_validate(value)

    return map


@command(invoke=main)
class MakeIceCream(BaseModel):
    params: Annotated[Params, Arg(long=True, parse=from_json_str(Params))] = Params().model_dump_json()


if __name__ == "__main__":
    invoke(MakeIceCream)

i.e. turn the string into a dict structure, and then model_validate it. Or if pydantic had a mechanism for parsing directly from a string, then that instead of from_json_str. This also seems to take care of defaults by way of leaving it to pydantic

It seemed like the other params, and the use of BaseSettings was mostly irrelevant to this purpose, which is why i omitted them. If that's not the case, lmk.

Also, if it matters, BaseSettings also works as a source class.

---

Also note, Cappa ships with a mechanism for loading default values from env vars: https://cappa.readthedocs.io/en/latest/arg.html#environment-variable-fallback, if that would be meaningful to you. Also I happened to write https://github.com/DanCardin/dataclass-settings/ which (imo) fixes a bunch of problematic things in pydantic-settings, which i just know definitely works with cappa.

---

Also like i said in my o.g. response, i think the fact that we're having to work around the default being required to be a string, when the annotation says otherwise is definitely what i'd consider a bug.

[blakeNaccarato]

I used backend after seeing it in the documentation, not realizing it was a hacksaw to the scalpel of Arg(parse=...). Obviously "rtfm" may apply to me here 😅. A few thoughts in conclusion here:

• It might help to redirect wayward travelers to the "Parser Backends" page with a "you may be looking for Arg(parse=...)" note.
• I see Arg(parse=...) makes guest appearances in Apps/Annotations "Concepts" pages and API docs. I see the difficulty in separating concepts here, since "parsing" is an overloaded term that means overall behavior as well as detailed, field-specific Arg(parse=...) behavior.
• Maybe a good "Parsing" Concept article would acknowledge this tension, written in such a way as to discuss the defaults, then escalate from minimally-invasive parsing customization to full-blown backend overrides. This might take care of some of the responsibilities of the "Args" and "Annotations" pages, allowing them to become more focused as well.
• Someday I swear I'll graduate and actually get some more time to contribute documentation and upstream changes to the packages I love, and that someday is when I'd be open to helping with this!

I also appreciate that you have in your back pocket an entire "pydantic-settings but they did it wrong" package ready to go. I recently got intimately familiar with pydantic-settings in implementing custom settings_customize_sources for certain behavior, so I understand the pain there. Though pydantic-settings is definitely helpful when you want custom class initialization behavior without hijacking __init__. Will be interesting to see if Pydantic plugins, once stabilized, provide a cleaner alternative to that.

Anyways, here's my final example for making ice cream in the theme of a pipeline stage (an odd example, I know). Thanks again for your help here!

"""Pipeline stage for making ice cream."""

from __future__ import annotations

from collections.abc import Callable
from json import loads
from pathlib import Path
from sys import argv
from typing import Annotated, TypeVar

from cappa.arg import Arg
from cappa.base import command, invoke
from pydantic import BaseModel


def main(stage: MakeIceCream):
    print(
        f"Here's your {stage.params.color.upper()} ice cream in a {stage.outs.waffle_cone.stem.upper()} waffle cone!\n"
    )


class Params(BaseModel):
    color: str = "default_yellow"
    flavor: str = "default_vanilla"


class Deps(BaseModel):
    freezer: Path = Path("default_freezer")
    stand_mixer: Path = Path("default_stand_mixer")


class Outs(BaseModel):
    waffle_cone: Path = Path("default_cone")
    bowl: Path = Path("default_bowl")


T = TypeVar("T", bound=BaseModel)


def get_parser(model: type[T]) -> Callable[[str], T]:
    """Get parser for model or JSON-encoded string."""

    def parse(v: T | str) -> T:
        """Parse model or JSON-encoded string."""
        return model(**loads(v)) if isinstance(v, str) else v

    return parse


@command(invoke=main, default_long=True)
class MakeIceCream(BaseModel):
    """Make ice cream."""

    params: Annotated[Params, Arg(parse=get_parser(Params))] = Params()
    deps: Annotated[Deps, Arg(parse=get_parser(Deps))] = Deps()
    outs: Annotated[Outs, Arg(parse=get_parser(Outs))] = Outs()


if __name__ == "__main__":
    if len(argv) > 1:
        invoke(MakeIceCream)
    else:
        invoke(
            MakeIceCream,
            argv=[
                "--outs",
                '{"waffle_cone": "chocolate_dipped"}',
                "--params",
                '{"color": "blue"}',
            ],
        )

[DanCardin]

I also appreciate that you have in your back pocket an entire "pydantic-settings but they did it wrong" package ready to go. I recently got intimately familiar with pydantic-settings in implementing custom settings_customize_sources for certain behavior, so I understand the pain there. Though pydantic-settings is definitely helpful when you want custom class initialization behavior without hijacking init. Will be interesting to see if Pydantic plugins, once stabilized, provide a cleaner alternative to that.

heh. I really wanted it to work after developing cappa, but it kept being problematic trying to integrate it into clis and having no idea how to backtrack to which specific env vars were failing to load.

There are inherent limitations to how they designed it that imo leave the whole thing in a weird place. And it seemed really pompous of me to go to their issue tracker and say: "hey, i like the library...but it should really be designed this way". so alas a new library need be born instead 🤷. And for my own purposes, the extra parsing logic they do is not what I'm looking for. I dont need to harp on it here, though, I lay it all out in the readme 😬.

With that said, I think the CLI parsing stuff you're talking about didn't exist the last time I looked.

[blakeNaccarato]

And to avoid burying the lede in that other reply, I'll quote the other actionable bit here that you have mentioned...

binarize.py yields foo. Whereas with deps: Deps = Deps("foo") (which is what you'd want to write, to be type-correct) it yields Deps(raw='foo'). It's probably the case that we shouldn't be performing the type coersion when the default value is selected...? If you agree, that's definitely something I can almost certainly address quickly.

And...

...although having said that, i suppose there's a world where we add a default inference for BaseModels, but it sort of leads into my next point
For example, one option i could imagine, is introspect the annotated classes' input fields (lets say 2 arguments raw and other), and from that inferring that that means num_args=2, so that the CLI parser for binarize.py 1 2 gets ("1", "2"). and then the mapping stage uses the same inference to splat the arguments over the input space Deps(1, 2) (or Deps(raw=1, other=2) for BaseModel)

Which could make sense. The pydantic_settings CLI parsing sees a BaseModel like Deps and allows dotted unpacking like --deps.raw something --deps.other 'something else', but maybe that's too opinionated. Or allowing another expansion point in backend that's a bit less of a hacksaw, and by default it does the --deps.raw something --deps.other 'something else' thing, but can be customized (per-field? idk). It gets messy as you add more places for users to hijack the arg consumption logic.

And...

Also like i said in my o.g. response, i think the fact that we're having to work around the default being required to be a string, when the annotation says otherwise is definitely what i'd consider a bug.

Which I now think I understand after digging through the internals, which is that the structure of cappa.command.Command.map_result uses the result of cappa.parser.backend first, which has its own cappa.parser.parse to consume the context, ultimately relying on cappa.parser.consume_arg, which is where my comprehension falls apart a bit.

But the crux is that in cappa.command.Command.map_result, by the time we get to the # apply Arg(parse=...) or else default parsing comment, it's already too late to have handled the string CLI input differently, right? And so it's good we have Arg(parse=...), but you're suggesting that some rethinking of arg consumption prior to that is possible? Here's the trimmed down cappa.command.Command.map_result I'm referencing:

def map_result(self, command: Command[T], prog: str, parsed_args) -> T:
    kwargs = {}
    for arg in self.value_arguments():
        is_subcommand = isinstance(arg, Subcommand)  # Side note: this var could be used below...
        if arg.field_name not in parsed_args:
            # handle default
        else:
            # get arg as parsed by the backend
        if ...:
            # handle other special stuff
        if isinstance(arg, Subcommand):  # Side note: This could be `is_subcommand` I think?
            # handle subcommand
        else:
            # apply `Arg(parse=...)` or else default parsing
        kwargs[arg.field_name] = value
    return command.cmd_cls(**kwargs)

[DanCardin]

...and the last thing i need to test out is my DestructuredArg idea. that...should essentially boil down to the same output shape as a parse=json.loads (i.e. a dict), but with disparate args; but would then need equivalent handling visa-vi these previous comments ^

[blakeNaccarato]

The docs changes address confusion about parsing very nicely, I like the mention of parse_ commands and cross-linking between confusable concepts.

I think it definitely makes sense to solve dataclass inference by just waiting a year for 3.8 to fully drop off and type-lens to progress. Like it's not an outright blocker since the "wrap the backend" escape hatch is there and not too painful. I agree that baking in ugly inference today is less attractive if type-lens facilitates that nicely in the future. I've manually parsed my share of BaseModel annotations and it gets ugly pretty quickly with all the get_args, get_origin, is_subclass boilerplate.

I think deferring to BaseModel.model_validate could work, though if built-in dataclass-like inference is easier to implement in a year or so, that would be less brittle and not Pydantic-specific. So it's less churn to just not touch it now.

Implementing the idea of destructured args sounds promising, that seems the right-shaped idea for handling sub-Arg specifics. The caveat being that the atomicity of an Arg is a nice conceptual "floor" to the already very complex logic of commands.

With Args being structurally similar to subcommands already (they're kind of like always-leaf combinatorial subcommands in a way), maybe there's an implementation that reuses some of that machinery and minimizes the impedance mismatch when moving from Subcommand land to Arg land. But I have less exposure to the concepts so maybe the confusion lies with my inexperience.

Thanks for the thorough consideration of these ideas!

[DanCardin]

I think it definitely makes sense...

fwiw, i think type-lens is an option soon, i'm just trying to merge interfaces they're currently lacking. they backported it to 3.8 recently (although unreleased).

it's mainly that i found myself needing to expose the annotation shape as a user accessible feature, which i dont want to be the current raw type shape. (currently you can only make inferences off the input value, but cappa knows the annotated type also, so making the decision to infer dataclass-likes a user's parse= choice then becomes a problem, unless they're forced to duplicate the annotation into the parse call like Annotated[Foo, Arg(parse=as_dataclass(Foo))], which is sad).

---

I think deferring to BaseModel.model_validate...

The nice thing about model_validate is that is just accepts a single-argument blob, which means a dict (json.loads) works fine (but also apparently you can pydantic.TypeAdapter(Foo).validate_json fwiw), whereas the constructor requires **splating a dict.

---

Implementing the idea of destructured args sounds promising,...

As far as destructured args go, one can already do foo: Annotated[dict, Arg(long='--foo', action=something_fancy), Arg(long='--bar', action=something_fancy)] to produce 2 cli-level arguments that target the same field_name. in this case something_fancy would presumably write them to dedicated dict keys.

the fancy bit would "just" be translating a dataclass-like into the appropriate series of Args.

---

With Args being structurally similar to subcommands already...

I'm not sure i follow what you mean here. unless you mean like... foo.py bar, where bar could either be a subcommand or a positional argument? if so, the difference is that subcommands move you into a completely different parser context, whereas args do not (and thus you can --foo=bar bar --baz=baz intermingle "options" around the arg). so i'm not sure what to make of this comment either way :P

---

Thanks for the thorough consideration of these ideas!

Thank you! Other than discovering bugs or inference extensions, these sort of ideas are the main way the capabilities get improved!

[pawamoy]

cappabilities 😀

[blakeNaccarato]

Regarding my conflating subcommand and destructured arg shapes, chalk it up to my flawed mental model. Okay I'll stop trading essays, you're free to close the discussion thread, if/when that's part of your workflow!

Thanks @pawamoy for the Cappa mention on Mastodon! It turned out to be the missing piece for representing my pipeline stages suitably as commands in a pipeline orchestrator's dvc.yaml (combined with a little YAML dumping). It sure beats the alternative, manually syncing dvc.yaml with hardcoded params/deps/outs. With Cappa you also get a human-usable CLI out of it, to boot!

[DanCardin]

#150: Merged
#141: still cooking but promising. Although it makes the whole parsing apparatus decently more complicated. i'd want to make sure it doesn't have negative downstream effects.

[blakeNaccarato]

The argument destructuring concept looks great! In the interim I flattened a bunch of format-related args from a Format class into the parent Params class used as a cappa.Subcommand. Now I can afford to isolate those format-specific things back into their own Format class and use arg destructuring to assemble them.

Handling arg destructuring as a simple extension of parent args during command collection is a great way to handle this. Seems a cleaner approach, rather than expecting the destructured arg name be pre-pended e.g. --sub-object-arg-1 foo in the way of pydantic-settings's CLI feature mentioned earlier.

In the docs example, if Args later grows an arg1 field itself, will that be detected as a collision with SubObject's arg1 field? Or will one silently take precedence?

[DanCardin]

oo good question. So if they're both options, then it'll fail in the parser with f"Conflicting option string: {key}".

but if they otherwise dont conflict at the CLI-shape level (e.g. 2 positionals, or one positional and one option), then it should "just work" because they're recorded to different underlying field_names (sub1 vs field.sub1).

With that said, i'm glad you thought of that because there's currently a bug where it will record the value for both fields, easily remedied (#151)

[blakeNaccarato]

Ah, glad I could help! Well it's a great feature and I will be making use of it sometime in the near future.