Update hub.json

[aneiderhiser]

Added 3 new packages to tuva-health. These were listed previously but then we took them down for a period while we made updates. We're now ready to put them back up.

---

Description

Tell us about your new package!

Link to your package's repository:

Checklist

This checklist is a cut down version of the best practices that we have identified as the package hub has grown. Although meeting these checklist items is not a prerequisite to being added to the Hub, we have found that packages which don't conform provide a worse user experience.

First run experience

• [x] The package includes a README which explains how to get started with the package and customise its behaviour
• [x] The README indicates which data warehouses/platforms are expected to work with this package

Customisability

• [x] The package uses ref or source, instead of hard-coding table references.

  Packages for data transformation (delete if not relevant):

• [ ] provide a mechanism (such as variables) to customise the location of source tables.
• [x] do not assume database/schema names in sources.

Dependencies

Dependencies on dbt Core

• [x] The package has set a supported require-dbt-version range in dbt_project.yml. Example: A package which depends on functionality added in dbt Core 1.2 should set its require-dbt-version property to [">=1.2.0", "<2.0.0"].

  Dependencies on other packages defined in packages.yml:

• [ ] Dependencies are imported from the dbt Package Hub when available, as opposed to a git installation.
• [ ] Dependencies contain the widest possible range of supported versions, to minimise issues in dependency resolution.
• [ ] In particular, dependencies are not pinned to a patch version unless there is a known incompatibility.

  Interoperability

• [ ] The package does not override dbt Core behaviour in such a way as to impact other dbt resources (models, tests, etc) not provided by the package.
• [ ] The package uses the cross-database macros built into dbt Core where available, such as {{ dbt.except() }} and {{ dbt.type_string() }}.
• [ ] The package disambiguates its resource names to avoid clashes with nodes that are likely to already exist in a project. For example, packages should not provide a model simply called users.

Versioning

• [ ] (Required): The package's git tags validates against the regex defined in version.py
• [ ] The package's version follows the guidance of Semantic Versioning 2.0.0. (Note in particular the recommendation for production-ready packages to be version 1.0.0 or above)

[aneiderhiser]

@dbeatty10

[dbeatty10]

@aneiderhiser I'd like to treat each of these as net-new packages so we can make sure each has gone through our checklist.

I've added the checklist to the PR description. Can you duplicate the checklist and fill it out for each new package you are adding? Then ping us again once that's done?

I'm guessing we won't want to add https://github.com/tuva-health/the_tuva_project_demo as a package on the Hub since it looks like it is merely a demo and not a package with reusable macros or transformations. I didn't look at this in-depth, so please let me know if it's more than a demo.

[aneiderhiser]

@dbeatty10 sounds great I'll do that. 2 of the things we want to add are actually projects, not packages. Do you allow projects on dbt hub?

[dbeatty10]

2 of the things we want to add are actually projects, not packages. Do you allow projects on dbt hub?

The dbt Package Hub is intended only for dbt packages that contain macros or models that are intended to be shared across multiple dbt projects (via packages.yml and dbt deps).

Regular dbt projects can just be shared on GitHub. Then people can use those projects by cloning and building them. Demo projects is a perfect example of this.

[aneiderhiser]

@dbeatty10 Makes sense. Then I think the only package we want on dbt hub is the_tuva_project. We can remove medicare_cclf_connector, which is a dbt project, not a package. I'll submit a PR for this.