1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.PYTHON

  • packaging help request: paths for build_py and build_scripts phases

    From Jonathan Dowland@21:1/5 to All on Mon Oct 18 12:10:01 2021
    Hello,

    I am attempting to package the latest upstream version of "trash-cli"ΒΉ,
    which differs quite a lot from the current package on the build side of
    things.
    https://github.com/andreafrancia/trash-cli

    The problem occurs during the post-build test phase. The tests cannot
    find the scripts they are trying to test. The build appears to be a
    standard python setuptools/distutils thing and the packaging is a
    standard dh --with python3 --buildsystem=pybuild. The Build runs

    /usr/bin/python3 setup.py build

    Which outputs the following (elided)

    running build_py
    creating /<<PKGBUILDDIR>>/.pybuild/cpython3_3.9/build/trashcli
    copying trashcli/fstab.py -> /<<PKGBUILDDIR>>/.pybuild/cpython3_3.9/build/trashcli
    ...

    So for the build_py phase, the destination for copied files is rooted
    under <<PKGBUILDDIR>>. The next build phase handles scripts:

    running build_scripts
    creating build
    creating build/scripts-3.9
    copying and adjusting trash -> build/scripts-3.9
    ...

    Here, the scripts are copied to a path *not* rooted in <<PKGBUILDDIR>>.
    So far as I can tell, both phases are normal parts of the
    setuptools/distutils build lifecycle, and I haven't spotted anything
    obviously non-standard about the way that is specified.

    Where is it that the build_py phase's path are specified or overridden
    such that they are correctly rooted under <<PKGBUILDDIR>>, and why isn't
    the same true of the build_scripts phase?

    I've pushed my WIP packaging to a temporary branch. https://salsa.debian.org/debian/trash-cli/-/tree/jmtd-update-0.21.7.24
    A BTS bug requesting the new version with some back-and-forth trying to
    figure this out is
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988597

    Thank you in advance for any tips you can offer!


    Best wishes,

    --

    πŸ‘±πŸ» Jonathan Dowland
    ✎ jmtd@debian.org
    πŸ”— https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Mon Oct 18 18:20:03 2021
    Hi Jonathan,

    * Jonathan Dowland <jmtd@debian.org> [2021-10-18 11:04]:
    Here, the scripts are copied to a path *not* rooted in <<PKGBUILDDIR>>.
    So far as I can tell, both phases are normal parts of the >setuptools/distutils build lifecycle, and I haven't spotted anything >obviously non-standard about the way that is specified.
    [...]
    A BTS bug requesting the new version with some back-and-forth trying to >figure this out is
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988597

    The main issue is the implicit upstream assumption that the tests
    are run from the source root dir; I've had a similar problem with
    tweepy and my solution was to make sure that the tests find
    everything they need in the build folder, i.e. add the following
    snippet to d/rules:

    export PYBUILD_BEFORE_TEST=cp {dir}/trash-* {dir}/script/bump.py {build_dir} export PYBUILD_AFTER_TEST=rm {build_dir}/trash-* {build_dir}/bump.py

    The second line is needed so the extraneous stuff is not installed
    with the built package. It's not very pretty, and hopefully someone
    else has a better solution, but it gets the job done.

    You'll also have to patch tests/run_command.py to run python3 and
    add python3-psutils to your Build-Depends.


    diff --git a/tests/run_command.py b/tests/run_command.py
    index 2e31e11..746cdad 100644
    --- a/tests/run_command.py
    +++ b/tests/run_command.py
    @@ -17,7 +17,7 @@ def run_command(cwd, command, args=None, input='', env=None):
    if args == None:
    args = []
    command_full_path = os.path.join(base_dir, command)
    - process = subprocess.Popen(["python", command_full_path] + args,
    + process = subprocess.Popen(["python3", command_full_path] + args,
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,


    Cheers
    Timo

    PS. I worked around the missing fork
    PPS. I thought about patching run_command.py to use the scripts from
    the source directory, but that will use the trashcli module from the
    source tree, not from the build tree, and contaminate the source tree
    with __pycache__ folders.

    --
    ⒀⣴⠾⠻⒢⣦⠀ ╭───────────────────────────────────────────β”