Configure check for empy3 with 0.116 fails with Fedora 32

[aperezbios]

@quozl , back in August, you committed a fix for configure.ac (d47694d) which now fails under Fedora 32.

When running configure, the empy test fails, even when the python3-empy package is installed.

You can successfully complete a build by simply commenting out the offending AC_PATH_PROGS([EMPY], [empy empy3]) test condition, or, by using the following hack:

AC_PATH_PROGS([EMPY], [empy empy3], [/usr/lib/python3.8/site_packages/em.py])

...but we should probably be using the AX_PYTHON_MODULE M4 macro instead: https://www.gnu.org/software/autoconf-archive/ax_python_module.html

This needs to be corrected in the configure.ac file for all python release tarballs.

[quozl]

Thanks for reporting this. I wouldn't have noticed.

• my earlier fix to this in August requires EMPY=%{python3_sitelib}/em.py on the configure command line, which is what @nullr0ute had used in the opening comment of the issue,

./configure EMPY=%{python3_sitelib}/em.py

• on Debian, Ubuntu, and other distributions, installing the empy packages do provide a /usr/bin/empy{,3} yet Fedora 18 and Fedora 31 do not, so can Fedora please fix that? There are other Python modules that provide a binary in $PATH, such as python3-flake8, and python3-pyflakes.

• using AX_PYTHON_MODULE will only check for the Python module, for use in the scenario where the module is imported, but we don't import, we execute directly,

• distribution-specific fixes are best made by the distributions, not upstream. I've tried fixing this before, but didn't get any feedback until now. I don't release Sugar specifically for Fedora. I don't have time to deal with Fedora's deviations and regressions, but hope someone else does, and it looks like @nullr0ute has committed your workaround instead.

• probably what you need is an automated way to find empy, which the Python environment has built-in, so

python3 -m em - -p $$ -D scaling=100 < gtkrc.em > sugar-100.gtkrc

Please make that change and test on Fedora 32?

[Bottersnike]

This appears to be a shortcoming of something within the sugar build system. The build system is looking for a binary named empy, however this is not part of empy. Comparison of the setup.py files for flake8 and empy shows flake8 explicitly telling python to install a binary named flake8 which runs flake8.main.cli.main() (https://gitlab.com/pycqa/flake8/blob/master/setup.cfg#L61), however the setup script for empy is far more minimal, and has no such addition. The empy binaries present in packages such as the one available on debian have been explicitly added by the package maintainers, and probably shouldn't be relied on existing. This same behaviour can easily be reproduced on any system by uninstalling the package manager's empy package and instead installing it system-wide with pip.

For what it's worth, this same issue occurs when installing python-empy, python2-empy, or just using pip, on Arch, as the arch packages, similarly to fedora, do not add this magic custom binary.

[quozl]

Excellent, thanks. That makes two distributions that don't provide a binary, and one that does. Does the change in my earlier comment work?

python3 -m em - -p $$ -D scaling=100 < gtkrc.em > sugar-100.gtkrc

[aperezbios]

Here's a workaround patch https://pastebin.com/raw/9JEa6tic

[aperezbios]

@quozl, can you please clarify what the command you've pasted in your previous comment is supposed to accomplish? It does not execute at a CLI, and fails with ":6: error: <class 'NameError'>: name 'scaling' is not defined"

Is it expected to?

[quozl]

Thanks for testing. This use of empy can be found in the first ten lines of Makefile.am in the data directory., and in several other makefiles in sugar-artwork, see sugarlabs/sugar-artwork#111 (comment) for a diff. The command is a replacement for what is there. The command runs empy during build.

[srevinsaju]

On arch, it provides python-empy which does not create a executable,
binary. For me adding this in the configure will make it good.

if python3 -m em --version; then echo empy found as Python module;
alias empy3='python3 -m em'; fi

[quozl]

Thanks @srevinsaju. I'm just curious; on Arch Linux, does the em.py file have execute bits set? I ask because the empy README gives two examples of use that would require execute bits.

[srevinsaju]

The em.py on Arch Linux is not executable. None of the python modules are executable.
Where should I add this python3 -m em - -p $$ -D scaling=100 < gtkrc.em > sugar-100.gtkrc to test it?

[quozl]

The em.py on Arch Linux is not executable. None of the python modules are executable.

This goes against the Empy documentation, which gives a clear expectation that Empy is executable. Please report this bug against Arch Linux or Empy?

Where should I add this python3 -m em - -p $$ -D scaling=100 < gtkrc.em > sugar-100.gtkrc to test it?

This is very frustrating. I gave a complete reply to this in the thread Initial Release: Sugar packages 0.116 for Arch Linux. Did you miss it?