Skip to content

Commit

Permalink
Merge branch 'main' into er/20-branch-protections
Browse files Browse the repository at this point in the history
  • Loading branch information
emmyoop authored Jan 22, 2024
2 parents f4a231f + 069043b commit 63f5ee8
Show file tree
Hide file tree
Showing 4 changed files with 86 additions and 4 deletions.
4 changes: 1 addition & 3 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,6 @@
** replace `dbt-common` with your repository name in all docs

## Understanding dbt-common

A short description of the purpose of this repository. Include relevant images.
The shared common utilities for dbt-core and adapter implementations use

## Getting started

Expand Down
1 change: 1 addition & 0 deletions dbt_common/__about__.py
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
version = "0.1.0"
80 changes: 80 additions & 0 deletions docs/arch/adr-0001-build-tooling.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
# Build Tool


## Context

We need to select a build tool for managing dependencies for, building, and distributing `dbt-common`. While tooling can vary, this repo can serve as an OSS template for other OSS at dbt Labs and beyond.


## Options

- `setuptools` (`twine`, `build`)
- `hatch`
- `poetry`


### setuptools

#### Pro's

- most popular option
- supported by Python Packaging Authority
- build tool of record for dbt-core & existing internal adapters

#### Con's

- less flexible; forced to support backwards compatibility more so than other options
- no dependency management (manually add to `pyproject.toml`)


### hatch

#### Pro's

- supported by Python Packaging Authority
- already used by `dbt-semantic-layer` and `internal-actions`
- supports running tests against multiple versions of python locally (same functionality as `tox`)
- supports configuring workflows in `pyproject.toml` (same functionality as `make`)
- incorporates new PEP's quickly
- Manages python distributions itself without need of pyenv. This allows Windows and non-Windows users to both work locally in the same way.
- used by black, tox, pipx, Jupyter Notebook, Datadog

#### Con's

- far less popular than other options
- no dependency management (manually add to `pyproject.toml`)
- only one maintainer (but is officially part of the larger PyPA working group)
- Hatch does not allow for the installation of specific patch release versions of itself but rather only uses minor release granularity that tracks the latest patch release


### poetry

#### Pro's

- second most popular option, similar in popularity to `setuptools`
- dependency management (`poetry add "my-dependency"`)
- provides a lock file
- more than one maintainer

#### Con's

- incorporates new PEP's slowly


## Decision

#### Selected: `hatch`

This option aligns with `dbt-adapter` and `dbt-semantic-layer`, which minimizes confusion
for anyone working in multiple repositories.
`hatch` also replaces `tox` and `make`, which consolidates our toolset to make working locally and with CI more consistant.


## Consequences

- [+] retire `tox`
- [+] retire `make`
- [+] rewriting the release workflows will create a more intuitive release for hatch projects
- [-] we cannot reuse the existing release workflows
- [-] write more detailed docs given lower familiarity
- [-] learning curve
5 changes: 4 additions & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[project]
name = "dbt-common"
version = "0.0.1"
dynamic = ["version"]
description = "The shared common utilities that dbt-core and adapter implementations use"
readme = "README.md"
requires-python = ">=3.8"
Expand Down Expand Up @@ -33,6 +33,9 @@ dependencies = [
"typing-extensions~=4.4",
]

[tool.hatch.version]
path = "dbt_common/__about__.py"

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
Expand Down

0 comments on commit 63f5ee8

Please sign in to comment.