You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 30, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: runestone_poetry_project/poetry_fix.py
+95-11Lines changed: 95 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,72 @@
1
1
# ***********************************
2
2
# |docname| - Work around Poetry bugs
3
3
# ***********************************
4
-
# This script contains two fixes for Poetry bugs: one bug which manifests when the ``--no-dev`` flag is passed to ``poetry install/update`` and another which occurs when the ``--no-dev`` flag isn't passed. It doesn't provide a fix to a third bug, discussed below
4
+
# This script contains workarounds for Poetry design decisions and bugs:
5
+
#
6
+
# #. Poetry doesn't support either/or dependencies, but this project needs them. Specifically, we want to install either the released, PyPI-published version of the RunestoneComponents and the BookServer, or the development version of these projects which are cloned to the local filesystem. The RunestoneServer ``pyproject.toml`` file therefore contains (with all other dependencies removed for clarity):
# This breaks Poetry, since it looks for BOTH dependencies during dependency resolution. To work around this, `rename_pyproject <rename_pyproject>` changes this to:
# ...in production mode; it does the opposite (changes ``[tool.poetry.dependencies]`` to ``[tool.no-poetry.dependencies]``) in development mode. This hides the modified section from Poetry, so the file now looks like an either/or project.
31
+
#
32
+
# #. Poetry doesn't install development dependencies in projects included through a `path dependency <https://python-poetry.org/docs/dependency-specification/#path-dependencies>`_. As a workaround, this script copies development dependencies from a project into an otherwise empty, auto-created "project", but puts them in the production dependencies section of this newly-created "project", so they will be installed. For example, the BookServer ``pyproject.toml`` contains:
33
+
#
34
+
# .. code-block:: text
35
+
#
36
+
# [tool.poetry.dev-dependencies]
37
+
# black = "~= 22.0"
38
+
# console-ctrl = "^0.1.0"
39
+
# ...many more, which are omitted for clarity...
40
+
#
41
+
# Poetry won't install these. Therefore, `make_dev_pyproject <make_dev_pyproject>` creates a "project" named bookserver-dev whose ``pyproject.toml`` contains a copy of the BookServer development dependencies, but placed in the production dependencies section of this ``bookserver-dev`` "project", so they will be installed. For example, the bookserver-dev ``pyproject.toml`` contains:
42
+
#
43
+
# .. code-block:: text
44
+
#
45
+
# [tool.poetry.dependencies] # <== CHANGED!
46
+
# black = "~= 22.0"
47
+
# console-ctrl = "^0.1.0"
48
+
# ...many more, which are omitted for clarity...
49
+
#
50
+
# This also means that the RunestoneServer ``pyproject.toml`` file must be manually edited to include a reference to this "project":
# #. Poetry generates invalid package metadata for local path dependencies, so that running ``pip show click`` results in a bunch of exceptions. This program doesn't provide a fix for this bug.
63
+
#
64
+
# ...and that's how using Poetry makes dependency management easier...
# Per this issue, Poetry generates invalid package metadata for local path dependencies. For example, the last few lines of ``.venv/lib/python3.8/site-packages/runestone_poetry_project-0.1.0.dist-info/METADATA`` contain:
69
+
# Per the issue linked in the title above, Poetry generates invalid package metadata for local path dependencies (tested on Poetry v1.1.14). For example, the last few lines of ``.venv/lib/python3.8/site-packages/runestone_poetry_project-0.1.0.dist-info/METADATA`` contain:
# ... along with a similar fix to the ``METADATA`` for ``bookserver_dev`` allow ``pip`` to run successfully.
109
+
# ... along with a similar fix to the ``METADATA`` for ``bookserver_dev`` allows ``pip`` to run successfully.
49
110
#
50
111
#
51
112
# TODO
@@ -55,11 +116,12 @@
55
116
#
56
117
# Imports
57
118
# =======
58
-
# These are listed in the order prescribed by `PEP 8`_.
119
+
# These are listed in the order prescribed by `PEP 8 <http://www.python.org/dev/peps/pep-0008/#imports>`_.
59
120
#
60
121
# Standard library
61
122
# ----------------
62
123
frompathlibimportPath
124
+
importsys
63
125
fromtypingimportAny, Dict, Set
64
126
65
127
# Third-party imports
@@ -72,7 +134,6 @@
72
134
# -------------------------
73
135
# None.
74
136
#
75
-
#
76
137
# Fix for ``dev-dependencies`` in subprojects
77
138
# ===========================================
78
139
# Given a main Poetry ``pyproject.toml``, these functions look for all subprojects included via path dependencies, creating additional subprojects named ``projectname-dev`` in which the subproject's dev-dependencies become dependencies in the newly-created subproject. This is a workaround for Poetry's inability to install the dev dependencies for a sub project included via a path requirement. To use this, in the main project, do something like:
sys.exit("Error: did not process the BookServer Poetry project.")
248
+
ifnotfound_runestone_components:
249
+
sys.exit("Error: did not process the RunestoneComponents Poetry project.")
168
250
169
251
170
-
# Fix for the main ``pyproject.toml``
171
-
# ===================================
252
+
# .. _rename_pyproject:
253
+
#
254
+
# Workaround for the main ``pyproject.toml``
255
+
# ==========================================
172
256
# This function updates the ``pyproject.toml`` in the current directory by switching between a section named ``[tool.poetry.dev-dependencies]`` when in development mode or ``[tool.no-poetry.dev-dependencies]`` when not in development mode. This is because Poetry does not support either/or dependencies: either resolve dependency x in dev mode, or dependency y when not in dev mode. Instead, it takes a both/and approach: during its dependency resolution phase, it resolves ALL dependencies, then installs a subset (such all non-dev dependencies, or dev and non-dev dependencies). Quoting from the `manual <https://python-poetry.org/docs/master/managing-dependencies/>`_:
173
257
#
174
258
# All dependencies must be compatible with each other across groups since they will be resolved regardless of whether they are required for installation or not (see Installing group dependencies).
0 commit comments