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

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

Bug#970643: "pytest" command is missing

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#970643: "pytest" command is missing "Novy, Ondrej" <Ondrej.Novy@firma.seznam.cz> - 2020-11-04 21:50 +0100
    Bug#970643: "pytest" command is missing Thomas Goirand <zigo@debian.org> - 2020-11-05 09:40 +0100
      Bug#970643: "pytest" command is missing "terceiro@debian.org" <terceiro@debian.org> - 2020-11-05 13:10 +0100
        Bug#970643: "pytest" command is missing Matthias Klose <doko@debian.org> - 2020-11-05 14:00 +0100

#13001 — Bug#970643: "pytest" command is missing

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

Hi,

Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
> Could you ellaborate? Maybe we should have a discussion in the Pythonteam so
> that we implement consistent practices. For example, `gunicorn`and `pip` now
> point to their python3 versions, but you are saying thatpytest will not do
> that, what maybe creates more confusion given Debianbullseye will not support
> any other Python.

"pytest" in buster now points to python2 version of pytest and "pytest-3" points
to python3 version. To prevent confusion after upgrade I want to keep one stable
release with pytest cmd "unoccupied" and keep pytest-3.

Bullseye will support Python2 interpreter so user can keep python-pytest package
installed from buster.


-- 
Best regards Ondřej Nový

[toc] | [next] | [standalone]

#13002

On 11/4/20 9:27 PM, Novy, Ondrej wrote:
> Hi,
> 
> Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
>> Could you ellaborate? Maybe we should have a discussion in the Python
>> team so that we implement consistent practices. For example, `gunicorn`
>> and `pip` now point to their python3 versions, but you are saying that
>> pytest will not do that, what maybe creates more confusion given Debian
>> bullseye will not support any other Python.
> 
> "pytest" in buster now points to python2 version of pytest and
> "pytest-3" points to python3 version. To prevent confusion after upgrade
> I want to keep one stable release with pytest cmd "unoccupied" and keep
> pytest-3.
> 
> Bullseye will support Python2 interpreter so user can keep python-pytest
> package installed from buster.

Moreover, simply invoking "pytest-3" is not enough, one should be using:

for pyvers in $$(py3versions -vr 2>/dev/null) ; do \
	python$$pyvers -m pytest ; \
done

otherwise, only the default version of Python3 is tested, and we really
want to test with all available versions (so we get results whenever
we're transitioning to a new Python 3 version).

Cheers,

Thomas Goirand (zigo)

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

#13003

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

On Thu, Nov 05, 2020 at 09:28:56AM +0100, Thomas Goirand wrote:
> On 11/4/20 9:27 PM, Novy, Ondrej wrote:
> > Hi,
> > 
> > Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
> >> Could you ellaborate? Maybe we should have a discussion in the Python
> >> team so that we implement consistent practices. For example, `gunicorn`
> >> and `pip` now point to their python3 versions, but you are saying that
> >> pytest will not do that, what maybe creates more confusion given Debian
> >> bullseye will not support any other Python.
> > 
> > "pytest" in buster now points to python2 version of pytest and
> > "pytest-3" points to python3 version. To prevent confusion after upgrade
> > I want to keep one stable release with pytest cmd "unoccupied" and keep
> > pytest-3.
> > 
> > Bullseye will support Python2 interpreter so user can keep python-pytest
> > package installed from buster.

The python2 interpreter will be supported, but nothing else will, so I
don't see the point of this compatibility.  I don't think that "keep you
old packages from the previous release" is a great upgrade path.

Anyway, my point is that we should collective aim to be consistent
across the Python packages. The fact that some packages have made their
"not *3" binaries be the python3 versions, and others not, due to
arbitrary individual maintainer decisions, is a mess.

> Moreover, simply invoking "pytest-3" is not enough, one should be using:
> 
> for pyvers in $$(py3versions -vr 2>/dev/null) ; do \
> 	python$$pyvers -m pytest ; \
> done
> 
> otherwise, only the default version of Python3 is tested, and we really
> want to test with all available versions (so we get results whenever
> we're transitioning to a new Python 3 version).

Sure, but that only applies for package maintainance. People who just
want to use pytest to test their Python code have a (IMO pointless)
divergence from upstream. This made some sense when there were 2
supported Python ecosystems, but that's now in the past. We could take
the opportunity to fix this.

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

#13004

On 11/5/20 1:03 PM, terceiro@debian.org wrote:
> On Thu, Nov 05, 2020 at 09:28:56AM +0100, Thomas Goirand wrote:
>> On 11/4/20 9:27 PM, Novy, Ondrej wrote:
>>> Hi,
>>>
>>> Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
>>>> Could you ellaborate? Maybe we should have a discussion in the Python
>>>> team so that we implement consistent practices. For example, `gunicorn`
>>>> and `pip` now point to their python3 versions, but you are saying that
>>>> pytest will not do that, what maybe creates more confusion given Debian
>>>> bullseye will not support any other Python.
>>>
>>> "pytest" in buster now points to python2 version of pytest and
>>> "pytest-3" points to python3 version. To prevent confusion after upgrade
>>> I want to keep one stable release with pytest cmd "unoccupied" and keep
>>> pytest-3.
>>>
>>> Bullseye will support Python2 interpreter so user can keep python-pytest
>>> package installed from buster.
> 
> The python2 interpreter will be supported, but nothing else will, so I
> don't see the point of this compatibility.  I don't think that "keep you
> old packages from the previous release" is a great upgrade path.

well, afaiu, we also will ship python-pip, so that users are able to get their
python2 code from other places.

> Anyway, my point is that we should collective aim to be consistent
> across the Python packages. The fact that some packages have made their
> "not *3" binaries be the python3 versions, and others not, due to
> arbitrary individual maintainer decisions, is a mess.

it's a difficult decision to make. But if people want, then we could ship
pytest-is-python2 and pytest-is-python3 packages as well, as long as we don't
build-depend on those.

Matthias

[toc] | [prev] | [standalone]

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

csiph-web