Skip to content
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

wheels created from requests-cache or url-normalize source distributions only contains metadata #384

Closed
benoit-pierre opened this issue Oct 20, 2021 · 29 comments

Comments

@benoit-pierre
Copy link
Member

benoit-pierre commented Oct 20, 2021

▸ wget -q https://files.pythonhosted.org/packages/ec/ea/780a38c99fef750897158c0afb83b979def3b379aaac28b31538d24c4e8f/url-normalize-1.4.3.tar.gz
▸ tar xf url-normalize-1.4.3.tar.gz
▸ cd url-normalize-1.4.3
▸ python -m build --wheel
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (poetry>=0.12)
* Getting dependencies for wheel...
* Building wheel...
Successfully built url_normalize-1.4.3-py2.py3-none-any.whl
▸ unzip -l dist/url_normalize-1.4.3-py2.py3-none-any.whl
Archive:  dist/url_normalize-1.4.3-py2.py3-none-any.whl
  Length      Date    Time    Name
---------  ---------- -----   ----
     1070  1980-01-01 00:00   url_normalize-1.4.3.dist-info/LICENSE
       87  2016-01-01 00:00   url_normalize-1.4.3.dist-info/WHEEL
     3193  2016-01-01 00:00   url_normalize-1.4.3.dist-info/METADATA
      318  2016-01-01 00:00   url_normalize-1.4.3.dist-info/RECORD
---------                     -------
     4668                     4 files

No such issue when using pip:

▸ python -m pip wheel --no-deps url-normalize-1.4.3.tar.gz
Processing ./url-normalize-1.4.3.tar.gz
  File was already downloaded […]/url-normalize-1.4.3.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: url-normalize
  Building wheel for url-normalize (PEP 517) ... done
  Created wheel for url-normalize: filename=url_normalize-1.4.3-py2.py3-none-any.whl size=6814 sha256=aa1858ca9e313314bb73dfcfa148ffb31e8d76fe05a725990731c7f316f632b0
  Stored in directory: […]/.cache/pip/wheels/8d/bb/29/b30564ee9ae6deb89c4aac8cf2e4f27662d9ee69d77ddab992
Successfully built url-normalize
▸ unzip -l url_normalize-1.4.3-py2.py3-none-any.whl
Archive:  url_normalize-1.4.3-py2.py3-none-any.whl
  Length      Date    Time    Name
---------  ---------- -----   ----
     1060  1980-01-01 00:00   url_normalize/__init__.py
     2306  1980-01-01 00:00   url_normalize/tools.py
     6462  1980-01-01 00:00   url_normalize/url_normalize.py
     1070  1980-01-01 00:00   url_normalize-1.4.3.dist-info/LICENSE
       87  2016-01-01 00:00   url_normalize-1.4.3.dist-info/WHEEL
     3193  2016-01-01 00:00   url_normalize-1.4.3.dist-info/METADATA
      566  2016-01-01 00:00   url_normalize-1.4.3.dist-info/RECORD
---------                     -------
    14744                     7 files

build version: 0.7.0.

@henryiii
Copy link
Contributor

henryiii commented Oct 20, 2021

Your SDist is empty. Build does Source -> SDist -> Wheel by default. You probably have an issue with your MANIFEST.in. It would be better to make proper SDists, but you can skip that by explicitly requesting --wheel.

Nevermind, you are already doing that 😳

@benoit-pierre
Copy link
Member Author

Note that if I do build a sdist (python -m build --sdist), it's indeed missing all the Python modules.

@henryiii
Copy link
Contributor

There is nothing inside the tar except raw Python files? No setup.py, pyproject.toml, nothing?

@henryiii
Copy link
Contributor

Ahh, I see the problem. You are cd'ing into the wrong folder. You need to run build from the folder that contains the extra files.

@henryiii
Copy link
Contributor

No, that's what I'm doing, not what you are doing. Just let me shut up until I know what's going on, sorry for the spam....

@benoit-pierre
Copy link
Member Author

Additionally, building a wheel/sdist from a clone of https://github.com/niksite/url-normalize works. But if I move the .git sub-folder out of the way, same issue. Again, pip has no such issue. Which is why I'm assuming it's not a bug with the PEP 517 backend.

@benoit-pierre
Copy link
Member Author

Is there a way to get more verbose/debug information from build?

@henryiii
Copy link
Contributor

Poetry does use git to track what goes in instead of using a MANIFEST.in, so it could very well be a bug in poetry. Though, for me, it's working:

$ wget -q https://files.pythonhosted.org/packages/ec/ea/780a38c99fef750897158c0afb83b979def3b379aaac28b31538d24c4e8f/url-normalize-1.4.3.tar.gz
$ tar xf url-normalize-1.4.3.tar.gz
$ cd url-normalize-1.4.3
$ pipx run build --wheel
$ unzip -l dist/url_normalize-1.4.3-py2.py3-none-any.whl
Archive:  dist/url_normalize-1.4.3-py2.py3-none-any.whl
  Length      Date    Time    Name
---------  ---------- -----   ----
     1060  01-01-1980 00:00   url_normalize/__init__.py
     2306  01-01-1980 00:00   url_normalize/tools.py
     6462  01-01-1980 00:00   url_normalize/url_normalize.py
     1070  01-01-1980 00:00   url_normalize-1.4.3.dist-info/LICENSE
       87  01-01-2016 00:00   url_normalize-1.4.3.dist-info/WHEEL
     3193  01-01-2016 00:00   url_normalize-1.4.3.dist-info/METADATA
      566  01-01-2016 00:00   url_normalize-1.4.3.dist-info/RECORD
---------                     -------
    14744                     7 files

You aren't in a git tracked directory when you are doing this, are you? That will break poetry for sure, as it will assume you are trying to track the contents of the folder you are building.

@benoit-pierre
Copy link
Member Author

There is nothing inside the tar except raw Python files? No setup.py, pyproject.toml, nothing?

▸ tar tvf dist/url-normalize-1.4.3.tar.gz
-rw-r--r-- 0/0            1070 2021-10-20 15:19 url-normalize-1.4.3/LICENSE
-rw-r--r-- 0/0            2136 2021-10-20 15:19 url-normalize-1.4.3/README.md
-rw-r--r-- 0/0            1234 2021-10-20 15:19 url-normalize-1.4.3/pyproject.toml
-rw-r--r-- 0/0            2888 2021-10-20 15:21 url-normalize-1.4.3/setup.py
-rw-r--r-- 0/0            3193 2021-10-20 15:21 url-normalize-1.4.3/PKG-INFO

@benoit-pierre
Copy link
Member Author

My dotfiles are tracked with git. Let me check if that's indeed the issue.

@layday
Copy link
Member

layday commented Oct 20, 2021

Is your git repo inside another git repo? Poetry might be using the outermost repo.

@benoit-pierre
Copy link
Member Author

Yep, that's the issue. That's not great behavior on the part of poetry... Clearly I'm not the only one with this issue: see comments for https://aur.archlinux.org/packages/python-requests-cache and https://aur.archlinux.org/packages/python-url-normalize/.

@benoit-pierre
Copy link
Member Author

benoit-pierre commented Oct 20, 2021

Possible workaround: GIT_CEILING_DIRECTORIES="$PWD/.." python -m build --wheel

In any case, not a build bug. Cheers!

@henryiii
Copy link
Contributor

Or

GIT_CEILING_DIRECTORIES="$PWD/.." python -m build --wheel

;)

@layday
Copy link
Member

layday commented Oct 20, 2021

When this came up before I suggested that Poetry should disable Git detection for sdists, might be worth bringing up on their tracker.

@benoit-pierre
Copy link
Member Author

Damn, yes, I meant with python -m build --wheel of course...

@henryiii
Copy link
Contributor

Part of the problem is that build can't run directly on the SDist. Pip is running directly on the SDist, and therefore is probably expanding the SDist in a temporary directory, so that's why it's working with pip. If we supported similar behavior (#311), then this would have worked from build too.

@benoit-pierre
Copy link
Member Author

But pip wheel . works fine too. Does pip still create a temporary copy? I think that's was removed.

@benoit-pierre
Copy link
Member Author

OK, yes, pip still builds in a temporary copy located in /tmp. I think the plan is to drop that copy in a future version.

@henryiii
Copy link
Contributor

What version of pip are you using? Isn't that in 21.3?

@benoit-pierre
Copy link
Member Author

20.3.4 (the Arch packaged version).

@henryiii
Copy link
Contributor

Okay, if you used 21.3, I think this would affect the pip wheel . usage identically, but not the sdist usage.

@benoit-pierre
Copy link
Member Author

And yep, 21.3 has the same issue.

@henryiii
Copy link
Contributor

That's reassuring, consistency is good. :)

@layday
Copy link
Member

layday commented Oct 20, 2021

Part of the problem is that build can't run directly on the SDist. Pip is running directly on the SDist, and therefore is probably expanding the SDist in a temporary directory, so that's why it's working with pip. If we supported similar behavior (#311), then this would have worked from build too.

Even when build is invoked with --sdist --wheel (or sans args), we're unpacking the sdist in the folder where build is invoked. pip unpacks downloaded sdists in $TMPDIR prior to building a wheel.

(Edited for clarity.)

@carlosal1015
Copy link

Thanks for the explanation @henryiii @benoit-pierre @layday @alex @jezdez . I am the maintainer of both packages on AUR, trying to understand how to fix the installation for everyone, thanks for the help.

@henryiii
Copy link
Contributor

If we support running directly on <file>.tar.gz, that likely will be in the tmp folder, since there isn't a package dir in that case. (I'm also a fan of using tmp for everything, using a subfolder causes issues, including this one. Scikit-build uses a local folder and it's a constant headache, but kind of necessary for incremental builds. But doesn't mean I like it).

@layday
Copy link
Member

layday commented Oct 20, 2021

It can be next to the tarfile ;)

@henryiii
Copy link
Contributor

There's a difference between "can" and "should". ;)

archlinux-github pushed a commit to archlinux/aur that referenced this issue Dec 16, 2022
* Change to use the python-{build,installer,wheel} utilities as specified
in [0].
* Use python package naming convention as specified in [0].
* Fix build error from poetry when nested git directories [1].

[0]: https://wiki.archlinux.org/title/Python_package_guidelines
[1]: pypa/build#384
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants