Submodules are brittle

Bug #347715 reported by Paul Jimenez on 2009-03-24
Affects Status Importance Assigned to Milestone

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" "http://whatever"
...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)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers