Request for merging "python-team" branch

Request for merging "python-team" branch

[Sharlatan Hellseher]

[-- Attachment #1: Type: text/plain, Size: 34 bytes --]


CC Python team for wider spread.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: bug#74715: Request for merging "python-team" branch

[Ludovic Courtès]

Hey there,

https://qa.guix.gnu.org/ says it’s your turn to merge!  :-)

Ludo’.

Re: bug#74715: Request for merging "python-team" branch

[jgart]

[-- Attachment #1: Type: text/plain, Size: 79 bytes --]

Hi Sharlatan,

Guix cheerleader here. Go for it! Merge ahoy!
🦜🦆
 LGTM

[-- Attachment #2: Type: text/html, Size: 297 bytes --]

Re: bug#74715: Request for merging "python-team" branch

[Ian Eure]

[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]

Hi all,

Since this merge landed, the builds for several Python packages in my personal channel broke.  Any package using pyproject-build-system for a Python project using setuptools seems to be affected.  This python-manhole package[1] is an example.  It's  about as simple as they can get, with no inputs or custom build steps.  It's failing with:

------------------------------------------------------------
starting phase `build'
Using 'setuptools.build_meta' to build wheels, auto-detected '#f', override '#f'.
Prepending '[]' to sys.path, auto-detected '#f', override '#f'.
Traceback (most recent call last):
  File "<string>", line 6, in <module>
  File "/gnu/store/jjcka1g6sk2cvwx8nm4fdwpdq3vll0v0-python-3.10.7/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'setuptools'
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "python" arguments: ("-c" "import sys, importlib, json\nbackend_path = json.loads (sys.argv[1]) or []\nbackend_path.extend (sys.path)\nsys.path = backend_path\nconfig_settings = json.loads (sys.argv[4])\nbuilder = importlib.import_module(sys.argv[2])\nbuilder.build_wheel(sys.argv[3], config_settings=config_settings)" "[]" "setuptools.build_meta" "dist" "{}") exit-status: 1 term-signal: #f stop-signal: #f> 
phase `build' failed after 0.0 seconds
command "python" "-c" "import sys, importlib, json\nbackend_path = json.loads (sys.argv[1]) or []\nbackend_path.extend (sys.path)\nsys.path = backend_path\nconfig_settings = json.loads (sys.argv[4])\nbuilder = importlib.import_module(sys.argv[2])\nbuilder.build_wheel(sys.argv[3], config_settings=config_settings)" "[]" "setuptools.build_meta" "dist" "{}" failed with status 1
build process 10 exited with status 256
------------------------------------------------------------

Since it's complaining about setuptools, I thought I might need to add that to the native-inputs.  Alas, that fails with a different error:

------------------------------------------------------------
starting phase `build'
Using 'setuptools.build_meta' to build wheels, auto-detected '#f', override '#f'.
Prepending '[]' to sys.path, auto-detected '#f', override '#f'.
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: -c --help [cmd1 cmd2 ...]
   or: -c --help-commands
   or: -c cmd --help

error: invalid command 'bdist_wheel'
------------------------------------------------------------

Is there somewhere I can find out how to fix these packages for the updated pyproject-build-system?  Should they be getting switched to python-build-system?

Noting also that the PyPI module for `guix import' hardcodes the pyproject-build-system, so it will generate unbuildable definitions for any Python project which uses setuptools.

Thanks,

  -- Ian

[1]: https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/packages/python-xyz.scm#L22

On Fri, Dec 13, 2024, at 5:00 PM, jgart wrote:
> Hi Sharlatan,
> 
> Guix cheerleader here. Go for it! Merge ahoy!
> 🦜🦆
> LGTM
> 
> 

[-- Attachment #2: Type: text/html, Size: 5834 bytes --]

Re: bug#74715: Request for merging "python-team" branch

[Kaelyn via Development of GNU Guix and the GNU System distribution.]

Hi Ian,

On Saturday, December 14th, 2024 at 5:00 PM, Ian Eure <ian@retrospec.tv> wrote:

> Hi all,
> 
> Since this merge landed, the builds for several Python packages in my personal channel broke.  Any package using pyproject-build-system for a Python project using setuptools seems to be affected.  This python-manhole package[1] is an example.  It's  about as simple as they can get, with no inputs or custom build steps.  It's failing with:
> 
> ------------------------------------------------------------
> starting phase `build'
> Using 'setuptools.build_meta' to build wheels, auto-detected '#f', override '#f'.
> Prepending '[]' to sys.path, auto-detected '#f', override '#f'.
> Traceback (most recent call last):
>   File "<string>", line 6, in <module>
>   File "/gnu/store/jjcka1g6sk2cvwx8nm4fdwpdq3vll0v0-python-3.10.7/lib/python3.10/importlib/__init__.py", line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
>   File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
>   File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
>   File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
>   File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
>   File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'setuptools'
> error: in phase 'build': uncaught exception:
> %exception #<&invoke-error program: "python" arguments: ("-c" "import sys, importlib, json\nbackend_path = json.loads (sys.argv[1]) or []\nbackend_path.extend (sys.path)\nsys.path = backend_path\nconfig_settings = json.loads (sys.argv[4])\nbuilder = importlib.import_module(sys.argv[2])\nbuilder.build_wheel(sys.argv[3], config_settings=config_settings)" "[]" "setuptools.build_meta" "dist" "{}") exit-status: 1 term-signal: #f stop-signal: #f> 
> phase `build' failed after 0.0 seconds
> command "python" "-c" "import sys, importlib, json\nbackend_path = json.loads (sys.argv[1]) or []\nbackend_path.extend (sys.path)\nsys.path = backend_path\nconfig_settings = json.loads (sys.argv[4])\nbuilder = importlib.import_module(sys.argv[2])\nbuilder.build_wheel(sys.argv[3], config_settings=config_settings)" "[]" "setuptools.build_meta" "dist" "{}" failed with status 1
> build process 10 exited with status 256
> ------------------------------------------------------------
> 
> Since it's complaining about setuptools, I thought I might need to add that to the native-inputs.  Alas, that fails with a different error:
> 
> ------------------------------------------------------------
> starting phase `build'
> Using 'setuptools.build_meta' to build wheels, auto-detected '#f', override '#f'.
> Prepending '[]' to sys.path, auto-detected '#f', override '#f'.
> usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>    or: -c --help [cmd1 cmd2 ...]
>    or: -c --help-commands
>    or: -c cmd --help
> 
> error: invalid command 'bdist_wheel'
> ------------------------------------------------------------

I don't have any comment about the pyproject-build-system issue in general, but I've done enough maintenance of Python packages in general to be familiar with this error. It should be as simple as adding `python-wheel` to the native-inputs--it is the module that allows setuptools to generate .whl files, and I'd be surprised if additional packages were needed (I've encountered having to add explicit setuptools and wheel dependencies to requirements.txt files for pip when changing the build environment of packages such as changing distros or Python versions). HTH!

Cheers,
Kaelyn

> Is there somewhere I can find out how to fix these packages for the updated pyproject-build-system?  Should they be getting switched to python-build-system?
> 
> Noting also that the PyPI module for `guix import' hardcodes the pyproject-build-system, so it will generate unbuildable definitions for any Python project which uses setuptools.
> 
> Thanks,
> 
>   -- Ian
> 
> [1]: https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/packages/python-xyz.scm#L22
> 
> On Fri, Dec 13, 2024, at 5:00 PM, jgart wrote:
> 
> > Hi Sharlatan,
> > 
> > Guix cheerleader here. Go for it! Merge ahoy!
> > 🦜🦆
> > LGTM
> > 
> > 
> 
>

Re: bug#74715: Request for merging "python-team" branch

[Lars-Dominik Braun]

Hi Ian,

> Since this merge landed, the builds for several Python packages in my personal channel broke.  Any package using pyproject-build-system for a Python project using setuptools seems to be affected.

as Sharlatan Hellseher wrote in https://issues.guix.gnu.org/issue/74715#4,
you need to add python-setuptools and python-wheel to your
setuptools-based packages. The default python toolchain used by
pyproject-build-system (python-sans-pip-wrapper from
gnu/packages/python.scm) does not include these packages any more,
since they are technically not required and declaring them as *real*
inputs allows using different versions of these packages more easily
for packages, which require them. Plus there are quite a few packages,
which build using different build systems nowadays.

The python importer should probably be updated to read pyproject.toml
and parse the [build-system] table (there is a toml parser in Guix now,
so this should be easy).

Lars