Update hub.json for DataLakehouse.io

[guilhermealc]

changing org name, to match current DataLakehouse branding.

Description

Just changing the org name

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]

@joellabes we have instructions here for adding/renaming packages. But we don't yet have instructions documented how to rename an org within hubcap / hub.getdbt.com.

So before merging this PR, we'll want to:

1. Figure out what those instructions are
2. Add them here
3. Follow them for this PR

[dbeatty10]

@guilhermealc to make sure we tie off all loose ends, could you open an associated PR within https://github.com/dbt-labs/hub.getdbt.com that follows these instructions?

You've already done Step 1 (this PR). You'd just need to do Steps 2 and 3.

Could you respond back to this thread when that is complete?

[guilhermealc]

@dbeatty10 , these instructions looks related to changing the package name.
In our case we just want to change the organization name.
But our organization in GitHub is still named as Datalakehouse.... would that still be possible without changing our org name in github?

[dbeatty10]

But our organization in GitHub is still named as Datalakehouse.... would that still be possible without changing our org name in github?

We utilize the organization in GitHub to list out all the packages listed at https://hub.getdbt.com/, so you'd need to change your GitHub org name if you want it to display differently within the dbt Package Hub.

With that information, do you want to proceed with this pull request, or would it be more appropriate to close it?

[guilhermealc]

Gotcha @dbeatty10 , in this case I'll close the PR and open a new one when/if we have our org name updated.
Thanks!