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

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

running tests against installed version of package

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

Contents

  running tests against installed version of package Brian May <brian@linuxpenguins.xyz> - 2016-03-25 08:20 +0100
    Re: running tests against installed version of package Ben Finney <ben+debian@benfinney.id.au> - 2016-03-25 11:50 +0100
      Re: running tests against installed version of package Brian May <bam@debian.org> - 2016-03-26 03:50 +0100
        Re: running tests against installed version of package Brian May <bam@debian.org> - 2016-03-26 04:10 +0100
          Re: running tests against installed version of package Ben Finney <ben+debian@benfinney.id.au> - 2016-03-26 04:20 +0100
        Re: running tests against installed version of package Ben Finney <ben+debian@benfinney.id.au> - 2016-03-26 04:10 +0100
    Re: running tests against installed version of package Barry Warsaw <barry@debian.org> - 2016-03-25 23:20 +0100
      Re: running tests against installed version of package Brian May <bam@debian.org> - 2016-03-26 04:00 +0100
        Re: running tests against installed version of package Barry Warsaw <barry@debian.org> - 2016-03-31 19:00 +0200
    Re: running tests against installed version of package Brian May <brian@linuxpenguins.xyz> - 2016-03-27 07:20 +0200
      egg-info executable files Brian May <bam@debian.org> - 2016-03-27 07:30 +0200
        Re: egg-info executable files Ben Finney <ben+debian@benfinney.id.au> - 2016-03-27 08:50 +0200
    Re: running tests against installed version of package Thomas Goirand <zigo@debian.org> - 2016-04-01 00:00 +0200
      Re: running tests against installed version of package Piotr Ożarowski <piotr@debian.org> - 2016-04-01 00:20 +0200
        Re: running tests against installed version of package Thomas Goirand <zigo@debian.org> - 2016-04-02 14:00 +0200
          Re: running tests against installed version of package Piotr Ożarowski <piotr@debian.org> - 2016-04-02 23:00 +0200
      Re: running tests against installed version of package Tiago Ilieve <tiago.myhro@gmail.com> - 2016-04-02 10:10 +0200
        Re: running tests against installed version of package Brian May <bam@debian.org> - 2016-04-03 03:40 +0200
          Re: running tests against installed version of package Tiago Ilieve <tiago.myhro@gmail.com> - 2016-04-03 04:50 +0200
            Re: running tests against installed version of package Brian May <bam@debian.org> - 2016-04-03 05:00 +0200
        Re: running tests against installed version of package Thomas Goirand <zigo@debian.org> - 2016-04-06 00:30 +0200
          Re: running tests against installed version of package Piotr Ożarowski <piotr@debian.org> - 2016-04-06 11:00 +0200

Page 1 of 2  [1] 2  Next page →

#8334 — running tests against installed version of package

Hello,

By default pybuild runs tests I think using the source tree.

However I have a package where the tests require the entry points from
setup.py to be configured, the tests fail without this.

So what is the appropriate way to modify debian/rules to get the tests
to run from the installed version with the entry points available?

This is:

Vcs-Git: git://anonscm.debian.org/python-modules/packages/apscheduler.git
Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/apscheduler.git

(I considered moving this to become DPMTs maintained, however it appears
the original package maintainer is still interested; so the above
repository may not stay)

See #807797

I filled an uptream bug report before I realized what the problem is:

https://bitbucket.org/agronholm/apscheduler/issues/114/lookuperror-no-trigger-by-the-name-date

Thanks
-- 
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/

[toc] | [next] | [standalone]

#8336

Brian May <brian@linuxpenguins.xyz> writes:

> Vcs-Git: git://anonscm.debian.org/python-modules/packages/apscheduler.git
> Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/apscheduler.git

The “git:” URL method is not encrypted. You should specify the encrypted
“https:” method in the “VCS-Git” field:

    Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/apscheduler.git

-- 
 \          “That's all very good in practice, but how does it work in |
  `\                                             *theory*?” —anonymous |
_o__)                                                                  |
Ben Finney

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

#8345

Ben Finney <ben+debian@benfinney.id.au> writes:

> The “git:” URL method is not encrypted. You should specify the encrypted
> “https:” method in the “VCS-Git” field:
>
>     Vcs-Git:
>     https://anonscm.debian.org/git/python-modules/packages/apscheduler.git

So just to double check, this should solve that right?

sed 's=git://anonscm.debian.org/=https://anonscm.debian.org/git/=' */debian/control

...I notice a number of packages I maintain have this problem and I
really want to make sure I get this right first time!
-- 
Brian May <bam@debian.org>

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

#8347

Ben Finney <ben+debian@benfinney.id.au> writes:

> As another check, you can test the resulting URL with a ‘git clone’ to a
> temporary target directory.

It doesn't seem to like me today:

% git clone https://anonscm.debian.org/git/python-modules/packages/apscheduler.git
Cloning into 'apscheduler'...
[ relatively long timeout ]
fatal: unable to access 'https://anonscm.debian.org/git/python-modules/packages/apscheduler.git/': gnutls_handshake() failed: Error in the pull function.

Is this URL correct?

I also tried git from unstable in case the version in Jessie is broken,
however the results are the same
-- 
Brian May <bam@debian.org>

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

#8349

Brian May <bam@debian.org> writes:

> Ben Finney <ben+debian@benfinney.id.au> writes:
>
> > As another check, you can test the resulting URL with a ‘git clone’ to a
> > temporary target directory.
>
> It doesn't seem to like me today:

Alioth is not responding at all, for me at the moment. And not just for me:

<URL:http://downforeveryoneorjustme.com/alioth.debian.org>

You'll need to do the test when Alioth can actually pass the test :-)

-- 
 \      “If you were going to shoot a mime, would you use a silencer?” |
  `\                                                    —Steven Wright |
_o__)                                                                  |
Ben Finney

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

#8348

Brian May <bam@debian.org> writes:

> Ben Finney <ben+debian@benfinney.id.au> writes:
>
> > The “git:” URL method is not encrypted. You should specify the encrypted
> > “https:” method in the “VCS-Git” field
>
> So just to double check, this should solve that right?
>
> sed 's=git://anonscm.debian.org/=https://anonscm.debian.org/git/=' */debian/control

That looks right to me, for the case you presented. I make no promises
for what will result on other texts :-)

> ...I notice a number of packages I maintain have this problem and I
> really want to make sure I get this right first time!

As another check, you can test the resulting URL with a ‘git clone’ to a
temporary target directory.

-- 
 \         “A child of five could understand this. Fetch me a child of |
  `\                                              five.” —Groucho Marx |
_o__)                                                                  |
Ben Finney

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

#8342

On Mar 25, 2016, at 06:17 PM, Brian May wrote:

>However I have a package where the tests require the entry points from
>setup.py to be configured, the tests fail without this.
>
>So what is the appropriate way to modify debian/rules to get the tests
>to run from the installed version with the entry points available?

In some cases, I've just taken to adding DEP-8 tests for those.

Cheers,
-Barry

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

#8346

Barry Warsaw <barry@debian.org> writes:

> In some cases, I've just taken to adding DEP-8 tests for those.

Do you have an example I can look at?

Thanks
-- 
Brian May <bam@debian.org>

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

#8367

On Mar 26, 2016, at 01:49 PM, Brian May wrote:

>Barry Warsaw <barry@debian.org> writes:
>
>> In some cases, I've just taken to adding DEP-8 tests for those.  
>
>Do you have an example I can look at?

Hi Brian.  Take a look at tox for example.

Cheers,
-Barry

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

#8354

> ... little cheat: run the tests after install:
> https://sources.debian.net/src/pytest-catchlog/1.2.2-1/debian/rules/

Ok, thanks for that.

In my case I found the order is not important. What is important is that
the tests are run via "setup.py" which will write/read the
APScheduler.egg-info/*


--- cut ---
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<<PKGBUILDDIR>>'
dh_auto_test
I: pybuild base:184: cd /<<PKGBUILDDIR>>/.pybuild/pythonX.Y_2.7/build; python2.7 -m pytest tests
============================= test session starts ==============================
platform linux2 -- Python 2.7.11+, pytest-2.9.1, py-1.4.31, pluggy-0.3.1
rootdir: /<<PKGBUILDDIR>>, inifile: setup.cfg
collected 401 items
...
--- cut ---

vs

--- cut ---
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<<PKGBUILDDIR>>'
dh_auto_test -- --system=custom --test-args="{interpreter} setup.py test"
I: pybuild base:184: python2.7 setup.py test
running test
running egg_info
writing requirements to APScheduler.egg-info/requires.txt
writing APScheduler.egg-info/PKG-INFO
writing top-level names to APScheduler.egg-info/top_level.txt
writing dependency_links to APScheduler.egg-info/dependency_links.txt
writing entry points to APScheduler.egg-info/entry_points.txt
reading manifest file 'APScheduler.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'APScheduler.egg-info/SOURCES.txt'
running build_ext
============================= test session starts ==============================
platform linux2 -- Python 2.7.11+, pytest-2.9.1, py-1.4.31, pluggy-0.3.1
rootdir: /<<PKGBUILDDIR>>, inifile: setup.cfg
collected 401 items
--- cut ---




-- 
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/

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

#8355 — egg-info executable files

Anybody here seen this before?

W: python3-apscheduler: executable-not-elf-or-script usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/PKG-INFO
W: python3-apscheduler: executable-not-elf-or-script usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/requires.txt
W: python3-apscheduler: executable-not-elf-or-script usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/top_level.txt
W: python3-apscheduler: executable-not-elf-or-script ... use --no-tag-display-limit to see all (or pipe to a file/program)
W: python-apscheduler: executable-not-elf-or-script usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/requires.txt
W: python-apscheduler: executable-not-elf-or-script usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/entry_points.txt
W: python-apscheduler: executable-not-elf-or-script usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/dependency_links.txt
W: python-apscheduler: executable-not-elf-or-script ... use --no-tag-display-limit to see all (or pipe to a file/program)

setuptools seems to want to make these files executable for some reason,
however it doesn't normally do so, and I don't see any reason why it
should do so for this project.
-- 
Brian May <bam@debian.org>

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

#8356 — Re: egg-info executable files

Brian May <bam@debian.org> writes:

> Anybody here seen this before?
>
> W: python3-apscheduler: executable-not-elf-or-script usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/PKG-INFO
> W: python3-apscheduler: executable-not-elf-or-script usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/requires.txt
> W: python3-apscheduler: executable-not-elf-or-script usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/top_level.txt
> W: python3-apscheduler: executable-not-elf-or-script ... use --no-tag-display-limit to see all (or pipe to a file/program)
> W: python-apscheduler: executable-not-elf-or-script usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/requires.txt
> W: python-apscheduler: executable-not-elf-or-script usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/entry_points.txt
> W: python-apscheduler: executable-not-elf-or-script usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/dependency_links.txt
> W: python-apscheduler: executable-not-elf-or-script ... use --no-tag-display-limit to see all (or pipe to a file/program)
>
> setuptools seems to want to make these files executable for some
> reason,

Possibly they have the executable permission in the upstream source
tarball? This is a common symptom of files from MS Windows systems.

Solution: convince upstream to build the tarball better, and/or re-pack
it to fix the permissions.

-- 
 \      “He that would make his own liberty secure must guard even his |
  `\                             enemy from oppression.” —Thomas Paine |
_o__)                                                                  |
Ben Finney

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

#8371

On 03/25/2016 08:17 AM, Brian May wrote:
> Hello,
> 
> By default pybuild runs tests I think using the source tree.

In most cases, Pybuild isn't very helpful for running tests and fails in
the most common traps (like the one I'm solving for you below), which is
why I don't really think it's useful at all. YMMV...

> However I have a package where the tests require the entry points from
> setup.py to be configured, the tests fail without this.

Most of the time, you get by this doing:
PYTHONPATH=$(CURDIR) python -m pytest tests

If this doesn't work (maybe because you need the egg-info which isn't in
the tarball, or otherwise...), then get the package installed first:

python setup.py install --install-layout=deb \
	--root $(CURDIR)/debian/tmp
PYTHONPATH=$(CURDIR)/debian/tmp python -m pytest tests

In the case of apscheduler, simply defining PYTHONPATH=. is enough, then
unit tests failing are those trying to connect to a local redis server
which may be fixed by manually starting redis-server from your
debian/rules (take care: you *must* start it on a non-standard port or
unix file-socket, and get your unit tests to use that non-standard port,
otherwise you'll be in trouble either in sbuild, or in non-sbuild).

By doing the above, I was able to run *all* of the unit tests of
apscheduler (ie: 404 tests, minus the 7 tests which got automatically
skipped).

I hope this helps, even though you probably will not maintain this
package. Hopefully, it will help you for the next one! :)

Cheers,

Thomas Goirand (zigo)

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

#8372

> > By default pybuild runs tests I think using the source tree.

pybuild tells build system to build .py/.so files in temporary
directory (with a _stable_ name), copies tests dir there as well,
changes current directory to that dir (so that sys.path[0] doesn't point
to sources), runs tests and removes them (so that install target doesn't
pick them up)

> In most cases, Pybuild isn't very helpful for running tests and fails in
> the most common traps (like the one I'm solving for you below), which is
> why I don't really think it's useful at all. YMMV...

file bugs please. Works fine for me.

> > However I have a package where the tests require the entry points from
> > setup.py to be configured, the tests fail without this.
> 
> Most of the time, you get by this doing:
> PYTHONPATH=$(CURDIR) python -m pytest tests

this will test python2.7 only and will most probably ignore extensions, etc.
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

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

#8377

On 04/01/2016 12:13 AM, Piotr Ożarowski wrote:
>> Most of the time, you get by this doing:
>> PYTHONPATH=$(CURDIR) python -m pytest tests
> 
> this will test python2.7 only

Running tests with multiple version of Python was out of scope of my
message.

> and will most probably ignore extensions, etc.

What do you mean? What extensions? Suff like pypy?

Cheers,

Thomas Goirand (zigo)

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

#8378

[Thomas Goirand, 2016-04-02]
> > this will test python2.7 only
> 
> Running tests with multiple version of Python was out of scope of my
> message.

it might be out of scope of your message, but during package's build all
interpreters ought to be tested

> > and will most probably ignore extensions, etc.
> 
> What do you mean? What extensions? Suff like pypy?

no, I mean Python extensions (.so files). distutils builds them by
default in ./build/lib.linux-x86_64-2.7/foo (where "lib.linux-x86_64-2.7"
is sometimes random) and this dir is not in sys.path, so you're not
testing built files - you're testing source files only (.so files are not
tested, if any .py file is not installed, your tests will not detect
that, etc.). Testing sources is good, but we can do better.
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

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

#8376

Thomas,

On 31 March 2016 at 18:49, Thomas Goirand <zigo@debian.org> wrote:
> Most of the time, you get by this doing:
> PYTHONPATH=$(CURDIR) python -m pytest tests

Awesome tip! Just stumbled up on this one when imports where changed
from relative to absolute and this tip properly fixed the matter.

Piotr,

On 31 March 2016 at 19:13, Piotr Ożarowski <piotr@debian.org> wrote:
> this will test python2.7 only and will most probably ignore extensions, etc.

I've used the following workaround for this.

override_dh_auto_test:
        PYTHONPATH=$(CURDIR) py.test
        PYTHONPATH=$(CURDIR) py.test-3

... As Python's "unittest discover" weren't working anyway.

Regards,
Tiago.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

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

#8379

Tiago Ilieve <tiago.myhro@gmail.com> writes:

> override_dh_auto_test:
>         PYTHONPATH=$(CURDIR) py.test
>         PYTHONPATH=$(CURDIR) py.test-3

This will only test the current version of Python 3. Which is OK at the
moment, there is only Python 3.5

However it was very useful to have packages run tests against Python 3.5
while Python 3.4 was still the default.

I imagine the same thing will happen when Python 3.6 is released.
-- 
Brian May <bam@debian.org>

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

#8381

Hi Brian,

On 2 April 2016 at 22:32, Brian May <bam@debian.org> wrote:
> This will only test the current version of Python 3. Which is OK at the
> moment, there is only Python 3.5
>
> However it was very useful to have packages run tests against Python 3.5
> while Python 3.4 was still the default.
>
> I imagine the same thing will happen when Python 3.6 is released.

I see. Actually I've removed the "override_dh_auto_test"[1] when I
found out[2] that Pybuild can to do this by itself.

Now I wonder whether this is enough to fit the use case of multiple
Python 3 versions that you mentioned...

Regards,
Tiago.

[1]: https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/commit/?h=debian/unstable&id=9b57cbf
[2]: https://wiki.debian.org/Python/LibraryStyleGuide#Overriding

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

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

#8382

Tiago Ilieve <tiago.myhro@gmail.com> writes:
> I see. Actually I've removed the "override_dh_auto_test"[1] when I
> found out[2] that Pybuild can to do this by itself.
>
> Now I wonder whether this is enough to fit the use case of multiple
> Python 3 versions that you mentioned...


Yes, I believe that is sufficient. The default dh_auto_test will do the
correct thing.
-- 
Brian May <bam@debian.org>

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web