erikfanderson / toolbox Goto Github PK

Right now tools can be added that have same class name. Onbiously this will mess things up. Need to at least check that all tools being used do not have conflicting class names. Also might make sense to specify the tool by an alias rather than a class name in the job field so users do not need to go look up the class name. They can simply define the alias when they define their list of tools.

Also add a way to create individual packages for invocations of specific tools

Need to add CI at some point... Also will want to reassess status of current tests and see if any new ones need to be added

tool namespaces should be configurable. Should use a "namespace" field in the tool.yml.
This can also change the global namespace use "internal.tools.{namespace}" for internal info and simply "{namespace}" for the tool namespace. This wiill change things like "tools.vlsi" to "vlsi"

Right now you can only set the description and default for the top level. Would be nice to specify defaults at each level of the namespace...

Thing like toolbox-cli <job_name> var.something="something" and then process last part as yaml string and add it the configs

Right now if the additional_config overrides a value that is used as a variable BEFORE the additional_config is loaded then the wrong value will be resolved... Need to wait to perform resolution of config files until right before we run a job!

Allow for absolute paths (i.e. not relative to jinja dirs) so that tool schemas can use "file()" schema attributes for these files

This is import if you ever read in scripts that reference environment variables (e.g. cds.lib)

Read title... should be easy fix

tools.yml is unnecessary! Simply make this a simple config file and then allow toolbox to automatically load any toolbox.yml in the cwd

If there is a namespace "thing" and "thing.prop" is given but "prop" is not defined in the "thing" tool.yml then toolbox should issue a warning to alert the user so they know that the value is not being checked. This can be a problem if the tool.yml has a default value but the user is actually trying to override it

Right now only the messages that are generated using the log functions are put into the log file

Allow for some fields to be checked only when another field is true. Will enable things like versioning for Cadence tools.

e.g. if "genus_version == 191" then require a bunch of additional fields within the namespace to be required, otherwise don't require those fields

This allows the user to quickly change the namespace name and not have to also edit the init.py file

So the issue is that the warning is actually logged 2 times for some reason. Also worth considering whether this should be logged as a warning at all.

self.tool should return a dictionary with all of the tool properties that pertain to that tool.
The namespace should be separated by the schema/tool name. This will replace the current tool = self.get_db(...) and subsequent tool.update(self.get_db(...))

Forces users to only put custom vars in "user" namespace! Will avoid confusion in the future as more and more. Also means that "user" must be an invalid namespace for a tool. This is taken care of if "user" is added to the database in the init function of the toolbox class

Currently schema includes are global across all included config files. This needs to change

Should log something like "loading configuration file ..." then it can issue warnings related to the config files and then finally say "loaded configuration file "

read title

Develop some sort of API such that we can take python files as configs instead of yaml. We should probably limit the dictionary input to be non dot dict? We just want to be able to specify config fields directly in python.

Will require calling mro() in the JinjaTool.init func

So you can control what fields the additional config files are allowed to overwrite

Just need to make sure that these schemas do not collide with the existing tool schemas