Submodules are brittle
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Vellum |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Using the code in the repo as an example, it's plain to see that the current implementation of submodules is brittle.
In the repo, build.vel imports scripts/dist.vel. scripts/dist.vel has a bunch of references to dist.* ; this is wrong - they should be local references to the local namespace - if dist.vel was imported as some other name, they'd be wrong.
Ronny and I chatted on IRC about it and came up with:
22:04 < ronny> module.options -> options.module, module.targets -> targets.module
22:05 < ronny> ie if you import something as mymodule
22:05 < ronny> you will get a mymodule element in options and a mymodule element in targets
22:05 < ronny> oh, and in depends of course
So 'import' becomes a way to reserve a name in all three sections for a sub-namespace.
Note that this sub-namespace is writable from the importer. So while the existing dist says:
# requires that you have options: setup, project, website, vesion, and sudo
instead you would import dist and then in your options do
dist.setup "your setup value"
dist.project "your project value"
dist.website "http://
...and etc.
This keeps the submodule self-contained; someone using it doesn't have to tweak it or change it - I can see eventually shipping a set of standard recipes so that a build.vel becomes an import and some options and not much else!
One tricky bit will be flattening the options with all the overrides correct; this will have to be done so they can be put into the py locals() and the sh environ.
Other random thoughts:
* invoking target 'submodule' should invoke the submodule's default target.
* the sub-namespaces need to be *copies*, because I might import the same module multiple times each as a different name, and then set their options all different. Consider some project that uses distutils on multiple parts - you want to use the dist module on each part, but with different options. Copy-on-write eventually maybe, but RAM is cheap so go for reliable first.
* This all falls out of the Zen of Python: "Namespaces are one honking great idea -- let's do more of those!"
Changed in vellum: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → ronny (ronny-pfannschmidt) |