@mnci/nx-python-pip 0.1.2 → 0.1.3

package/README.md

@@ -11,7 +11,7 @@ ships only `uv` and Poetry providers, and every alternative found on npm is
 either the same uv/Poetry architecture or years stale. If your organization
 standardizes on plain pip (no uv, no Poetry), this plugin fills that gap.
 
-It was built for and is used by [`@mnci/cli`](../cli)'s `mnci2 add python-*`
+It was built for and is used by [`@mnci/cli`](../cli)'s `mnci add python-*`
 commands, but has no dependency on `@mnci/cli` — any Nx 21+ workspace can
 install and use it directly.
 
@@ -115,6 +115,12 @@ dependencies).
   wheel — not from a plain `pip install -e .` dev environment, since
   vendoring happens at `build` time only. A project whose pytest-covered
   code imports a vendored internal lib needs its own test-isolation
-  strategy; the `test` executor makes no attempt to solve this.
+  strategy; the `test` executor makes no attempt to solve this (it only
+  editable-installs the project under test, never what it imports). A
+  workspace can solve it at the workspace level instead, by
+  editable-installing every Python project (not just the one under test)
+  into one shared environment — the pip-world counterpart of `npm install`
+  hoisting every workspace package into one root `node_modules`. `@mnci/cli`
+  does exactly this as a guarded CI step; see its README.
 - venv management is left to the user — same spirit as never managing
   `node_modules` beyond `npm install`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mnci/nx-python-pip",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "An Nx plugin for pip-native Python projects (Ruff + pytest + the standard PyPA build/twine tools) — no uv, no Poetry, no lock file.",
   "publishConfig": {
     "access": "public"