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

Build fails to build the voila project: TypeError: expected string or bytes-like object #558

Open
yurivict opened this issue Dec 29, 2022 · 9 comments

Comments

@yurivict
Copy link

yurivict commented Dec 29, 2022

voila

===>  Building for py39-voila-0.4.0
* Getting build dependencies for wheel...

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/build/__main__.py", line 373, in main
    built = build_call(
  File "/usr/local/lib/python3.9/site-packages/build/__main__.py", line 206, in build_package
    out = _build(isolation, builder, outdir, distribution, config_settings, skip_dependency_check)
  File "/usr/local/lib/python3.9/site-packages/build/__main__.py", line 145, in _build
    return _build_in_current_env(builder, outdir, distribution, config_settings, skip_dependency_check)
  File "/usr/local/lib/python3.9/site-packages/build/__main__.py", line 125, in _build_in_current_env
    missing = builder.check_dependencies(distribution)
  File "/usr/local/lib/python3.9/site-packages/build/__init__.py", line 396, in check_dependencies
    return {u for d in dependencies for u in check_dependency(d)}
  File "/usr/local/lib/python3.9/site-packages/build/__init__.py", line 396, in <setcomp>
    return {u for d in dependencies for u in check_dependency(d)}
  File "/usr/local/lib/python3.9/site-packages/build/__init__.py", line 202, in check_dependency
    if req.specifier and not req.specifier.contains(dist.version, prereleases=True):
  File "/usr/local/lib/python3.9/site-packages/packaging/specifiers.py", line 728, in contains
    item = parse(item)
  File "/usr/local/lib/python3.9/site-packages/packaging/version.py", line 49, in parse
    return Version(version)
  File "/usr/local/lib/python3.9/site-packages/packaging/version.py", line 264, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

ERROR expected string or bytes-like object
*** Error code 1

The command is:

cd /usr/ports/devel/py-voila/work-py39/voila-0.4.0 && /usr/bin/env XDG_DATA_HOME=/usr/ports/devel/py-voila/work-py39 XDG_CONFIG_HOME=/usr/ports/devel/py-voila/work-py39 XDG_CACHE_HOME=/usr/ports/devel/py-voila/work-py39/.cache HOME=/usr/ports/devel/py-voila/work-py39 PATH=/usr/local/libexec/ccache:/usr/ports/devel/py-voila/work-py39/.bin:/home/yuri/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin PKG_CONFIG_LIBDIR=/usr/ports/devel/py-voila/work-py39/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing " CPP="cpp" CPPFLAGS="-isystem /usr/local/include" LDFLAGS=" -fstack-protector-strong " LIBS="-L/usr/local/lib" CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include " MANPREFIX="/usr/local" CCACHE_DIR="/tmp/.ccache" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" /usr/local/bin/python3.9 -m build --wheel --no-isolation --outdir /usr/ports/devel/py-voila/work-py39

Version: 0.9.0, 0.8.0
Python-3.9
FreeBSD 13.1

@layday
Copy link
Member

layday commented Dec 29, 2022

I assume that the version returned by importlib.metadata.distribution.version for one of your installed packages is not a string. That would be the case if e.g. the version was missing from the metadata, then it would be None. The Version is required by Core Metadata; metadata without a Version field are invalid.

@yurivict
Copy link
Author

The version returned for one of the packages (hackling) in None.
And what to do in such case?

@layday
Copy link
Member

layday commented Dec 29, 2022

Figure out why that is :)

How did you build hatchling? Do you post-process the metadata at all?

@layday
Copy link
Member

layday commented Dec 29, 2022

cc @ofek

@yurivict
Copy link
Author

I installed py39-hatchling from the FreeBSD package.
I tried to rebuild it itself with build/install. This succeeded, but the resulting package has exactly the same problem.
By looking at the metadata I can't see that anything is obviously wrong or missing.
The version is listed there.

@layday
Copy link
Member

layday commented Dec 29, 2022

I think you are gonna face the same issue with all of viola's build dependencies - hatchling just so happens to be the first one to be checked. Looking at the contents of the FreeBSD py39-hatchling package, the FreeBSD folks are using old-style egg-info folders with a custom Python version suffix that importlib.metadata does not recognise. I suppose that importlib.metadata falls back on reading the egg-info folder as a file then suppresses a whole host of errors only to have the version bubble up as None.

@yurivict
Copy link
Author

But the new style package using build/install has the same problem.
And why does hatchling have this problem, and not other packages?

@layday
Copy link
Member

layday commented Dec 29, 2022

Are you sure that it's only hatchling that's affected? Have you tried commenting out hatchling in viola's pyproject.toml?

@henryiii
Copy link
Contributor

henryiii commented Dec 30, 2022

FYI, while this is probably something you should still hunt down and fix, but for packaging for distros, you'll very likely eventually need to add --skip-dependency-check when building. Users will sometime pin versions like setuptools and numpy exactly, which distro packaging can't and shouldn't require - the reason for pinning numpy (via oldest-supported-numpy) is specific to environments with multiple numpy versions is invalid for distro packaging. Also packages may add things like cmake and ninja, which are only required if those CLI tools are not present, and your distro packaging shouldn't be required to ship the Python wrapper. And so on.

(see my comment at #557 (comment))

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

3 participants