anon-iclr-submission/benchname-bug-localization huggingface dataset:
Repository: dbt-labs/dbt-core
Issue: anonymous event tracking slows down dbt runs when there is no internet connection

## Issue

### Issue description
dbt's anonymous event tracking will try to send events even when there is no internet connection. In these cases, each ping takes about a second to timeout, adding a meaningful amount of time to every run. This was actually the root cause of this issue: https://github.com/fishtown-analytics/dbt/issues/1002

dbt should either try to fire these events in a background thread, or stop trying to send pings if the first one fails. I think the former is preferable, as these shouldn't be blocking calls even if the pings are successful.

### Results
dbt blocked on sending anonymous events, whereas these events should not have measurably impacted the performance of a given dbt run.

### System information
0.11.x

The operating system you're running on:
This happened in a Docker container, though I imagine it would happen on any OS

### Steps to reproduce
Turn off your wifi and wait

Changed files:
core/dbt/tracking.py

diff --git a/core/dbt/tracking.py b/core/dbt/tracking.py
index af1d5b4a2..c9524bf85 100644
--- a/core/dbt/tracking.py
+++ b/core/dbt/tracking.py
@@ -7,6 +7,7 @@ from datetime import datetime
 import pytz
 import platform
 import uuid
+import requests
 import yaml
 import os
 
@@ -25,7 +26,35 @@ PACKAGE_INSTALL_SPEC = 'iglu:com.dbt/package_install/jsonschema/1-0-0'
 
 DBT_INVOCATION_ENV = 'DBT_INVOCATION_ENV'
 
-emitter = Emitter(COLLECTOR_URL, protocol=COLLECTOR_PROTOCOL, buffer_size=1)
+
+class TimeoutEmitter(Emitter):
+    def __init__(self):
+        super(TimeoutEmitter, self).__init__(COLLECTOR_URL,
+                                             protocol=COLLECTOR_PROTOCOL,
+                                             buffer_size=1,
+                                             on_failure=self.handle_failure)
+
+    @staticmethod
+    def handle_failure(num_ok, unsent):
+        # num_ok will always be 0, unsent will always be 1 entry long, because
+        # the buffer is length 1, so not much to talk about
+        logger.warning('Error sending message, disabling tracking')
+        do_not_track()
+
+    def http_get(self, payload):
+        sp_logger.info("Sending GET request to %s..." % self.endpoint)
+        sp_logger.debug("Payload: %s" % payload)
+        r = requests.get(self.endpoint, params=payload, timeout=2.0)
+
+        msg = "GET request finished with status code: " + str(r.status_code)
+        if self.is_good_status_code(r.status_code):
+            sp_logger.info(msg)
+        else:
+            sp_logger.warn(msg)
+        return r
+
+
+emitter = TimeoutEmitter()
 tracker = Tracker(emitter, namespace="cf", app_id="dbt")
 
 active_user = None
Repository: dbt-labs/dbt-core
Issue: When using the `package` syntax without `version`, dbt returns a vague error message


## Issue

### Issue description
When using the `package` syntax without `version`, dbt returns a vague error message:
```
$ cat packages.yml
packages:
  - package: fishtown-analytics/dbt_utils
$ dbt deps
Running with dbt=0.14.0-a1
Encountered an error:
'version'
```
### Expected result
An error message more like:
```
No version was specified for package "fishtown-analytics/dbt_utils"
```
(Even that's not super helpful tbh)


Changed files:
core/dbt/task/deps.py, core/dbt/contracts/project.py, test/unit/test_deps.py

diff --git a/core/dbt/contracts/project.py b/core/dbt/contracts/project.py
index 206f82cda..fc7cba84e 100644
--- a/core/dbt/contracts/project.py
+++ b/core/dbt/contracts/project.py
@@ -243,7 +243,7 @@ REGISTRY_PACKAGE_CONTRACT = {
             'description': 'The version of the package',
         },
     },
-    'required': ['package'],
+    'required': ['package', 'version'],
 }
 
 
diff --git a/core/dbt/task/deps.py b/core/dbt/task/deps.py
index 18ba004ae..307505c0c 100644
--- a/core/dbt/task/deps.py
+++ b/core/dbt/task/deps.py
@@ -118,6 +118,11 @@ class RegistryPackage(Package):
     SCHEMA = REGISTRY_PACKAGE_CONTRACT
 
     def __init__(self, *args, **kwargs):
+        if 'version' not in kwargs:
+            dbt.exceptions.raise_dependency_error(
+                'package dependency {} is missing a "version" field'
+                .format(kwargs.get('package'))
+            )
         super(RegistryPackage, self).__init__(*args, **kwargs)
         self._version = self._sanitize_version(self._contents['version'])
 
diff --git a/test/unit/test_deps.py b/test/unit/test_deps.py
index 06eb163e3..80170bb22 100644
--- a/test/unit/test_deps.py
+++ b/test/unit/test_deps.py
@@ -73,7 +73,7 @@ class TestHubPackage(unittest.TestCase):
         self.assertEqual(a.source_type(), 'hub')
 
     def test_invalid(self):
-        with self.assertRaises(dbt.exceptions.ValidationException):
+        with self.assertRaises(dbt.exceptions.DependencyException):
             RegistryPackage(package='namespace/name', key='invalid')
 
     def test_resolve_ok(self):
Repository: dbt-labs/dbt-core
Issue: Add materializations dirs to include paths for pg/redshift

## Issue

### Issue description
The 0.14.0-a1 pypi distribution of dbt does not include specific macro directories in its `package_data` list. As a result, dbt installed via pip from pypi does not ship with materialization overrides for archival. This manifests as a `merge` statement running for snapshot jobs on pg/redshift projects.

- [package_data](https://github.com/fishtown-analytics/dbt/blob/dev/wilt-chamberlain/plugins/postgres/setup.py#L24-L29)
- unincluded macros:
  - [postgres](https://github.com/fishtown-analytics/dbt/tree/dev/wilt-chamberlain/plugins/postgres/dbt/include/postgres/macros/materializations)
  - [redshift](https://github.com/fishtown-analytics/dbt/tree/dev/wilt-chamberlain/plugins/redshift/dbt/include/redshift/macros/materializations)

We should:
1. include these macro directories in `setup.py` (is there anywhere else to add them?)
2. figure out if there's a good way to keep these things synchronized, or understand if they've fallen out of sync. This works great in development, but only fails once the release is cut on pypi. Is there a way for us to find this earlier?

### Results
dbt used the default snapshot materialization (using a `merge`) and not the pg/redshift-specific implementation provided in the respective plugins.

### System information
The output of `dbt --version`:
```
0.14.0-a1
```

The operating system you're running on:

The python version you're using (probably the output of `python --version`)

### Steps to reproduce
```
pip install dbt
dbt snapshot # on redshift
```

Changed files:
plugins/postgres/setup.py, plugins/redshift/setup.py

diff --git a/plugins/postgres/setup.py b/plugins/postgres/setup.py
index 3f19b0d9d..d6d9331bb 100644
--- a/plugins/postgres/setup.py
+++ b/plugins/postgres/setup.py
@@ -25,6 +25,7 @@ setup(
         'dbt': [
             'include/postgres/dbt_project.yml',
             'include/postgres/macros/*.sql',
+            'include/postgres/macros/**/*.sql',
         ]
     },
     install_requires=[
diff --git a/plugins/redshift/setup.py b/plugins/redshift/setup.py
index c32fd0e78..17f05a82c 100644
--- a/plugins/redshift/setup.py
+++ b/plugins/redshift/setup.py
@@ -25,6 +25,7 @@ setup(
         'dbt': [
             'include/redshift/dbt_project.yml',
             'include/redshift/macros/*.sql',
+            'include/redshift/macros/**/*.sql',
         ]
     },
     install_requires=[
Repository: dbt-labs/dbt-core
Issue: dbt sometimes writes a `.user.yml` and ignores configs

## Issue
If you pass dbt a relative path to `--profiles-dir` or the `DBT_PROFILES_DIR` environment variable and execute from a subdirectory, dbt will look for the user cookie and profiles.yml in different places (the latter correct, the former incorrect).

### Results
What happened? What did you expect to happen?
I got a `./profiles/.user.yml` and my settings were ignored. I expected my settings to be respected or to receive an error, and to not have a new file.

Suggested fixes:
My preference: don't allow users to run dbt from subdirectories.
Other option: defer loading of the user config until after we've found `dbt_project.yml`.

### System information
The output of `dbt --version`:
```
0.14.0
```

The operating system you're running on:
Any

The python version you're using (probably the output of `python --version`)
Any

### Steps to reproduce
In as much detail as possible, please provide steps to reproduce the issue. Sample data that triggers the issue, example models, etc are all very helpful here.

1) Make a dbt project in `${project_root}`
2) put your profiles.yml in  `${project_root}/profiles`
3) Make a subdirectory (`${project_root}/models`) and cd into it
4) Run dbt with the relative path to the profiles directory as an argument to `--profiles-dir`: `dbt run --profiles-dir profiles`
5) You will now have a `${project_root}/models/profiles/.user.yml` with cookie information. Also, any settings in your `profiles.yml` won't be respected.


Changed files:
core/dbt/tracking.py

diff --git a/core/dbt/tracking.py b/core/dbt/tracking.py
index 6307a2da0..b1b876421 100644
--- a/core/dbt/tracking.py
+++ b/core/dbt/tracking.py
@@ -13,8 +13,6 @@ import requests
 import yaml
 import os
 
-import dbt.clients.system
-
 sp_logger.setLevel(100)
 
 COLLECTOR_URL = "fishtownanalytics.sinter-collect.com"
@@ -91,12 +89,22 @@ class User(object):
         tracker.set_subject(subject)
 
     def set_cookie(self):
-        user = {"id": str(uuid.uuid4())}
+        # If the user points dbt to a profile directory which exists AND
+        # contains a profiles.yml file, then we can set a cookie. If the
+        # specified folder does not exist, or if there is not a profiles.yml
+        # file in this folder, then an inconsistent cookie can be used. This
+        # will change in every dbt invocation until the user points to a
+        # profile dir file which contains a valid profiles.yml file.
+        #
+        # See: https://github.com/fishtown-analytics/dbt/issues/1645
 
-        dbt.clients.system.make_directory(self.cookie_dir)
+        user = {"id": str(uuid.uuid4())}
 
-        with open(self.cookie_path, "w") as fh:
-            yaml.dump(user, fh)
+        cookie_path = os.path.abspath(self.cookie_dir)
+        profiles_file = os.path.join(cookie_path, 'profiles.yml')
+        if os.path.exists(cookie_path) and os.path.exists(profiles_file):
+            with open(self.cookie_path, "w") as fh:
+                yaml.dump(user, fh)
 
         return user
Repository: dbt-labs/dbt-core
Issue: 'SnowflakeConnectionManager' object has no attribute 'nice_connection_name'

dbt makes an errant call to [self.nice_connection_name()](https://github.com/fishtown-analytics/dbt/blob/e7a24a2062704a8effd9d9e1f0fc65ee7fb19aa6/plugins/snowflake/dbt/adapters/snowflake/connections.py#L260), but `nice_connection_name()` is defined on the Adapter, not the Connection Manager.

This bug affects Snowflake on dbt == 0.14.0

Changed files:
plugins/snowflake/dbt/adapters/snowflake/connections.py

diff --git a/plugins/snowflake/dbt/adapters/snowflake/connections.py b/plugins/snowflake/dbt/adapters/snowflake/connections.py
index f2005b50c..2952d364a 100644
--- a/plugins/snowflake/dbt/adapters/snowflake/connections.py
+++ b/plugins/snowflake/dbt/adapters/snowflake/connections.py
@@ -252,12 +252,18 @@ class SnowflakeConnectionManager(SQLConnectionManager):
             )
 
         if cursor is None:
+            conn = self.get_thread_connection()
+            if conn is None or conn.name is None:
+                conn_name = '<None>'
+            else:
+                conn_name = conn.name
+
             raise dbt.exceptions.RuntimeException(
                 "Tried to run an empty query on model '{}'. If you are "
                 "conditionally running\\nsql, eg. in a model hook, make "
                 "sure your `else` clause contains valid sql!\\n\\n"
                 "Provided SQL:\\n{}"
-                .format(self.nice_connection_name(), sql)
+                .format(conn_name, sql)
             )
 
         return connection, cursor
Repository: dbt-labs/dbt-core
Issue: Unclosed connections prevent dbt from exiting on Snowflake with keepalives enabled

## Issue

### Issue description
The `client_session_keep_alive` config for snowflake-connector-python is implemented using a threaded heartbeat. During the `dbt docs generate` command (and possibly others), dbt doesn't close 100% of the connections it opens. As a result, the snowflake-connector-python threads continue to heartbeat in perpetuity, preventing dbt from exiting. See the comment [here](https://github.com/snowflakedb/snowflake-connector-python/issues/104#issuecomment-424350077) while slowly and deliberately raising the palm of your hand  into the vicinity of your face.

We should, in general, ensure that dbt always closes any connections that it opens.

### Results
dbt finishes executing, but control is not returned to the terminal. Instead, python hangs on a lock held by snowflake-connector-python, and the user needs to ctrl-c to exit.

### System information
The output of `dbt --version`:
```
0.12.2
```

The operating system you're running on: Any

### Steps to reproduce
1. Set up a Snowflake profile, configuring `client_session_keep_alive` to be `True`
2. Run `dbt docs generate`
3. wait forever

Changed files:
core/dbt/main.py

diff --git a/core/dbt/main.py b/core/dbt/main.py
index fbfa02e17..655ea698a 100644
--- a/core/dbt/main.py
+++ b/core/dbt/main.py
@@ -23,7 +23,7 @@ import dbt.task.freshness as freshness_task
 import dbt.task.run_operation as run_operation_task
 from dbt.task.list import ListTask
 from dbt.task.rpc_server import RPCServerTask
-from dbt.adapters.factory import reset_adapters
+from dbt.adapters.factory import reset_adapters, cleanup_connections
 
 import dbt.tracking
 import dbt.ui.printer
@@ -123,6 +123,15 @@ def initialize_config_values(parsed):
     cfg.set_values(parsed.profiles_dir)
 
 
+@contextmanager
+def adapter_management():
+    reset_adapters()
+    try:
+        yield
+    finally:
+        cleanup_connections()
+
+
 def handle_and_check(args):
     with log_manager.applicationbound():
         parsed = parse_args(args)
@@ -143,10 +152,10 @@ def handle_and_check(args):
 
             initialize_config_values(parsed)
 
-            reset_adapters()
+            with adapter_management():
 
-            task, res = run_from_args(parsed)
-            success = task.interpret_results(res)
+                task, res = run_from_args(parsed)
+                success = task.interpret_results(res)
 
             return res, success
Repository: dbt-labs/dbt-core
Issue: Postgres character columns are not treated as string types

## Issue

### Issue description
dbt does not treat character types as string types, and therefore leaves out the length portion of the `character` column type when building columns. This happens during Archival (and likely incremental models when expanding types) on Postgres.

### Results
dbt should treat `character` as a string type, as with `varchar` and `text`.

### System information
The output of `dbt --version`:
```
0.12.x
```

### Steps to reproduce
Archive a table on Postgres with a column of type `character(36)`. dbt will recreate this column with type `character` with no size specified.


This issue was created from the description of https://github.com/fishtown-analytics/dbt/pull/1191

Changed files:
dbt/schema.py, test/unit/test_schema.py

diff --git a/dbt/schema.py b/dbt/schema.py
index 3a34903a8..f4b75e7b6 100644
--- a/dbt/schema.py
+++ b/dbt/schema.py
@@ -45,7 +45,7 @@ class Column(object):
             return self.dtype
 
     def is_string(self):
-        return self.dtype.lower() in ['text', 'character varying']
+        return self.dtype.lower() in ['text', 'character varying', 'character']
 
     def is_numeric(self):
         return self.dtype.lower() in ['numeric', 'number']
diff --git a/test/unit/test_schema.py b/test/unit/test_schema.py
index a7c3d94ff..6c065a422 100644
--- a/test/unit/test_schema.py
+++ b/test/unit/test_schema.py
@@ -2,6 +2,17 @@ import unittest
 
 import dbt.schema
 
+class TestStringType(unittest.TestCase):
+
+    def test__character_type(self):
+        col = dbt.schema.Column(
+            'fieldname',
+            'character',
+            char_size=10
+        )
+
+        self.assertEqual(col.data_type, 'character varying(10)')
+
 
 class TestNumericType(unittest.TestCase):
Repository: dbt-labs/dbt-core
Issue: `this` should not be supplied in an operation context

In 0.10.1, `this` was usable in the context of an operation (ie. `on-run-start`, `on-run-end`). These instances of `this` should be replaced with `target`, as the operation does not run in the context of any particular model.

We should remove `this` from the operation context.

Changed files:
dbt/context/common.py

diff --git a/dbt/context/common.py b/dbt/context/common.py
index d2f23eda8..84a686160 100644
--- a/dbt/context/common.py
+++ b/dbt/context/common.py
@@ -407,10 +407,22 @@ def generate(model, project_cfg, flat_graph, provider=None):
         "try_or_compiler_error": try_or_compiler_error(model)
     })
 
-    # Operations do not represent database relations, so 'this' does not apply
-    if model.get('resource_type') != NodeType.Operation:
-        context["this"] = get_this_relation(db_wrapper, project_cfg, profile,
-                                            model)
+    # Operations do not represent database relations, so there should be no
+    # 'this' variable in the context for operations. The Operation branch
+    # below should be removed in a future release. The fake relation below
+    # mirrors the historical implementation, without causing errors around
+    # the missing 'alias' attribute for operations
+    #
+    # https://github.com/fishtown-analytics/dbt/issues/878
+    if model.get('resource_type') == NodeType.Operation:
+        this = db_wrapper.adapter.Relation.create(
+                schema=target['schema'],
+                identifier=model['name']
+        )
+    else:
+        this = get_this_relation(db_wrapper, project_cfg, profile, model)
+
+    context["this"] = this
 
     context = _add_tracking(context)
     context = _add_validation(context)
Repository: dbt-labs/dbt-core
Issue: Python 3.6.2 doesn't work with dbt 0.17.0

### Describe the bug
Running dbt on python <= 3.6.2 results in an error that `name 'TimestampSnapshotConfig' is not defined`. 3.6.3 is unaffected.

### Steps To Reproduce
Install python 3.6.2
Install dbt
Try to use dbt

### Expected behavior
dbt should run, not crash, etc


### System information
**Which database are you using dbt with?**
Any

**The output of `dbt --version`:**
```
0.17.0
```

**The operating system you're using:**
macos, linux

**The output of `python --version`:**
`Python 3.6.2`



Changed files:
core/setup.py

diff --git a/core/setup.py b/core/setup.py
index b63daad5d..82fc31ae8 100644
--- a/core/setup.py
+++ b/core/setup.py
@@ -86,5 +86,5 @@ setup(
         'Programming Language :: Python :: 3.7',
         'Programming Language :: Python :: 3.8',
     ],
-    python_requires=">=3.6.2",
+    python_requires=">=3.6.3",
 )
Repository: dbt-labs/dbt-core
Issue: --fail-fast msg typo

### Describe the bug
Typo in `--fail-fast` runner message:
```
Falling early due to test failure or runtime error
```
should say
```
Failing early due to test failure or runtime error
```

**The output of `dbt --version`:**
```
installed version: 0.17.0-rc1
   latest version: 0.16.1

Your version of dbt is ahead of the latest release!

Plugins:
  - bigquery: 0.17.0rc1
  - snowflake: 0.17.0rc1
  - redshift: 0.17.0rc1
  - postgres: 0.17.0rc1
```

Changed files:
core/dbt/task/runnable.py

diff --git a/core/dbt/task/runnable.py b/core/dbt/task/runnable.py
index 6fd8562fa..525e1216c 100644
--- a/core/dbt/task/runnable.py
+++ b/core/dbt/task/runnable.py
@@ -183,7 +183,7 @@ class GraphRunnableTask(ManifestTask):
 
         if (result.fail is not None or result.error is not None) and fail_fast:
             self._raise_next_tick = FailFastException(
-                message='Falling early due to test failure or runtime error',
+                message='Failing early due to test failure or runtime error',
                 result=result,
                 node=getattr(result, 'node', None)
             )
Repository: dbt-labs/dbt-core
Issue: Update comment re: private method rename: _add_ctes

### Describe the bug
In #2834, it looks like we switched the name of the internal method from `_insert_ctes` to `_add_ctes`. That's fine, we should just also update the comment that serves as a hint for plugin authors:

https://github.com/fishtown-analytics/dbt/blob/3af02020ff697cbc34b7bf7d538e99ccd1979afd/core/dbt/compilation.py#L353-L358

### Context
Adapter plugin authors for databases that don't support nested CTEs should have a clear point of intervention to alter dbt's behavior when constructing data tests and ephemeral models:
- [dbt-synapse#25](https://github.com/dbt-msft/dbt-synapse/issues/25)
- [dbt-sqlserver#26](https://github.com/mikaelene/dbt-sqlserver/issues/26)

If we have a little extra time, I'd like to prove it's actually possible to override this behavior for data tests and ephemeral models by overriding `_add_ctes` in an adapter plugin.

Changed files:
core/dbt/compilation.py

diff --git a/core/dbt/compilation.py b/core/dbt/compilation.py
index f66b6806a..0d6a4ccb9 100644
--- a/core/dbt/compilation.py
+++ b/core/dbt/compilation.py
@@ -348,13 +348,13 @@ class Compiler:
         manifest: Manifest,
         extra_context: Dict[str, Any],
     ) -> NonSourceCompiledNode:
-        """Insert the CTEs for the model."""
+        """Wrap the data test SQL in a CTE."""
 
         # for data tests, we need to insert a special CTE at the end of the
         # list containing the test query, and then have the "real" query be a
         # select count(*) from that model.
-        # the benefit of doing it this way is that _insert_ctes() can be
-        # rewritten for different adapters to handle databses that don't
+        # the benefit of doing it this way is that _add_ctes() can be
+        # rewritten for different adapters to handle databases that don't
         # support CTEs, or at least don't have full support.
         if isinstance(compiled_node, CompiledDataTestNode):
             # the last prepend (so last in order) should be the data test body.
Repository: dbt-labs/dbt-core
Issue: set colorama upper bound to <0.4.4

colorama v0.4.4 (released in the last 24 hours) is missing an sdist, which trips up the homebrew packaging step of our [dbt release flow](https://github.com/fishtown-analytics/dbt-release/runs/1249693542). Let's set the [upper bound](https://github.com/fishtown-analytics/dbt/blob/dev/kiyoshi-kuromiya/core/setup.py#L67) to <0.4.4 instead of <0.5 for now.

Changed files:
core/setup.py

diff --git a/core/setup.py b/core/setup.py
index 71fc77658..118cac2d3 100644
--- a/core/setup.py
+++ b/core/setup.py
@@ -64,7 +64,7 @@ setup(
         'sqlparse>=0.2.3,<0.4',
         'networkx>=2.3,<3',
         'minimal-snowplow-tracker==0.0.2',
-        'colorama>=0.3.9,<0.5',
+        'colorama>=0.3.9,<0.4.4',
         'agate>=1.6,<2',
         'isodate>=0.6,<0.7',
         'json-rpc>=1.12,<2',
Repository: dbt-labs/dbt-core
Issue: Minor rendering bug for clickable `docs serve` output

### Describe the bug

When running `dbt serve` the printout of the url where the docs are served is rendering with a period ('.') immediately adjacent to the link. This is a minor issue but it prevents link detection from working correctly by terminals (VS Code in my case) which automatically detect URLs and render them as hyperlinks. In this case, the output is correctly parsed as a URL but because the URL includes a '.' at the end, it reaches a dead end (equivalent to pasting `http://localhost:8081.` in chrome address bar).

```
To access from your browser, navigate to http://localhost:8080.
```

### Steps To Reproduce

1. Run `dbt docs serve`

### Expected behavior

Ideally, the printout would be rendered as:

```
To access from your browser, navigate to: http://localhost:8080
```

### Screenshots and log output

```
Running with dbt=0.13.0
Serving docs at 0.0.0.0:8080
To access from your browser, navigate to http://localhost:8080.
Press Ctrl+C to exit.
```

### System information
**Which database are you using dbt with?**
- [ ] postgres
- [ ] redshift
- [ ] bigquery
- [ ] snowflake
- [ ] other (specify: ____________)


**The output of `dbt --version`:**
```
Running with dbt=0.13.0
```

**The operating system you're using:**

**The output of `python --version`:**

### Additional context
Add any other context about the problem here.


Changed files:
core/dbt/task/serve.py

diff --git a/core/dbt/task/serve.py b/core/dbt/task/serve.py
index d92f37312..2170d00e5 100644
--- a/core/dbt/task/serve.py
+++ b/core/dbt/task/serve.py
@@ -20,7 +20,7 @@ class ServeTask(ProjectOnlyTask):
 
         logger.info("Serving docs at 0.0.0.0:{}".format(port))
         logger.info(
-            "To access from your browser, navigate to http://localhost:{}."
+            "To access from your browser, navigate to:  http://localhost:{}"
             .format(port)
         )
         logger.info("Press Ctrl+C to exit.\\n\\n")
Repository: dbt-labs/dbt-core
Issue: Fix docstring for dbt docs generate

### Describe the bug
The docstring for dbt docs seems to indicate that if you want to use a different target, you would put the `--target` parameter before generate:
```
# dbt docs -h
usage: dbt docs [-h] [--project-dir PROJECT_DIR] [--profiles-dir PROFILES_DIR] [--profile PROFILE] [--target TARGET] [--vars VARS] [--bypass-cache] {generate,serve} ...
```
However, when I try that, it doesn't honor the parameter
```
# dbt docs --target prod generate
Running with dbt=0.14.3
Found 125 models, 207 tests, 15 snapshots, 0 analyses, 254 macros, 2 operations, 3 seed files, 101 sources
19:31:38 | Concurrency: 4 threads (target='dev')
```

However, if I put the flag at the end like this, it works fine:
```
# dbt docs generate --target prod
```

### Steps To Reproduce
See above

### Expected behavior
The docs should be in alignment with the actual commands.

### Screenshots and log output
See above

### System information
**Which database are you using dbt with?**
- [ ] postgres
- [x ] redshift
- [ ] bigquery
- [ ] snowflake
- [ ] other (specify: ____________)


**The output of `dbt --version`:**
```
installed version: 0.14.3
```

**The operating system you're using:** Debian GNU/Linux 10 (buster)

**The output of `python --version`:** 3.6.9

### Additional context



Changed files:
core/dbt/main.py

diff --git a/core/dbt/main.py b/core/dbt/main.py
index ac8562195..12fa3bb23 100644
--- a/core/dbt/main.py
+++ b/core/dbt/main.py
@@ -287,7 +287,6 @@ def _build_base_subparser():
 def _build_docs_subparser(subparsers, base_subparser):
     docs_sub = subparsers.add_parser(
         'docs',
-        parents=[base_subparser],
         help='''
         Generate or serve the documentation website for your project.
         '''
@@ -298,7 +297,6 @@ def _build_docs_subparser(subparsers, base_subparser):
 def _build_source_subparser(subparsers, base_subparser):
     source_sub = subparsers.add_parser(
         'source',
-        parents=[base_subparser],
         help='''
         Manage your project's sources
         ''',
@@ -884,7 +882,9 @@ def parse_args(args, cls=DBTArgumentParser):
         sys.exit(1)
 
     parsed = p.parse_args(args)
-    parsed.profiles_dir = os.path.expanduser(parsed.profiles_dir)
+
+    if hasattr(parsed, 'profiles_dir'):
+        parsed.profiles_dir = os.path.expanduser(parsed.profiles_dir)
 
     if not hasattr(parsed, 'which'):
         # the user did not provide a valid subcommand. trigger the help message
Repository: dbt-labs/dbt-core
Issue: Unhelpful error message with malformed packages.yml

### Describe the bug
```
MacBook-Pro:analytics tristan$ cat packages.yml
packages:
  - package: fishtown-analytics/stripe
    revision: 0.3.1
```

I had recently switched from a git reference to this package to a hub reference, and forgot that I needed to change from `revision` to `version`. This is the error message I received, which made it significantly more challenging to debug:

```
MacBook-Pro:analytics tristan$ dbt clean && dbt deps
Running with dbt=0.15.0
Encountered an error while reading the project:
  ERROR: Runtime Error
  Invalid package config: at path []: 'local' is a required property
```

### Expected behavior
I would expect an error message like:
```
Required parameter version not supplied.
```
...or something similar.

**The output of `dbt --version`:**
```
MacBook-Pro:analytics tristan$ dbt --version
installed version: 0.15.0
   latest version: 0.15.0

Up to date!
```

Changed files:
core/dbt/config/project.py

diff --git a/core/dbt/config/project.py b/core/dbt/config/project.py
index 620aa0773..3ba025fa7 100644
--- a/core/dbt/config/project.py
+++ b/core/dbt/config/project.py
@@ -59,6 +59,17 @@ Check the requirements for the '{package}' package, or run dbt again with \\
 --no-version-check
 """
 
+MALFORMED_PACKAGE_ERROR = """\\
+The packages.yml file in this project is malformed. Please double check
+the contents of this file and fix any errors before retrying.
+
+You can find more information on the syntax for this file here:
+https://docs.getdbt.com/docs/package-management
+
+Validator Error:
+{error}
+"""
+
 
 def _list_if_none(value):
     if value is None:
@@ -130,7 +141,7 @@ def package_config_from_data(packages_data):
         packages = PackageConfig.from_dict(packages_data)
     except ValidationError as e:
         raise DbtProjectError(
-            'Invalid package config: {}'.format(validator_error_message(e))
+            MALFORMED_PACKAGE_ERROR.format(error=str(e.message))
         ) from e
     return packages
Repository: dbt-labs/dbt-core
Issue: Ephemeral models are shown as cancelled on KeyboardInterrupt

### Describe the bug
This is a minor UI bug - ephemeral models are shown as "cancelled" when a running dbt process is ctrl-c'd. I didn't dig so far into the implementation that I know exactly where this is coming from, but my instinct is that it has something to do with dbt "selecting" all ephemeral models for a run by default, a recent-ish performance improvement.

### Steps To Reproduce
1. Create an ephemeral model
```
{{ config(materialized='ephemeral') }}

select 1 as id
```

2. Create a slow table model
```
{{ config(materialized='table') }}

select 1 as id from pg_sleep(10)
```

3. `dbt run`
4. `ctrl-c` the running process.

Results:
```
14:50:59 | Concurrency: 8 threads (target='dev')
14:50:59 |
14:50:59 | 1 of 1 START table model test_schema.my_first_model............................ [RUN]
^C14:51:05 | CANCEL query model.debug.eph............................................. [CANCEL]
********* ^ this ephemeral should not be shown as cancelled ^ **********
14:51:05 | CANCEL query model.debug.my_first_model.................................. [CANCEL]
14:51:05 | 1 of 1 ERROR creating table model test_schema.my_first_model................... [ERROR in 5.30s]
```

**The output of `dbt --version`:**
```
v0.15.0
```

Changed files:
core/dbt/task/runnable.py

diff --git a/core/dbt/task/runnable.py b/core/dbt/task/runnable.py
index 0efb782a1..394d8f09a 100644
--- a/core/dbt/task/runnable.py
+++ b/core/dbt/task/runnable.py
@@ -242,6 +242,11 @@ class GraphRunnableTask(ManifestTask):
                 raise
 
             for conn_name in adapter.cancel_open_connections():
+                if self.manifest is not None:
+                    node = self.manifest.nodes.get(conn_name)
+                    if node is not None and node.is_ephemeral_model:
+                        continue
+                # if we don't have a manifest/don't have a node, print anyway.
                 dbt.ui.printer.print_cancel_line(conn_name)
 
             pool.join()
Repository: dbt-labs/dbt-core
Issue: Show a more helpful error message when plugins cannot be imported

### Describe the bug
If a dbt plugin cannot be imported, dbt will show a message about invalid credentials, eg:
```
Running with dbt=0.14.3
Error importing adapter: cannot import name 'collections_abc'
Encountered an error while reading profiles:
  ERROR Runtime Error
  Credentials in profile "<profile name>", target "dev" invalid: Runtime Error
    Could not find adapter type bigquery!
Defined profiles:
 - ....
```

If this is an error that occurs at import-time, dbt should not indicate that the credentials are invalid. dbt should also not show a list of defined profiles in this error message.

Desired output:
```
Running with dbt=0.14.3
The dbt plugin 'bigquery' could not be imported: cannot import name 'collections_abc'
```

dbt version: v0.14.3. I need to test against 0.15.0 to determine if this behavior has recently changed.

Changed files:
core/dbt/adapters/factory.py

diff --git a/core/dbt/adapters/factory.py b/core/dbt/adapters/factory.py
index 0c8edd272..0742a1e0c 100644
--- a/core/dbt/adapters/factory.py
+++ b/core/dbt/adapters/factory.py
@@ -46,16 +46,17 @@ class AdpaterContainer:
         # singletons
         try:
             mod = import_module('.' + name, 'dbt.adapters')
-        except ImportError as e:
-            logger.info("Error importing adapter: {}".format(e))
-            raise RuntimeException(
-                "Could not find adapter type {}!".format(name)
-            )
-        if not hasattr(mod, 'Plugin'):
-            raise RuntimeException(
-                f'Could not find plugin in {name} plugin module'
-            )
-        plugin: AdapterPlugin = mod.Plugin  # type: ignore
+        except ModuleNotFoundError as exc:
+            # if we failed to import the target module in particular, inform
+            # the user about it via a runtiem error
+            logger.info(f'Error importing adapter: {exc}')
+            if exc.name == 'dbt.adapters.' + name:
+                raise RuntimeException(f'Could not find adapter type {name}!')
+            # otherwise, the error had to have come from some underlying
+            # library. Log the stack trace.
+            logger.debug('', exc_info=True)
+            raise
+        plugin = mod.Plugin  # type: AdapterPlugin
         plugin_type = plugin.adapter.type()
 
         if plugin_type != name:
Repository: dbt-labs/dbt-core
Issue: [LMA Regression] redshift get_catalog requires exactly one database

### Describe the bug
Users are seeing the `redshift get_catalog requires exactly one database` error on dbt v0.15.0-rc1 even though they only have a single database specified in their project.

### Steps To Reproduce
Exact reproduction case tbd

Changed files:
core/dbt/adapters/base/relation.py

diff --git a/core/dbt/adapters/base/relation.py b/core/dbt/adapters/base/relation.py
index d429fb7f3..957ac3802 100644
--- a/core/dbt/adapters/base/relation.py
+++ b/core/dbt/adapters/base/relation.py
@@ -246,7 +246,10 @@ class BaseRelation(FakeAPIObject, Hashable):
         if not isinstance(view_name, str):
             view_name = None
 
-        return InformationSchema.from_relation(self, view_name)
+        # Kick the user-supplied schema out of the information schema relation
+        # Instead address this as <database>.information_schema by default
+        info_schema = InformationSchema.from_relation(self, view_name)
+        return info_schema.incorporate(path={"schema": None})
 
     def information_schema_only(self) -> 'InformationSchema':
         return self.information_schema()
Repository: dbt-labs/dbt-core
Issue: [LMA regression] Runs randomly fail with "SchemaError"s

### Describe the bug
If you run dbt commands enough times, you will eventually get a weird jsonschema error:

```
  None is not of type 'object', 'boolean'

  Failed validating 'type' in metaschema['properties']['definitions']['additionalProperties']:
      {'$id': 'http://json-schema.org/draft-07/schema#',
  <snipped a lot of json here>
  On schema['definitions']['Policy']:
      None
```

That last line is one of a few possible values. It only seems to happen with multiple threads. I assume it involves some aspect of the stuff hologram does for schema generation/caching.

dbt should either wrap `hologram` and retry, or we should fix `hologram` and rely on the fixed version.

### Steps To Reproduce
1) Clone jaffle shop, or any other working dbt project
2) echo ''; while [[ $? -eq 0 ]]; do dbt docs generate --threads=8; done
3) wait a bit

There's possibly more to this, I think I've also triggered it with `dbt run`, but that seems much more difficult.


### Expected behavior
dbt should pass/should not raise big errors about metaschema junk

### Screenshots and log output
See above

### System information
**Which database are you using dbt with?**
- [X] postgres

**The output of `dbt --version`:**
```
installed version: 0.15.0-b2
   latest version: 0.14.3

Your version of dbt is ahead of the latest release!
```

**The operating system you're using:**
Macos Mojave, also seen on docker

**The output of `python --version`:**
Python 3.6.5

### Additional context


Changed files:
core/setup.py

diff --git a/core/setup.py b/core/setup.py
index 1186b9e7e..6509e481b 100644
--- a/core/setup.py
+++ b/core/setup.py
@@ -56,7 +56,7 @@ setup(
         'json-rpc>=1.12,<2',
         'werkzeug>=0.15,<0.17',
         'dataclasses==0.6;python_version<"3.7"',
-        'hologram==0.0.4',
+        'hologram==0.0.5',
         'logbook>=1.5,<1.6',
         'pytest-logbook>=1.2.0,<1.3',
         'typing-extensions>=3.7.4,<3.8',
Repository: dbt-labs/dbt-core
Issue: [BUG] Command line variable ignored when supplied to command in server

### Describe the bug
When I run this command against the `cli` method in the server:
```
dbt run --vars '{period_start_date: '2019-04-01', period: 'day'}' -m buildings
```
the command line variables are ignored. Instead I would expect the command line variables to be present in the context. 

Note: partial parsing is enabled in this environment

### Steps To Reproduce
tbd


**The output of `dbt --version`:**
```
O.15.2
```


Changed files:
test/rpc/test_base.py, core/dbt/task/rpc/cli.py

diff --git a/core/dbt/task/rpc/cli.py b/core/dbt/task/rpc/cli.py
index e3bb477c4..d5bb61b6d 100644
--- a/core/dbt/task/rpc/cli.py
+++ b/core/dbt/task/rpc/cli.py
@@ -1,5 +1,6 @@
 import abc
 import shlex
+import yaml
 from typing import Type, Optional
 
 
@@ -12,6 +13,7 @@ from dbt.rpc.method import (
     Result,
 )
 from dbt.exceptions import InternalException
+from dbt.utils import parse_cli_vars
 
 from .base import RPCTask
 
@@ -36,6 +38,15 @@ class RemoteRPCCli(RPCTask[RPCCliParameters]):
 
     def set_config(self, config):
         super().set_config(config)
+
+        # read any cli vars we got and use it to update cli_vars
+        self.config.cli_vars.update(
+            parse_cli_vars(getattr(self.args, 'vars', '{}'))
+        )
+        # rewrite args.vars to reflect our merged vars
+        self.args.vars = yaml.safe_dump(self.config.cli_vars)
+        self.config.args = self.args
+
         if self.task_type is None:
             raise InternalException('task type not set for set_config')
         if issubclass(self.task_type, RemoteManifestMethod):
diff --git a/test/rpc/test_base.py b/test/rpc/test_base.py
index 140741bb2..14694f155 100644
--- a/test/rpc/test_base.py
+++ b/test/rpc/test_base.py
@@ -863,3 +863,25 @@ def test_missing_tag_sighup(
         querier.sighup()
 
         assert querier.wait_for_status('ready') is True
+
+
+def test_rpc_vars(
+    project_root, profiles_root, postgres_profile, unique_schema
+):
+    project = ProjectDefinition(
+        models={
+            'my_model.sql': 'select {{ var("param") }} as id',
+        },
+    )
+    querier_ctx = get_querier(
+        project_def=project,
+        project_dir=project_root,
+        profiles_dir=profiles_root,
+        schema=unique_schema,
+        test_kwargs={},
+    )
+
+    with querier_ctx as querier:
+        results = querier.async_wait_for_result(querier.cli_args('run --vars "{param: 100}"'))
+        assert len(results['results']) == 1
+        assert results['results'][0]['node']['compiled_sql'] == 'select 100 as id'