Added new data unification packages to Saras-Daton

[saras-daton]

Description

This is a BigQuery specific package to help BQ users understand their per-execution costs, errors, bottlenecks, and usage more effectively. It optionally will create reporting models that can be used for visualizations and cost & usage alerting. This package built specifically for BigQuery and relies on a cloud audit logging sink being used (explained in Readme).

Link to your package's repository: https://github.com/saras-daton/Walmart https://github.com/saras-daton/PinterestAds https://github.com/saras-daton/AmazonDSP https://github.com/saras-daton/TiktokAds https://github.com/saras-daton/Aftership

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):

• [x] 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:

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

  Interoperability

• [x] 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.
• [x] The package uses the cross-database macros built into dbt Core where available, such as {{ dbt.except() }} and {{ dbt.type_string() }}.
• [x] 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

• [x] (Required): The package's git tags validates against the regex defined in version.py
• [x] 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)

[saras-daton]

Description This is a BigQuery specific package to help BQ users understand their per-execution costs, errors, bottlenecks, and usage more effectively. It optionally will create reporting models that can be used for visualizations and cost & usage alerting. This package built specifically for BigQuery and relies on a cloud audit logging sink being used (explained in Readme).

Link to your package's repository: https://github.com/saras-daton/Walmart https://github.com/saras-daton/PinterestAds https://github.com/saras-daton/AmazonDSP https://github.com/saras-daton/TiktokAds https://github.com/saras-daton/Aftership

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 The package includes a README which explains how to get started with the package and customise its behaviour The README indicates which data warehouses/platforms are expected to work with this package Customisability 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. do not assume database/schema names in sources. Dependencies Dependencies on dbt Core 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)

[dbeatty10]

@saras-daton The PR checklist for new packages is an important part of our quality assurance for packages listed on the Hub -- thank you for your help in completing this important piece.

What you have right now is closer, but not quite right.

Let me know if you need help, and I can edit the PR description on your behalf to restore the PR checklist. After that, you'd still need to go through and fill out the checklist.

Instructions

If you copy and paste the content from here into the original PR description, then it will look like this (after you check the boxes):

[saras-daton]

Description

This is a BigQuery specific package to help BQ users understand their per-execution costs, errors, bottlenecks, and usage more effectively. It optionally will create reporting models that can be used for visualizations and cost & usage alerting. This package built specifically for BigQuery and relies on a cloud audit logging sink being used (explained in Readme).

Link to your package's repository: https://github.com/saras-daton/Walmart https://github.com/saras-daton/PinterestAds https://github.com/saras-daton/AmazonDSP https://github.com/saras-daton/TiktokAds https://github.com/saras-daton/Aftership

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):

• [x] 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:

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

  Interoperability

• [x] 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.
• [x] The package uses the cross-database macros built into dbt Core where available, such as {{ dbt.except() }} and {{ dbt.type_string() }}.
• [x] 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

• [x] (Required): The package's git tags validates against the regex defined in version.py
• [x] 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)

[dbeatty10]

@saras-daton Thanks for filling out that checklist 🙏

In the future, here's how to edit the original PR description (which I've already done for you this time):

[dbeatty10]

@joellabes could you pick up the review process from here?

[saras-daton]

@dbeatty10 additionally, can you please let us know the process of how to remove redundant packages from dbt hub? We tried removing the package name from hub.json, but we can still see the packages on dbt hub.

[dbeatty10]

can you please let us know the process of how to remove redundant packages from dbt hub?

Sure thing: you'll need to open a PR in https://github.com/dbt-labs/hub.getdbt.com

This section contains some instructions for removing a package from hub.getdbt.com: https://github.com/dbt-labs/hub.getdbt.com#rename-a-package

Let us know if you need any help during the process.