Support kw=Collection(task) in addition to Collection('kw', task) #528
ns = Collection( env=Collection(some_task1, some_task2), )
But now it fails (on py3.5 at least) to:
Now we have to give the namespace as str parameter to
ns = Collection( Collection('env', some_task1, some_task2), )
Was this change intended or accidental? I liked to old way more (rather kwarg than positional string arg).
The text was updated successfully, but these errors were encountered:
Suspect this is missed in our test suite because the fixtures I use for testing
I can confirm we have a test about the actual kwarg-key-is-the-name behavior and it's passing, so this is either limited to
Think this is due to an annoying modeling discrepancy: the fact that a task or collection can be added to a Collection multiple times, and thus there are two ways to "name" these objects - the dictionary key they are attached as at a given point, and/or their own internal/intrinsic name.
Most of the time, namespace-crawling functionality is concerned only with the former: something is requesting lookup of eg
This is why, for example, in @tuukkamustonen's case, actually invoking
However, the new list functionality at one point looks at the latter name - the object's intrinsic name - and in the case under examination, it's None (because, as Tuukka stumbled upon, that's driven entirely by whether the inner
The naive fix is to modify the object when it's being given as a kwarg value - but this is misleading because as noted above, that's a big no-no (mutating an object you were given by your caller) in general. And in specifics, it would be problematic for us if the object were to be attached elsewhere in the tree later (the name would just get overwritten a second time).
So I'm 99% sure the right fix is to not reference
Have that mostly solved but there is another minor add-on problem (I think more an issue with my test than reality), the now-not-a-module subcollection I tweaked lost its docstring, because...I'm handing in the raw collection and not the module.
Technically I should fix this by updating my test output assertions to not expect help text for that particular subcollection, but it makes me realize that there is no way to specify the help for a collection this way - the help functionality has been written assuming one is using module trees.
I'll probably hack it up now to save myself some work, but it means there needs to be a spinoff feature ticket.