Odd package extraction (hexdump)
Closed this issue · 1 comments
On installation, downloaded source archive is extracted into __pypackages__/3.9/ instead of expected __pypackages__/3.9/hexdump-3.3/
Perhaps this is due to hexdump being an old package?
Environment:
pyflow 0.3.1 installed via homebrew
Python 3.9.7 installed via homebrew
Mac OS 11.6
To replicate:
> pyflow new test
Select Python 3.9.7 installation
> cd test
> pyflow install hexdump
Get errors:
Problem opening the tar.gz archive: File { fd: 4, path: "/Users/scottcandey/Library/Application Support/pyflow/dependency-cache/hexdump-3.3.zip", read: true, write: false }: Custom { kind: InvalidInput, error: "invalid gzip header" }, checking if it's a zip...
Can't find setup.py in this source distributionpath: "/Users/scottcandey/Desktop/test/__pypackages__/3.9/lib/hexdump-3.3/setup.py". This could mean there are no suitable wheels for this package,and there's a problem with its setup.py.
> ls __pypackages__/3.9/lib/
Get results:
PKG-INFO README.txt __main__.py data hexdump.py setup.py
Since hexdump does not have a proper wheel, pip has to generate one on installation. (The only change strictly required from that .zip to .whl is moving the files from the top level zipfile to a new directory with the same name.)
I'm not sure how pip / pipenv / poetry implemented this functionality, but this seems like a important feature to include in pyflow as well. I went through the wheel / extract_zip function, but I'm not well versed enough in rust to implement an explicit check of the file structure and then generating the proper wheel if not.