n applications for Debian) do the Python unit tests run?
As a part of the build process they run when the package is built.
As a part of autopkgtests then run when autopkgtests for the package are
triggered, so after it's uploaded and when its deps/revdeps (?) are
uploaded.
> I know about the S
Hello,
I try to understand some basics about debian packaging Python
applications and the upload and test process.
My question in short: When (at which time point in the process of
packaging python applications for Debian) do the Python unit tests run?
I know about the Salsa instance
Hi,
I've investigated a bit more and found where I was confused.
TL;DR: I'm deleting the non-needed workaround and found where things are
happening.
On 05 Oct 2023 at 16:36:17, Andrey Rakhmatullin wrote:
> On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote:
> > > upstream test
Hi,
On 05 Oct 2023 at 16:38:29, Andrey Rakhmatullin wrote:
> On Wed, Oct 04, 2023 at 07:58:11AM +0100, Carles Pina i Estany wrote:
> > Recap: pytest executed from "pybuild-autopkgtest", in the
> > python-cloudscraper package, would use the src cloudscrapper instead of
> > the installed one.
> >
Hi,
On 05 Oct 2023 at 16:36:17, Andrey Rakhmatullin wrote:
> On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote:
> > > upstream tests. Though I think it won't see your explicit `pytest -k` and
> > > you should replace the override with a PYBUILD_TEST_ARGS var.
> >
> > Done thi
On Wed, Oct 04, 2023 at 07:58:11AM +0100, Carles Pina i Estany wrote:
> Recap: pytest executed from "pybuild-autopkgtest", in the
> python-cloudscraper package, would use the src cloudscrapper instead of
> the installed one.
>
> So, to make sure that pytest uses the installed one, I added in
> deb
On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote:
> > upstream tests. Though I think it won't see your explicit `pytest -k` and
> > you should replace the override with a PYBUILD_TEST_ARGS var.
>
> Done this way:
> https://salsa.debian.org/python-team/packages/python-cloudscrap
Hi Andrey, list
On 03 Oct 2023 at 23:52:58, Carles Pina i Estany wrote:
> On 03 Oct 2023 at 12:25:27, Andrey Rakhmatullin wrote:
> > On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote:
> > > I will create a new version of the package and upload it into
> > > mentors.debian.net
Hi Andrey, list,
On 03 Oct 2023 at 12:25:27, Andrey Rakhmatullin wrote:
> On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote:
> > I will create a new version of the package and upload it into
> > mentors.debian.net when I finish this email. For reference: it will be
> > the ver
On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote:
> I will create a new version of the package and upload it into
> mentors.debian.net when I finish this email. For reference: it will be
> the version 1.2.69-3.
Note that the usual practice is not bumping Debian versions for pack
ad it into
mentors.debian.net when I finish this email. For reference: it will be
the version 1.2.69-3.
> > So far I've done:
> > Maintainer: Carles Pina i Estany
> > And no Uploader (will be the sponsor on the first time).
> >
> > Is that correct?
>
> It&
time).
Is that correct?
It's probably preferable to directly put the team as Maintainer.
* Question 3: allow failing tests from upstream in dh_auto_test
Upstream has 4 failing unit tests. Besides working with upstream to fix
them what I've done is, in debian/rules:
-
override_dh_auto_t
ow failing tests from upstream in dh_auto_test
Upstream has 4 failing unit tests. Besides working with upstream to fix
them what I've done is, in debian/rules:
-
override_dh_auto_test:
# Disable tests failing from upstream
pytest -k "not (test_bad
way
to run Python unit tests?
No (except "whatever the upstream CI runs").
This would vote for option 3:
pythonX -m tests
Best regards
Peter
On Tue, Dec 08, 2020 at 09:33:03PM +0100, Peter Wienemann wrote:
> Dear Python experts,
>
> in trying to update the python-lark package [0] to the most recent upstream
> version, an interesting issue regarding unit tests showed up [1]. Depending
> on how one runs unit tests they
Dear Python experts,
in trying to update the python-lark package [0] to the most recent
upstream version, an interesting issue regarding unit tests showed up
[1]. Depending on how one runs unit tests they either fail or not. Tried
options are:
1. PYTHONWARNINGS=d pythonX -m unittest
On Tue, Sep 9, 2014 at 4:59 AM, Jakub Wilk wrote:
> * Josue Ortega , 2014-09-08, 21:21:
>
>> When the tests are running the docstrings are displayed in a terminal
>> pager making impossible run all tests without human interaction to close
>> the pager. I've found this really annoying if someone w
* Josue Ortega , 2014-09-08, 21:21:
When the tests are running the docstrings are displayed in a terminal
pager making impossible run all tests without human interaction to
close the pager. I've found this really annoying if someone wants to
build the package even the build process might fail i
Hi,
Currently I am working on the debianization of oct2py[1] which is
a bridge between Python an GNU Octave.
When the tests are running the docstrings are displayed in a terminal pager
making impossible run all tests without human interaction to close the
pager. I've found this really annoying
On Sat, Dec 26, 2009 at 19:11, Guy Hulbert wrote:
> On Sat, 2009-26-12 at 17:13 +0100, W. Martin Borgert wrote:
>> Quoting "anatoly techtonik" :
>> If unit tests were in the package, reportbug could automatically
>> run them on a bug report. Does someone do this al
re there any such people here? Do they prefer different package
repository with stripped down binary packages like
http://wiki.debian.org/Embedded_Debian ?
> Also, the dependencies of a package that includes unit tests are
> generally greater; a significant amount of Python package
e?
I think the judgement of “not bloat the package too much” is to be made
with consideration of those users striving for a small system as their
primary concern, e.g. those trying to install onto embedded systems with
minimal storage.
Also, the dependencies of a package that includes unit tests ar
ple think of the issue?
They should only be in the source package.
>
> If unit tests were in the package, reportbug could automatically
> run them on a bug report. Does someone do this already, maybe?
Can reportbug be modified to download a source package and run tests ?
>
--
--
Quoting "anatoly techtonik" :
Even if most users don't need them, tests greatly increase the value
of bugreports and doesn't bloat python packages too much.
True. What do other people think of the issue?
If unit tests were in the package, reportbug could automatically
run
On Fri, Dec 25, 2009 at 6:01 PM, W. Martin Borgert wrote:
> Quoting "anatoly techtonik" :
>>
>> Python policy is silent about unit tests. Should they be stripped? Or
>> should they be Debianized or left as-is?
>
> Just my opinion: Unit tests should be in
Quoting "anatoly techtonik" :
Python policy is silent about unit tests. Should they be stripped? Or
should they be Debianized or left as-is?
Just my opinion: Unit tests should be in the source package, but not
in the binary package. Most users don't need them, and if somebody
wa
Hello,
I'm having some troubles with trac-accountmanager package and want to
execute its unit tests to see if they could catch anything unusual,
but it appeared that they were stripped from the package.
Python policy is silent about unit tests. Should they be stripped? Or
should th
27 matches
Mail list logo
