https://bugzilla.redhat.com/show_bug.cgi?id=1244014 --- Comment #5 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to Carl George from comment #4) > > Have you tried running %build and %install without creating a separate py3k directory? This package doesn't use 2to3 so this should work juts as well. > > I have not tried it that way. I just did it the same way I saw several > other module packages do it (pip, setuptools, six, click). The only > documentation I could find about this says the macro should be used when the > same source is used for both python2 and python3 [1], which is the case here. This idea of using py3dir originated when sources were "translated" when building the package, using 2to3. After this step was done, sources were incompatible with Python 2 and couldn't be used any more, so there was no choice except to use a second source directory. Another related reason could have been that when building for multiple python versions, .so, .pyc, and .pyo files would be overwritten. Starting with python3 the version of the interpreter is included in the file name (.cpython-34m.so, .cpython-34.pyc), so build products do not conflict. Python 2.x does not use this, but because we are building for only one version of Python 2 and one version of Python 3, the conflict is avoided anyway. Using 2to3 was cumbersome, and fortunately almost no projects do that any more. The guidelines do not require a separate directory to be used, and only prescribe the name of the directory to use if it used. Most new packages don't use a separate directory. If you insist on using two source directories, I won't press the point, but please note that a) this is totally obsolete because the reasons for it are gone b) it clutters the spec file and the file system > > You can use %global _docdir_fmt %{name} to use a common license and documentation directories. > > I'm not following what the point of this would be. I thought the current > project goal was to separate license files from documentation [2]? It's about sharing the %doc dir between subpackages, and the %license dir between subpackages. You'd have: /usr/share/doc/python-ddt/README /usr/share/licenses/python-ddt/LICENSE and those two files would be owned by both python-ddt and python3-ddt. The motivation is that when a user looks into /usr/share/doc/, if both packages are installed, he or she has to inspect both READMEs to realize that they are identical, so it's just simpler to provide just one file. > > Summary or %description should say what this package is in more basic term (e.g. a library which provides a testing framework). > > I thought that was clear in the summary, but I am not a wordsmith, so I'm > open to more detailed suggestions here. I just copied the current summary > and description from the setup.py and README.md files. Maybe the > long_description in the setup.py would be more appropriate for the RPM > description? > > > long_description='A library to multiply test cases', Actually, what is missing, is the information that this is not a testing framework, but that it is to be used with unittests or nose. So maybe something like this: %description DDT (Data-Driven Tests) allows you to multiply one test case by running it with different test data, and make it appear as multiple test cases. It is used in combination with other testing frameworks like unittest and nose. Hm, and what about documentation? There are some sphinx docs which could be built and distributed. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review