@mnci/nx-python-pip 0.1.6 → 0.1.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +5 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -85,8 +85,11 @@ project graph** (not a hard-coded path), copies its module directory into a
|
|
|
85
85
|
staged copy of the project being built, patches the staged
|
|
86
86
|
`pyproject.toml`'s `[tool.hatch.build.targets.wheel] packages` list to
|
|
87
87
|
include it, and builds from there. No cross-project dependency is ever wired
|
|
88
|
-
automatically
|
|
89
|
-
|
|
88
|
+
automatically by this plugin — the entry above is always a hand-edit as far
|
|
89
|
+
as it's concerned. If you're using `@mnci/cli`, `mnci add python-vendor
|
|
90
|
+
<consumer> --lib my-shared-lib` writes exactly that edit for you
|
|
91
|
+
(idempotently); this package itself stays that CLI-agnostic — reading the
|
|
92
|
+
entry, not writing it.
|
|
90
93
|
|
|
91
94
|
Verified empirically that vendoring an internal lib and declaring a real
|
|
92
95
|
external PyPI dependency on the *same* project works correctly together —
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@mnci/nx-python-pip",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.7",
|
|
4
4
|
"description": "An Nx plugin for pip-native Python projects (Ruff + pytest + the standard PyPA build/twine tools) — no uv, no Poetry, no lock file.",
|
|
5
5
|
"publishConfig": {
|
|
6
6
|
"access": "public"
|