Fedora Account System
Red Hat Associate
Red Hat Customer
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
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 :(
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
(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 ***