Complications with [cient]_urbansim and urbansim_defaults

[fscottfoti]

I think we should start a discussion - though this isn't necessarily a bug or an urgent problem - about the relationship of client implementations and urbansim_defaults. I mean, right now everything is working as designed but I wonder if we can / should improve the design.

To summarize the problem, we have models/variables/tables defined in Python code in urbansim_defaults and then other models/variables/tables defined in bayarea_urbansim. This is so we can share the default definitions across clients, which makes code more heavily tested and high-level features get updated once for all clients.

The biggest problem is that you can lose track of what is defined where and have to click between the two repos to find the place something is defined. In my experience working with UrbanSim users, this is one of the biggest UrbanSim-related headaches people encounter.

And it's especially a problem when using something like autoimport in the Notebook because when you're trying to override the default with something of the same name and then edit the file from urbansim_defaults, you can actually redefine the default.

Anyway, we've discussed some solutions to this - like whether we should process the defaults into the same file or something, but maybe we can come up with better ideas.

Second, it might be nice to have a command on the sim framework that prints out what is currently defined for a table/variable/model like the website has - I guess it prints out the source code. I can imagine this might work with the ipython interact stuff too.

[tbuckl]

Is there a present example of a differently defined model/table/variable in urbansim_defaults and bayarea_urbansim?

[fscottfoti]

So you mean like an override from urbansim_defaults to bayarea_urbansim? Umm, not for the Bay Area since it's typically our source of models for the defaults. It does happen in other client implementations though. Really it's just something with the same name, so you can pretty easily try out an override by creating an empty model/table/variable with the same name.

[tbuckl]

Yeah. OK, sounds good.