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
Currently, mitosis checks to see that the current working directory, if under git version control, is dirty (uncommitted changes). It also logs the commit hash of the current repo. This assumes a project organization where the experimental package and no others is installed in editable mode, because installed editable packages under setuptools_scm use the version number at the time of install.
However, there's no reason to assume that (a) mitosis is called from within the relevant git repo, and (b) no reason to assume that only one repo is installed in editable mode.
Install metadata in site-packages/<package.version>.dist-info/direct-url.json includes the value {editable: True} (PEP 660/610). But since packages and installers have multiple ways of installing packages, I'm not sure how to reliably get that file without assumptions. There's been discussions back and forth about whether this will end up on packaging or importlib.metadata, but it looks like the latter. See:
Currently,
mitosis
checks to see that the current working directory, if under git version control, is dirty (uncommitted changes). It also logs the commit hash of the current repo. This assumes a project organization where the experimental package and no others is installed in editable mode, because installed editable packages under setuptools_scm use the version number at the time of install.However, there's no reason to assume that (a)
mitosis
is called from within the relevant git repo, and (b) no reason to assume that only one repo is installed in editable mode.Install metadata in site-packages/<package.version>.dist-info/direct-url.json includes the value
{editable: True}
(PEP 660/610). But since packages and installers have multiple ways of installing packages, I'm not sure how to reliably get that file without assumptions. There's been discussions back and forth about whether this will end up on packaging or importlib.metadata, but it looks like the latter. See:CPython PR, importlib_metadata backport PR
Once the latter of those PRs is merged, I can add this feature. I don't want to add a hacky workaround just to fix it in a few months.
The text was updated successfully, but these errors were encountered: