[ISSUE] Broken xbps-src builds as a result of pycompile and python_version behavior changes

[ISSUE] Broken xbps-src builds as a result of pycompile and python_version behavior changes

[ahesford]

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

New issue by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/21323

Description:
The move to drop the default `python_version=2` in favor of no default, in combination with the move to derive the `pycompile_version` value from `python_version`, has broken builds that declare `pycompile_dirs` without `python_version`.

The hook `common/hooks/post-install/04-create-xbps-metadata-scripts.sh` tries to discover the `pycompile_version` from the existence of `usr/lib/pythonX.Y`. However, this directory will not exist if a package installs Python code somewhere else. In these cases, when `pycompile_dirs` is nonempty by `python_version` is not set, the hook will fail.

The fix involves:
1. Finding the list of packages that declare `pycompile_dirs`;
2. Eliminating from the list those packages that also declare `python_version`;
3. Further eliminating those packages that install files into `usr/lib/pythonX.Y` for any version `X.Y`; and
4. Manually adding `python_version=2` to the remaining templates. This will restore prior build behavior for those packages.

I will dig into this as soon as I have time. In the meantime, please merge as many reasonable PRs that add explicit `python_version` to individual templates as possible to avoid duplicate PRs and potential merge conflicts.

Re: Broken xbps-src builds as a result of pycompile and python_version behavior changes

[Chocimier]

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

New comment by Chocimier on void-packages repository

https://github.com/void-linux/void-packages/issues/21323#issuecomment-619332893

Comment:
> tries to discover the pycompile_version from the existence of usr/lib/pythonX.Y

Note, this only works when there is exactly one `X.Y`.

Re: Broken xbps-src builds as a result of pycompile and python_version behavior changes

[ahesford]

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

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/21323#issuecomment-619366727

Comment:
> > tries to discover the pycompile_version from the existence of usr/lib/pythonX.Y
> 
> Note, this only works when there is exactly one `X.Y`.

Right. This is also true in `common/hooks/pre-pkg/03-rewrite-python-shebang.sh`. I think this is proper behavior; trying to decide what to do when a package created two Python libdirs is prone to error. Let the template specifically list `python_version` in those ambiguous cases.

Re: [ISSUE] [CLOSED] Broken xbps-src builds as a result of pycompile and python_version behavior changes

[Chocimier]

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

Closed issue by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/21323

Description:
The move to drop the default `python_version=2` in favor of no default, in combination with the move to derive the `pycompile_version` value from `python_version`, has broken builds that declare `pycompile_dirs` without `python_version`.

The hook `common/hooks/post-install/04-create-xbps-metadata-scripts.sh` tries to discover the `pycompile_version` from the existence of `usr/lib/pythonX.Y`. However, this directory will not exist if a package installs Python code somewhere else. In these cases, when `pycompile_dirs` is nonempty by `python_version` is not set, the hook will fail.

The fix involves:
1. Finding the list of packages that declare `pycompile_dirs`;
2. Eliminating from the list those packages that also declare `python_version`;
3. Further eliminating those packages that install files into `usr/lib/pythonX.Y` for any version `X.Y`; and
4. Manually adding `python_version=2` to the remaining templates. This will restore prior build behavior for those packages.

I will dig into this as soon as I have time. In the meantime, please merge as many reasonable PRs that add explicit `python_version` to individual templates as possible to avoid duplicate PRs and potential merge conflicts.