Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12641 > unrolled thread

SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?

Back to article view | Back to linux.debian.maint.python

Contents

  SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest? Julien Puydt <julien.puydt@gmail.com> - 2020-06-08 17:30 +0200
    Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest? Ondrej Novy <novy@ondrej.org> - 2020-06-09 11:00 +0200
      Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in  autopkgtest? Julien Puydt <julien.puydt@gmail.com> - 2020-06-09 12:00 +0200
        Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in  autopkgtest? Simon McVittie <smcv@debian.org> - 2020-06-09 13:30 +0200

#12641 — SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?

Hi,

I know about the SETUPTOOLS_SCM_PRETEND_VERSION trick when it is used
in d/rules :

include /usr/share/dpkg/pkg-info.mk
export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)

so setuptools-scm won't have trouble finding the correct version
outside of a git repository. But the situation I'm facing is that the
upstream testing code also needs this. Not at build-time, but at
autopkgtest-time.

My initial d/tests/control was:

Tests: upstreamtestsuite
Depends: @, python3-setuptools, python3-setuptools-scm

and d/tests/upstreamtestsuite was:

#!/bin/sh
set -e
python3 setup.py test 2>1

which of course failed because setuptools-scm couldn't find the
version.

I got around by turning d/tests/upstreamtestsuite to:

#!/bin/sh
set -e
SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 python3 setup.py test 2>&1

which worked because in fact the tests don't care about the version.

But if they did, how would I inject the right version into this script?

Thanks,

JP

[toc] | [next] | [standalone]

#12643

[Multipart message — attachments visible in raw view] — view raw

H,

po 8. 6. 2020 v 17:22 odesílatel Julien Puydt <julien.puydt@gmail.com>
napsal:

> Hi,
>
> I know about the SETUPTOOLS_SCM_PRETEND_VERSION trick when it is used
> in d/rules :
>
> include /usr/share/dpkg/pkg-info.mk
> export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
>

dh-python do this automatically when python{,3}-setuptools-scm is in B-D.


> I got around by turning d/tests/upstreamtestsuite to:
>
> #!/bin/sh
> set -e
> SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 python3 setup.py test 2>&1
>
> which worked because in fact the tests don't care about the version.
>

you can use "dpkg-parsechangelog -SVersion" or include /usr/share/dpkg/
pkg-info.mk + $DEB_VERSION_UPSTREAM here too.

-- 
Best regards
 Ondřej Nový

[toc] | [prev] | [next] | [standalone]

#12644 — Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?

Hi,

Le mardi 09 juin 2020 à 10:35 +0200, Ondrej Novy a écrit :

> po 8. 6. 2020 v 17:22 odesílatel Julien Puydt <julien.puydt@gmail.com
> > napsal:
> > I know about the SETUPTOOLS_SCM_PRETEND_VERSION trick when it is
> > used
> > in d/rules :
> > 
> > include /usr/share/dpkg/pkg-info.mk
> > export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
> 
> dh-python do this automatically when python{,3}-setuptools-scm is in
> B-D.

Oh, so in fact, the only package which should do that in its d/rules
should be setuptools-scm itself, then ?

> > I got around by turning d/tests/upstreamtestsuite to:
> > 
> > #!/bin/sh
> > set -e
> > SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 python3 setup.py test 2>&1
> > 
> > which worked because in fact the tests don't care about the
> > version.
> 
> you can use "dpkg-parsechangelog -SVersion" or include
> /usr/share/dpkg/pkg-info.mk + $DEB_VERSION_UPSTREAM here too.

There are several things I don't understand there:

(1) during the autopkgtest run, we're not in the package source tree,
are we? So there should be no access do d/changelog?

(2) including pkg-info.mk is for makefiles, so not available there, and
dpkg-parsechangelog -SVersion will give me the full Debian version, not
just upstream's.

Thanks,

JP

[toc] | [prev] | [next] | [standalone]

#12645 — Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?

On Tue, 09 Jun 2020 at 11:50:02 +0200, Julien Puydt wrote:
> (1) during the autopkgtest run, we're not in the package source tree,
> are we? So there should be no access do d/changelog?

    The cwd of each test is guaranteed to be the root of the source
    package, which will have been unpacked but not built. However note
    that the tests must test the installed version of the package,
    as opposed to programs or any other file from the built tree.
    — https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst

I've found that a lot of the time, what makes most sense is to gather
the information you need from the source tree, copy the files you
need from the source tree into a temporary directory, cd into the
temporary directory, and do the rest of your testing there. This avoids
things like Python's default "add the script's directory to sys.path"
behaviour accidentally picking up the version of the library that's in
the source package, which would result in not testing the installed copy
as required. For example, src:python-mpd does this.

Another way to get a similar result is to install the tests as part of the
binary packages, cd into an empty temporary directory, and run them from the
installed location. src:tap.py does this (the tests are small, so they're
just included in the main binary package) and so does src:dbus-python (the
tests are larger and have non-trivial dependencies, so they're a separate
binary package).

autopkgtest guarantees that $AUTOPKGTEST_TMP is an empty temporary
directory, or you can make your own with mktemp -d or similar, or you
can use a tool like ginsttest-runner (aka gnome-desktop-testing-runner,
in the gnome-desktop-testing package) that does it for you.

    smcv

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web