Bug 2023561

Summary: Paths with curly brackets (e.g. cookiecutter dirs) break `%pyproject_save_files`
Product: [Fedora] Fedora Reporter: Maxwell G <maxwell>
Component: pyproject-rpm-macrosAssignee: Miro Hrončok <mhroncok>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 35CC: mhroncok, pviktori, python-sig, ssbarnea, torsava
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-07 10:56:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Maxwell G 2021-11-16 03:25:54 UTC
Description of problem:
I am attempting to convert `python-molecule` to use the new Python macros. However, Molecule uses Cookiecutter and contains directory names that include curly brackets. One example is `src/molecule/cookiecutter/molecule/{{cookiecutter.role_name}}`. This breaks `%pyproject_save_files`.

Version-Release number of selected component (if applicable):
pyproject-rpm-macros-0-49.fc35.noarch

How reproducible:
Use the pypyproject macros to build a project that includes file paths that contain curly brackets. Here[1.2] is a link to a WIP specfile and a Copr build for the aforementioned `python-molecule` package. I have not yet finalized the specfile, but if you notice any glaring errors, feel free to let me know😀.

Steps to Reproduce:
1.Run `fedpkg --release f35 mockbuild --no-cleanup-after` or`mock -Nnr fedora-35-x86_64 *fc35.src.rpm`, or see the Copr build that I linked.


Expected results:
Package to build successfully


Actual results:
```
RPM build errors:
    File not found: /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/conftest.cpython-310{,.opt-?}.pyc
    File not found: /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/test_default.cpython-310{,.opt-?}.pyc
```

I confirmed that those files actually exist.

``` console
$ mock -Nnr fedora-35-x86_64 --shell 'ls -al /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/conftest.cpython-310{,.opt-?}.pyc /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/test_default.cpython-310{,.opt-?}.py'

[...]

-rw-r--r--. 2 mockbuild mock 958 Nov 15 20:45 /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/conftest.cpython-310.opt-1.pyc
-rw-r--r--. 2 mockbuild mock 958 Nov 15 20:45 /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/conftest.cpython-310.pyc
-rw-r--r--. 1 mockbuild mock 510 Nov 15 20:45 /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/test_default.cpython-310.opt-1.pyc
-rw-r--r--. 1 mockbuild mock 581 Nov 15 20:45 /builddir/build/BUILDROOT/python-molecule-3.5.2-1.fc35.x86_64/usr/lib/python3.10/site-packages/molecule/cookiecutter/scenario/verifier/testinfra/{{cookiecutter.molecule_directory}}/{{cookiecutter.scenario_name}}/{{cookiecutter.verifier_directory}}/__pycache__/test_default.cpython-310.pyc
```

[1]: https://copr.fedorainfracloud.org/coprs/gotmax23/gotmax23_copr/build/2935177/
[2]: https://download.copr.fedorainfracloud.org/results/gotmax23/gotmax23_copr/fedora-35-x86_64/02935177-python-molecule/python-molecule.spec

Comment 1 Miro Hrončok 2021-11-16 09:34:43 UTC
Yes, this is another form of bz1990879 (may I merge the two problems into a single bugzilla, i.e. mark this as a duplicate and edit the summary of that one?).

Unfortunately, there seems to be no way to escape the {} shell-glob symbols in a path with another shell-glob in the %files section and hence we cannot include this path in the file list.

One workaround might be to replace the {} symbols with question marks, but that could lead to unexpected problems (it could math other paths).

Another possible workaround is to examine the directory containing weird paths and include it entirely if all the files within are also included (which is a bit tricky but possible). The problem with this approach is that it might not always be possible.


Another workaround is to avoid using globs in the filelist. Listing the paths directly works. However up until now, the pyproject macros had no knowledge of how many optimized levels of bytecode are there (they supported any number >= 1). We would need to hardcode this knowledge to the macros, which I do no like :(

Comment 2 Maxwell G 2021-11-18 23:05:32 UTC
Hi Miro,

(In reply to Miro Hrončok from comment #1)
> Yes, this is another form of bz1990879 (may I merge the two problems into a
> single bugzilla, i.e. mark this as a duplicate and edit the summary of that
> one?).

I'm not sure that is the same issue. The error message is different and the problematic characters are different. Am I missing something?

> 
> Unfortunately, there seems to be no way to escape the {} shell-glob symbols
> in a path with another shell-glob in the %files section and hence we cannot
> include this path in the file list.
> 
> One workaround might be to replace the {} symbols with question marks, but
> that could lead to unexpected problems (it could math other paths).
> 
> Another possible workaround is to examine the directory containing weird
> paths and include it entirely if all the files within are also included
> (which is a bit tricky but possible). The problem with this approach is that
> it might not always be possible.
> 
> 
> Another workaround is to avoid using globs in the filelist. Listing the
> paths directly works. However up until now, the pyproject macros had no
> knowledge of how many optimized levels of bytecode are there (they supported
> any number >= 1). We would need to hardcode this knowledge to the macros,
> which I do no like :(

I ended up completely removing the `%pyproject_save_files` macro and listing the paths manually in `%files`.

```
%{python3_sitelib}/%{srcname}
%{python3_sitelib}/%{srcname}-%{version}.dist-info
```

Is it feasible to have `%pyproject_save_files` find the actual paths instead of passing globs to rpm?

Thanks,
Maxwell

Comment 3 Tomas Orsava 2021-12-07 10:56:00 UTC
(In reply to Maxwell G from comment #2)
> Hi Miro,
> 
> (In reply to Miro Hrončok from comment #1)
> > Yes, this is another form of bz1990879 (may I merge the two problems into a
> > single bugzilla, i.e. mark this as a duplicate and edit the summary of that
> > one?).
> 
> I'm not sure that is the same issue. The error message is different and the
> problematic characters are different. Am I missing something?

RPM has problems with all of these special characters. If you'd like to move this issue along, please ping the RPM upstream: https://github.com/rpm-software-management/rpm/issues/1749

*** This bug has been marked as a duplicate of bug 1990879 ***