1.16.0: pytest needs `setuptools`

[mtkennerly]

1.16.0: pytest needs `setuptools`

[kloczek]

Just tested that commit and all looks good 👍

+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-dunamai-1.16.0-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-dunamai-1.16.0-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ /usr/bin/pytest -ra -m 'not network'
============================= test session starts ==============================
platform linux -- Python 3.8.16, pytest-7.2.2, pluggy-1.0.0
rootdir: /home/tkloczko/rpmbuild/BUILD/dunamai-1.16.0
collected 58 items

tests/integration/test_dunamai.py .........s..s.sss                      [ 29%]
tests/unit/test_dunamai.py ......................................        [ 94%]
tests/unit/test_main.py ...                                              [100%]

=========================== short test summary info ============================
SKIPPED [1] tests/integration/test_dunamai.py:448: Requires Mercurial
SKIPPED [1] tests/integration/test_dunamai.py:534: Requires Darcs
SKIPPED [1] tests/integration/test_dunamai.py:672: Requires Bazaar
SKIPPED [1] tests/integration/test_dunamai.py:735: Requires Fossil
SKIPPED [1] tests/integration/test_dunamai.py:789: Requires Pijul
======================== 53 passed, 5 skipped in 22.37s ========================

Thank you very much 😄
Closing.

[mtkennerly]

If you're running Dunamai's unit tests, then you should prepare the dev environment via poetry install. setuptools is included in the repository's poetry.lock, so that should take care of the issue. If you're trying to avoid that, then could you give me some more detail about your use case?

[kloczek]

I'm packaging your module as rpm [ackage and for buld env preparation is rersponsible packages buil automation baseing on BRs (build is performed in build env which is cut off from access to public network).

Nevertheless this still has notnig to to wit fact that pkg_resources should be not used 😋

[mtkennerly]

Sorry, I'm not familiar with RPM. Could you elaborate on how the test dependencies are installed? The tests passed during the GitHub build, so I'd like to understand how your test environment is different. I don't mind swapping out the deprecated module (it only affects the unit test code), but I would be concerned if environment differences could lead to other issues now or later. For example, your log output shows Pytest 7.2.2, but per poetry.lock, it should be 7.2.0, so it doesn't look like you're installing the same test dependencies pinned in the repository.

[kloczek]

Use depreated pkg_resources has nothing to do with rpm.

[mtkennerly]

I understand. I just want to confirm if you'll be running the tests with the same versions of the dependencies that are pinned in poetry.lock.

[kloczek]

I just want to confirm if you'll be running the tests with the same versions of the dependencies that are pinned in poetry.lock.

That is rally hard to use exactly the same versions becaue I have only one vesion of exact module in my rpm packages repo.
To have something working I'm fully relly on test suites executions results.
If module passes its own test suite which is the case for about +65% of all package module.
I have +1.1k packaged as rpm packages python modules and aongst them

[tkloczko@pers-jacek SPECS]$ grep "%bcond_with.*failing_tests" python-* | wc -l
265
[tkloczko@pers-jacek SPECS]$ grep "%bcond_with.*check" python-* | wc -l
106

Which means that 265 packages has some disabled units and 106 completly disabled test suites.
Example spec file of youtr module:

# BUG: switch pytest to importlib-metadata https://github.com/mtkennerly/dunamai/issues/60
# PRE-INST: subversion
# TODO: enable testing more VCS backends
Summary:        Dynamic version generation
Name:           python-dunamai
Version:        1.16.0
Release:        2%{?dist}
License:        MIT (https://spdx.org/licenses/MIT.html)
URL:            https://pypi.org/pypi/dunamai/
VCS:            https://github.com/mtkennerly/dunamai/
Source:         %{VCS}/archive/v%{version}/%{name}-%{version}.tar.gz
Patch:          %{name}-man_pages.patch
BuildArch:      noarch
BuildRequires:  python3dist(build)
BuildRequires:  python3dist(pip)
BuildRequires:  python3dist(poetry-core)
BuildRequires:  python3dist(wheel)
# ChcekRequires:
#BuildRequires: /usr/bin/bzr
#BuildRequires: /usr/bin/darcs
#BuildRequires: /usr/bin/fossil
#BuildRequires: /usr/bin/hg
#BuildRequires: /usr/bin/pijul
BuildRequires:  git-core
BuildRequires:  python3dist(pytest)
BuildRequires:  python3dist(setuptools)
BuildRequires:  subversion
Obsoletes:      python3-dunamai

%description
Dunamai is a Python 3.5+ library and command line tool for producing dynamic,
standards-compliant version strings, derived from tags in your version control
system. This facilitates uniquely identifying nightly or per-commit builds in
continuous integration and releasing new versions of your software simply by
creating a tag.

%prep
%autosetup -p1 -n dunamai-%{version}

%build
%pyproject_wheel

%install
%pyproject_install

%__install -Dm644 docs/*1 -t %{buildroot}%{_mandir}/man1

%check
#brz whoami "Your Name <[email protected]>"
#export DARCS_EMAIL="Yep something <[email protected]>"
git config --global user.email "[email protected]"
git config --global user.name "Your Name"
%pytest

%files
%doc README.*
%attr(755,root,root) %{_bindir}/*
%{_mandir}/man1/*
%{python3_sitelib}/dunamai
%{python3_sitelib}/dunamai-*.*-info

[kloczek]

BTW would you accept PR with below patch which adds lvl 1 man pages made by fedora maintainer? 🤔
it would be good to rewrite that to sphinx however it straight roff output is BetterThanNothing™️
python-dunamai-man_pages.patch

[mtkennerly]

pkg_resources is removed now in master :)

That is rally hard to use exactly the same versions becaue I have only one vesion of exact module in my rpm packages repo.

I see; thank you for clarifying.

BTW would you accept PR with below patch which adds lvl 1 man pages made by fedora maintainer?

I would be hesitant to add it, partly since I don't have a way to keep it up to date when there are changes, and partly since distro-specific packaging is outside the scope of this project.