amotl
commented
2 weeks ago Introduction
We discussed matters of how to derive subsets of functionality in CrateDB Toolkit into dedicated release artefacts, which not necessarily need to follow the development iterations and release cadence of Toolkit.
Most prominently, this use case appeared with GH-88 and GH-153. We are sharing our thoughts here, about our first approach to that topic on behalf of monorepo paradigms.
Proposal
This is our first proposal, based on preliminary discussions around needs, requirements, and their possible benefits or pitfalls.
Driver
- There will be a GHA workflow, which slices the package on behalf of labels corresponding to setuptools
extralabels 1:1. - Signals to the driver will be submitted on behalf of plain Git tags, being pushed to remote, like LangChain or others are doing it.
Publisher
In order to detach from the regular cadence and relevant build processes, we proposed to:
-
Use a date based versioning scheme ^1, in order to signal low churn, and give users the idea of "software age" right away. For example, a possible first artefact for CrateDB CFR could be
cratedb-cfr-2024.6.1.exe, when applicable. ^3 -
Upload artefacts to ghcr.io instead of using GitHub release assets, like apparently Homebrew is doing it, when possible.
About
We might think about using traditional PyInstaller to build self-contained native binaries? Alternatively, let's try Briefcase, or PyApp?
References