-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
- I am on the latest Poetry version.
- I have searched the issues of this repo and believe that this is not a duplicate.
Closest issue I found to this is #4800.
- OS version and name: CentOS 7 (not relevant to this issue)
- Poetry version: Poetry-core-1.0.8 and 1.1.0a7
Issue
I'm trying to package up poetry-core-1.0.8 at work but when building it I end up with an empty install (apart for some metadata).
private/dist/
└── python_poetry_core-1.0.8
├── lib
│ └── python3.7
│ └── site-packages
│ └── poetry_core-1.0.8.dist-info
│ ├── LICENSE
│ ├── METADATA
│ ├── RECORD
└── └── WHEELAt work we are using a proprietary package manager, closest open source equivalent would probably be rez.
Each recipe to build a package is its own git repo, which we call a port. The source of a package is extracted to a subdirectory called private/build then the resulting artifact is installed to another subdirectory private/dist which then can be installed to its final destination. To keep the repo clean we list private in .gitignore.
I did some code spelunking in the source code for poetry-core and discovered that the issue is how it uses the VCS's ignore list (.gitignore for git) to pre-seed the exclude field. Since I'm downloading the release tarball, the source code does not contain any VCS info. But given that the tarball is extracted in a subdirectory (private/build) of the port which is a git repo, poetry-core picks up the .gitignore from that. And as stated earlier that ignores the whole source directory.
I patched the get_vcs(…) function to check that the path returned by git is located inside the directory given to get_vcs. And that seems to fix my issue:
diff -urB a/poetry/core/vcs/__init__.py b/poetry/core/vcs/__init__.py
--- a/poetry/core/vcs/__init__.py 2022-02-27 20:15:29.000000000 -0800
+++ b/poetry/core/vcs/__init__.py 2022-05-05 10:26:37.248645073 -0700
@@ -20,7 +20,7 @@
)
).strip()
- vcs = Git(Path(git_dir))
+ vcs = Git(Path(git_dir)) if git_dir.startswith(str(directory.resolve())) else None
except (subprocess.CalledProcessError, OSError, RuntimeError):
vcs = None
But I have very little knowledge of the code so this might not be the desired fix.
Repro
Using guix (with commit f49b1a10f3d13ee9597b8ef230828606f7cac99f if you want to reproduce the exact environment)
Here follows the commands to reproduce my issue. Note that guix isn't necessary if you have all the dependencies needed to build poetry-core
guix shell -D python-poetry-core python-pypa-build unzip git wget --pure -E LANG
mkdir /tmp/poetry-core-port
cd /tmp/poetry-core-port
git init
echo private > .gitignore
wget https://github.com/python-poetry/poetry-core/archive/refs/tags/1.0.8.tar.gz
mkdir -p private/build
tar -xf /tmp/poetry-core-port/1.0.8.tar.gz -C private/build
cd private/build/poetry-core-1.0.8
python -m build -wn
unzip -l dist/poetry_core-1.0.8-py2.py3-none-any.whlOr as a oneliner:
guix shell -D python-poetry-core python-pypa-build unzip git wget --pure -- sh -c "mkdir /tmp/poetry-core-port && cd /tmp/poetry-core-port && git init && echo private > .gitignore && wget https://github.com/python-poetry/poetry-core/archive/refs/tags/1.0.8.tar.gz && mkdir -p private/build && tar -xf /tmp/poetry-core-port/1.0.8.tar.gz -C private/build && cd private/build/poetry-core-1.0.8 && python -m build -wn && unzip -l dist/poetry_core-1.0.8-py2.py3-none-any.whl"The last output will be:
Archive: dist/poetry_core-1.0.8-py2.py3-none-any.whl
Length Date Time Name
--------- ---------- ----- ----
1062 01-01-1980 00:00 poetry_core-1.0.8.dist-info/LICENSE
87 01-01-2016 00:00 poetry_core-1.0.8.dist-info/WHEEL
4107 01-01-2016 00:00 poetry_core-1.0.8.dist-info/METADATA
310 01-01-2016 00:00 poetry_core-1.0.8.dist-info/RECORD
--------- -------
5566 4 files
If you remove git from the environment it will successfully package up all files.
I have also tested this with poetry-core-1.1.0a7 and that exhibits the same issue.