Earlier in the week, I updated my still infant matrix library to the new symbols and facets. I took notes as I made the changes. Here are some comments:

1. The new fanb tool doesn't work yet, right? In any case, I've customized some of the build anyway. I'm just wondering if I saw correctly.
2. In my build script, I still needed to say podName = "math". Is there some way to avoid needing the redundancy?
3. I also still had to specify the version in build.fan. I can't use @build::buildVersion without making my pod dependent on build. Seems like a plain @sys::version facet would make a lot of sense. And for cases where it mattered, maybe allow a separate @sys::implementationVersion (where that differs from the implementation of a common spec), but I wouldn't expect most people to use that.
4. I recommend @sys::depends instead of @sys::podDepends.
5. Also, it would be nice to be able to say simply @depends = ["blah 0.1", "sys 1.0"] instead of @depends = [Depend("blah 0.1"), Depend("sys 1.0")]. But this more of a side comment. That's just sort of a side wish since I understand that dealing with that could be involved. I don't necessarily recommend addressing this.
6. I recommend @build::srcDirs (change of pod and name) or perhaps @compiler::srcDirs instead of @sys::podSrcDirs.

Just occurred to me that @build::srcDirs would raise the unwanted dependency problem again. (But I do recommend moving @version to sys because it also seems very fitting there at the core.)

Goes back to the topic of build-time vs. run-time dependencies. Build-time only facets, too.

I like keeping podSrcDirs in sys, since all pods (possibly except proprietary/obfuscated) need to reflect how they were built.

About @version and @build::buildVersion; isn't build.fan run as a script? --meaning it's external to the actual pod source code; meaning it can use build-pod symbols without making the pod depend on build. (When run as a script, all the system is available; pod dependencies only applies within pods)

I didn't try to test that, but it seems like that's how it ought to work.

About @version and @build::buildVersion; isn't build.fan run as a script?

I mean it would be nice to put a version facet on a pod. We declare dependencies on pods by name and version. I think it makes sense to put the version right with the pod declaration, too.

The new fanb tool doesn't work yet, right? In any case, I've customized some of the build anyway. I'm just wondering if I saw correctly.

no it doesn't

In my build script, I still needed to say podName = "math". Is there some way to avoid needing the redundancy?

when/if I do fanb, then yes it goes away b/c the whole build script goes away - but I left it in there for now because it means we know the pod name even if we can't actually parse pod.fan

I also still had to specify the version in build.fan. I can't use @build::buildVersion without making my pod dependent on build.

In your build script you have an implicit dependency on build already, so I don't understand the issue.

I recommend @sys::depends instead of @sys::podDepends.

I choose to make all pod level facets prefixed with "pod" for both consistency and to avoid taking common names since sys is imported into the namespace by default.

Also, it would be nice to be able to say simply @depends = ["blah 0.1", "sys 1.0"] instead of @depends = [Depend("blah 0.1"), Depend("sys 1.0")].

I agree, but since ideally you want to reflect it as fully parsed Depends I choose the current design. Seems a minor annoyance to pay for strongly typed facets and consistency.

I recommend @build::srcDirs (change of pod and name) or perhaps @compiler::srcDirs instead of @sys::podSrcDirs.

They have to be in the sys pod b/c all pods have to use them (even the sys, compiler, and build pods themslves). And they are prefixed with pod as I noted above for consistency and avoid taking good names by sys.

I mean it would be nice to put a version facet on a pod. We declare dependencies on pods by name and version.

It is a practical problem - dependencies don't really change so putting them into source code (pod.fan) is fine. The version changes on every build and is typically configured externally by build environment - so it doesn't make sense to put it directly into source code.

Thanks much for the replies. I still have concerns in some cases, but I'll just keep things in mind rather than worrying too much at the moment.