-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poetry tries to remove setuptools and then complains it can't find it #4242
Comments
Can reproduce on windows and linux: poetry 1.2.0a1 generates a lock file that, when installed, sometimes, removes setuptools and makes some packages fail to install. |
Does editing your [build-system]
-requires = ["poetry_core>=1.0"]
+requires = ["setuptools", "poetry_core>=1.0"]
build-backend = "poetry.core.masonry.api" |
The delta between diff --git a/poetry.lock b/poetry.lock
index dc6b6820f..f0e8e3fdd 100644
--- a/poetry.lock
+++ b/poetry.lock
@@ -499,7 +499,6 @@
pickleshare = "*"
prompt-toolkit = ">=2.0.0,<3.0.0 || >3.0.0,<3.0.1 || >3.0.1,<3.1.0"
pygments = "*"
-setuptools = ">=18.5"
traitlets = ">=4.2"
[package.extras]
@@ -1020,18 +1019,6 @@
-[[package]]
-name = "setuptools"
-version = "57.4.0"
-description = "Easily download, build, install, upgrade, and uninstall Python packages"
-category = "dev"
-optional = false
-python-versions = ">=3.6"
-
-[package.extras]
-docs = ["sphinx", "jaraco.packaging (>=8.2)", "rst.linker (>=1.9)", "jaraco.tidelift (>=1.4)", "pygments-github-lexers (==0.0.5)", "sphinx-inline-tabs", "sphinxcontrib-towncrier", "furo"]
-testing = ["pytest (>=4.6)", "pytest-checkdocs (>=2.4)", "pytest-flake8", "pytest-cov", "pytest-enabler (>=1.0.1)", "mock", "flake8-2020", "virtualenv (>=13.0.0)", "pytest-virtualenv (>=1.2.7)", "wheel", "paver", "pip (>=19.1)", "jaraco.envs", "pytest-xdist", "sphinx", "jaraco.path (>=3.2.0)", "pytest-black (>=0.3.7)", "pytest-mypy"]
-
@@ -1082,7 +1069,6 @@
packaging = "*"
Pygments = ">=2.0"
requests = ">=2.0.0"
-setuptools = "*"
six = ">=1.5"
snowballstemmer = ">=1.1"
sphinxcontrib-websupport = "*"
@@ -1994,10 +1980,6 @@
-setuptools = [
- {file = "setuptools-57.4.0-py3-none-any.whl", hash = "sha256:a49230977aa6cfb9d933614d2f7b79036e9945c4cdd7583163f4e920b83418d6"},
- {file = "setuptools-57.4.0.tar.gz", hash = "sha256:6bac238ffdf24e8806c61440e755192470352850f3419a52f26ffe0a1a64f465"},
-]
six = [
{file = "six-1.15.0-py2.py3-none-any.whl", hash = "sha256:8b74bedcbbbaca38ff6d7491d76f2b06b3592611af620f8426e82dddb04a5ced"},
{file = "six-1.15.0.tar.gz", hash = "sha256:30639c035cdb23534cd4aa2dd52c3bf48f06e5f4a941509c8bafd8ce11080259"}, In other words, I guess that |
So the only issue here is that an older poetry cannot read a lock file generated by the newer version? If that is the case then I think this is expected behavior. |
Breaking backwards compatibility in a minor release is not the best experience. Is there really no way to make any required changes in a way that it doesn't lead to mysterious breakage on earlier versions? |
I don't think so. In this special case it was actually a bug fix (1.1 was broken in the sense that it did not properly record setuptools in the lockfile). There is really no good way that an old version could ever cope with that I think. |
Sorry for the late reply about this. I think that fixed my issues before, but with 1.2.0 -> 1.1.x it does not fix the issue. But |
The See also #2789.
As you identify, since a project in your tree requires setuptools and that is not enabled for the platform, Additionally, changes in #3835 should now mean that I'd recommend you try using poetry from |
I'm on poetry 1.1.12 |
For me having explicit dependency on It completely breaks our Cython builds. |
I have the same problem as well that trying to slowly write my poetry plugins, but this issue with incompatibility between 1.1 and 1.2 would not allow me to use 1.2 and plugins. |
I've just bitten the bullet and tested 1.2.0b1 and wholly moved over to it - gambling a bit but half way house between the two isn't feasible any more. Especially with the |
I am going to close this as it seems this will be resolved in 1.2 and is already on mater. |
In case anyone are looking for a workaround to make a curl https://gist.githubusercontent.com/emilhe/0c7b1a33b2d02f17331242bf4fffd07c/raw/8da0665a58f469c980e7661d7f8c36f3bd3af992/strip_setuptools.py | python - && poetry install In my case, I needed it because I am using Poetry |
In my case the issue is reproduced using
Which when a another colleague (or our CI) runs
|
* refactor github action to perform linting before testing and use a typical poetry installation workflow * fix syntax errors in github action config * reformatted files with black * reorganized imports with isort * ignore swap files so we don't accidentally commit them * create user group, add python executables to path, and upgrade pip. I changed the default CMD to 'bash' because 'poetry shell' wasn't working and I couldn't figure out why... * simplify github workflow into just one job there's no reason to separate concerns between linting and testing now, plus I didn't want to have repetetitive jobs (although I could eventually templatize the setup steps) * changed to an available python version on github runners * workaround bug in snok/install-poetry action that gives 'poetry: command not found' for the latest version (1.2.0) * went back to poetry 1.2.0 but added ~/.local/bin to the system path in the github action the reason for this reversion is described in more detail here: python-poetry/poetry#4242 essentially there isn't backwards compatibility with 1.2.0 lock files and old poetry versions (like the 1.1.14 I switched it to before in the github action), and it couldn't find 'setuptools' because of this * explicitly list directory, maybe because /home/tristan isn't resolved correctly? * update poetry in dev dockerfile, lock updates with this new version, and upgrade the poetry-core version for building these were recommended from the issue with the snok/install-poetry github action documented at snok/install-poetry#89 * add path logging so i can figure out what's going on in the github action * add env variable to hopefully prevent issues with upgrade * maybe this is caused by 3.6 being deprecated? comments in the previously linked issue suggested this could be why * run linting and testing steps in the github action job in a poetry shell otherwise, the job will fail because the tools are libraries aren't actually available in the environment * poetry run wasn't accepted by github as valid for the 'shell' field so I added a bash -c to see if that works * that didn't work either so calling poetry run on every command separately * fix spacing in run command * remove 3.10 runtime because I realized I didn't actually test this works * take out pointless echos and exclude poetry .venv from flake8 linting because otherwise it will lint dependency source files we have no control over * fix a bunch of linting errors * reformat files and fix a couple remaining linting errors * make isort compatible with black so they don't keep reformatting endlessly -- had to sacrifice some comments because I couldn't figure out how to get it to work without this (will try later) * fix recursive import by importing tqdm modules from the library directly * fix permissions on parent directory of the devcontainer's working directory to allow for the unit testing module to download some testing data from https://github.com/pyrfume/pyrfume-data * add back the line that I thought was a pointless import but actually has relevant logic... * fix last lingering linting error, left as a TODO * drop support for python 3.6 (not even tested in actions and losing support anyways soon) to upgrade pandas to a compatible version so that tests fully pass * remove macos runtime because for some reason it can't install public files from api.github.com/repos, even though I tested the same install locally on macOS with all of the failing python versions * don't fail fast so we can see the results of runs on all python distributions. also I reincluded macos just to see how far they get
Looks like this is not needed. This will allow to workaround some problems with build tools like this one python-poetry/poetry#4242
Looks like this is not needed. This will allow to workaround some problems with build tools like this one python-poetry/poetry#4242
Looks like this is not needed. This will allow to workaround some problems with build tools like this one python-poetry/poetry#4242
I still have this problem on 1.2.x |
`poetry install` removes untracked packages by default in 1.3, among them setuptools. This causes all subsequent Python invocations (including the one poetry uses to get the system tags from a virtual environment) to fail with e.g. ``` Error processing line 1 of /opt/homebrew/Caskroom/miniforge/base/envs/test/lib/python3.10/site-packages/distutils-precedence.pth: Traceback (most recent call last): File "/opt/homebrew/Caskroom/miniforge/base/envs/test/lib/python3.10/site.py", line 186, in addpackage exec(line) File "<string>", line 1, in <module> ModuleNotFoundError: No module named '_distutils_hack' ``` As a workaround, make setuptools an explicit dev dependency so `poetry install` works by default. This is similar, but possibly not identical, to python-poetry/poetry#4242
Having same or similar issue with Poetry (version 1.3.2)
And I'm also wondering why pip is trying to reach "pypi.org" although I've defined a private index...
|
I found the related topic: #3249 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
-vvv
option).Issue
When running
poetry install
, Poetry tries to removesetuptools
, and then later complains that setuptools is not found when trying to installfuture
.I suspect this may be because
win10toast
depends on setuptools, but that package is skipped due to the platform not being Windows.To clarify: Running
poetry lock
from Poetry 1.2.0a1 seems to cause the lock file to include setuptools, which triggers the issue with Poetry <= 1.1.7. Runningpoetry lock
from Poetry 1.1.7 makes it exclude setuptools and there is no issue.Also, both lock files were generated on Linux. I have not tested on Windows yet.
The text was updated successfully, but these errors were encountered: