Remove special treatment for commas and colons in logdir specifiers

Generally, the argument to --logdir is interpreted simply as a path. But two characters have special meanings: commas allow specifying multiple directories, and colons allow specifying custom names for runs. Together, then:

tensorboard --logdir model1:/my/logs/model1,model2:/my/logs/model2

This is problematic when people try to specify a log directory that actually contains commas or colons in its name, which is fairly common for specifying hyper parameters: e.g., ./logs/lr_1E-03,conv=2,fc=2. It also complicates the parsing logic on Windows: --logdir C:\logs needs to be a bare name, not a run named C (while --logdir foo:C:\logs does need to be named).

It’s fairly common to get issues from users who can’t understand why TensorBoard isn’t loading the data that they’re telling it to (e.g., #1220), so this is a real usability issue.

Furthermore, the behavior is mostly superfluous. TensorBoard already loads runs recursively under the logdir, so it often suffices to just point TensorBoard at a common ancestor directory (/my/logs in the above example). When one wishes to include some runs from a very large parent directory but not all, one can simply create a symlink tree, which can be packaged up into a convenient shell function.

The only genuine value-add that this provides, near as I can tell, is when one wishes to load a proper subset of runs in a directory on a remote filesystem that cannot also be locally mounted, because in that case a symlink tree will not suffice.

It would be great to remove this in TF 2.0.

[wchargin]

Especially when the alias contains lines such as rm "${logdir}"/*, which looks scary!

Fair—renamed logdir to tmpdir to more clearly convey that nothing under the user-provided logdirs is actually being removed. But I get that this doesn’t really resolve your broader point.

For some context: the reason for the restriction is that our argument parsing needs to be compatible with Google’s internal Abseil flag parsing (can give you more details offline if you like). But the way that Google does flags is not really compatible with the way that everyone else does them: some differences are superficial, like the delimiters being --snake_case instead of --kebab-case; others have subtle effects, like the prevalence of --logdir=~/data/-style invocations forcing us to perform tilde expansion on arguments, contrary to wide Unix-y convention; and still others have structural limitations, like the fact that Abseil flags don’t take positional arguments at all and don’t support --logdir one two three-style invocations. Typical Google programs take multi-valued arguments as a single comma-separated value, but of course that isn’t compatible with glob expansion.

I can tell you that this is super frustrating for me, too.

A while ago, we migrated from pure Abseil flags to a hybrid solution that supports both argparse and Abseil (#1409). We can take a look and see if it’s as simple as setting nargs="*" on the --logdir argument. If so, we might be able to make that change, but note—I suspect that you realize this, so mostly for others’ benefit—that the glob would only be expanded at command invocation time, and not dynamically at runtime as you create new directories or delete old ones.

(For what it’s worth, the --logdir_spec breaking change isn’t really related to whether we accept multiple arguments to --logdir.)

[nfelt]

FWIW, I don’t think there is a similar concern for a non-optional nargs argument (same as cp). Especially now that we have a subcommand structure, maybe the win-win here is to remove the need to specify --logdir at all so that it’s just tensorboard serve experiment{1,2,3} or tensorboard dev upload experiment{1,2,3}.

We’d need to do some advance planning to ensure that this generalizes sufficiently well to cases where the thing passed in is not a logdir (e.g. for future use cases where it might be a reference to a database entry or a hosted experiment or something), maybe via a URI scheme like what we support today for GCS logdirs.