-
-
Notifications
You must be signed in to change notification settings - Fork 63
Open
Labels
packagingPackaging or distribution issuesPackaging or distribution issuesrefactorChange suggestion, not a bug nor a feature.Change suggestion, not a bug nor a feature.
Description
We'd like to make this repository a monorepo of 2 packages (and at the same time 2 separate PyPI projects) managed with uv workspaces:
griffelib, containing all library logicgriffe, a thin package that can be run as script which wrapsgriffelibwith a CLI
This originates from discussions in #406.
However, when working through this, I realized that it's a huge enough migration that quite a few things could be worth being explicitly mentioned and considered.
Our goals
- All variants of
pip install griffeinstall a CLI application and the library.uvx griffe,pipx run griffeorpip-run griffenaturally run the griffe CLI. - colorama is dropped from griffelib dependencies and is instead a griffe dependency, as in feature: could you make
coloramaan optional dependenncy #406. - Public API imports from griffe, such as
from griffe import ...imports, still work, andgriffe/__init__.pyis just a shim to all public members of thegriffeliblibrary.
Things to consider
- Should we make a major release after this migration?
- I'm not planning to add shims to new
griffe/_internalmodules that would re-export symbols fromgriffelib/_internal-- they're called_internalfor a reason, and btw @pawamoy that's awesome we have it this way. Just noting here that no shims will break a few packages -- but few enough to just go to their repos and kindly inform them that they'll need to migrate to griffelib if they want to maintain their unstable imports. Perhaps they don't even have to use internal imports? I haven't inspected that deeply. - Needs decision: Should we add a warning to all
from griffe ... importlibrary imports, and recommend to import library things from griffelib instead? I'd say no, because maintaining afrom griffe import *is low-cost, so I wouldn't care but perhaps you'd like to drop support for that. Do most people use griffe as an app, not a library? @pawamoy
Migration plan
- Introduce uv workspaces
- Introduce uv dynamic versioning for syncing
griffeandgriffelibreleases to be exact same version. As discussed privately, we'd like the two packages to be released with 1:1 versioning, even if one of them doesn't change, as we find a 1:1 relationship easier to reason about - Migrate tests and CI to new monorepo layout
- Migrate documentation
- Present
griffelibandgriffeseparately in our documentation - Migrate
griffe.*crossrefs togriffelib.*in the docstrings -- thankfully we have this nice tool calledgriffethat will help validate that we did it correctly - Important: make sure the old crossref links redirect to the new crossref targets
- Present
- Release a new version
griffelibandgriffe
Not sure yet how to partition that into PRs. I'll come up with whatever makes sense.
Metadata
Metadata
Assignees
Labels
packagingPackaging or distribution issuesPackaging or distribution issuesrefactorChange suggestion, not a bug nor a feature.Change suggestion, not a bug nor a feature.