Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auto_dash_names setting is ignored #465

lukeorland opened this issue Aug 2, 2017 · 7 comments

auto_dash_names setting is ignored #465

lukeorland opened this issue Aug 2, 2017 · 7 comments


Copy link

lukeorland commented Aug 2, 2017

Using invoke version 0.20.1.

./invoke.yaml and ~/.invoke.yaml:

    auto_dash_names: false


from invoke import task

def my_awesome_task(c):

Per the documenation, I would expect this to work, but it does not:

$ inv my_awesome_task
No idea what 'my_awesome_task' is!

Using dashes in the name does work, though:

$ inv my-awesome-task
Copy link

Strange, I know I tested that before I published, clearly something's gone sideways. Will look into it ASAP. Thanks for the report!

@bitprophet bitprophet added the Bug label Aug 2, 2017
Copy link

Yup, my goof. Had all the plumbing set up, and tested, but never tested or implemented that critical bridge between the CLI machinery and the task collection, so "config says no auto dashes -> tell collection not to emit auto-dashed names" never occurs. Fixing now.

Copy link

rpkilby commented Aug 2, 2017

Related, this has caused issues with the fabric's test suite since the task names are now dasherized. As a temp fix, I tried adding auto_dash_names=False to its task collection.

ns = Collection(
    docs, www, test, coverage, integration, sites, watch_docs,
    watch_tests, count_errors, release, travis,
    # TODO: update tests and travis.yml to use dasherized names

Running inv --list raised the following exception:

Traceback (most recent call last):
  File ".venv/bin/inv", line 11, in <module>
    load_entry_point('invoke==0.20.1', 'console_scripts', 'inv')()
  File ".venv/lib/python3.6/site-packages/invoke/", line 287, in run
  File ".venv/lib/python3.6/site-packages/invoke/", line 357, in _parse
  File ".venv/lib/python3.6/site-packages/invoke/", line 522, in parse_tasks
  File ".venv/lib/python3.6/site-packages/invoke/", line 337, in to_contexts
    task = self[primary]
  File ".venv/lib/python3.6/site-packages/invoke/", line 285, in __getitem__
    return self.task_with_config(name)[0]
  File ".venv/lib/python3.6/site-packages/invoke/", line 322, in task_with_config
    return self.tasks[name], ours
  File ".venv/lib/python3.6/site-packages/invoke/vendor/lexicon/", line 80, in __getitem__
    return self._handle(key, None, single, multi, unaliased)
  File ".venv/lib/python3.6/site-packages/invoke/vendor/lexicon/", line 62, in _handle
    return unaliased(self, key, value)
  File ".venv/lib/python3.6/site-packages/invoke/vendor/lexicon/", line 74, in unaliased
    def unaliased(d, key, value): return super(AliasDict, d).__getitem__(key)
KeyError: 'watch-docs'

Copy link

Hooking that stuff up exposes another hidden issue, hooray! (Note to self...)

  • The Collection created by Loader gets the flag OK now
  • However, explicit collection modules (ones which define a ns = Collection(...)) are problematic - because they are created in a vacuum and don't have access to the config, they still get the default auto-dash behavior, even if Collection.from_module ends up "cloning" them into a new Collection that is honoring the config.
  • Thus, the "inner" collection's data structures all still exhibit dashed names, even if the "outer" one has dashes disabled; and thus the copied structures also have dashed keys.
  • This causes a symptom where trying to call Collection.to_contexts() (for parsing) dies:
    • it's iterating over .task_names (which honors task name transformation, and thus underscores any dashes) and then looking up the resulting names within itself.
    • but because its __getitem__ doesn't do transformation, and holds the dashed versions of names emitted from the "inner" config, this turns into an attempt to look up, say, foo_bar (honoring config) in a dict/lexicon whose keys only contain foo-bar (default behavior)
  • In non-cloning behavior, this isn't an issue because name transformation is applied in add_task and add_collection, so "normally" there's no way to end up with this mismatch.
  • Thus the right solution seems like it should be to apply transforms during cloning, even though that may be a PITA (right now cloning gets away with a simple deepcopy.)

Copy link

@rpkilby That's exactly the issue I'm fixing right now, yup :)

bitprophet added a commit that referenced this issue Aug 2, 2017
bitprophet added a commit that referenced this issue Aug 2, 2017
bitprophet added a commit that referenced this issue Aug 2, 2017
Copy link

Works for me now, making sure Travis agrees, then will release as 0.20.2 :)

Copy link

It's on PyPI!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants