Bug 290576 - textproc/py-pystemmer: update to 3.0.0
Summary: textproc/py-pystemmer: update to 3.0.0
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Danilo G. Baio
URL:
Keywords:
Depends on:
Blocks: 290749
  Show dependency treegraph
 
Reported: 2025-10-27 14:41 UTC by John Hein
Modified: 2025-11-11 08:38 UTC (History)
4 users (show)

See Also:
vishwin: maintainer-feedback? (dbaio)


Attachments
[patch] update pystemmer to 3.0.0 (1.98 KB, patch)
2025-10-27 14:41 UTC, John Hein
no flags Details | Diff
[patch] update pystemmer to 3.0.0 (v2) (1.97 KB, patch)
2025-10-27 14:57 UTC, John Hein
no flags Details | Diff
[patch] update pystemmer to 3.0.0 (v3) (2.08 KB, patch)
2025-10-27 15:40 UTC, John Hein
no flags Details | Diff
[patch] update pystemmer to 3.0.0 (patch to include update for deps due to name change) (718 bytes, patch)
2025-10-27 16:09 UTC, John Hein
no flags Details | Diff
[patch] update pystemmer to 3.0.0 (v4) (2.08 KB, patch)
2025-11-02 17:26 UTC, John Hein
jcfyecrayz: maintainer-approval? (dbaio)
Details | Diff
link with textproc/snowballstemmer v0 (3.29 KB, patch)
2025-11-11 03:19 UTC, Charlie Li
vishwin: maintainer-approval? (dbaio)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2025-10-27 14:41:28 UTC
Created attachment 264939 [details]
[patch] update pystemmer to 3.0.0

- update pystemmer to latest (3.0.0)
- use cython3
- rm old alternative MASTERSITE (no longer available)
- add pytest


see:
https://pypi.org/project/PyStemmer/
https://pypi.org/simple/pystemmer/
https://github.com/snowballstem/pystemmer/tags
Comment 1 John Hein 2025-10-27 14:42:37 UTC
fix typo in port name in bug summary
Comment 2 John Hein 2025-10-27 14:57:59 UTC
Created attachment 264940 [details]
[patch] update pystemmer to 3.0.0 (v2)

I tried USE_PYTHON=pep517, and it failed (no .whl file [[1]]).
It may be an easy fix, but I didn't dig into that at all.

[[1]]
===============
 .
 .
cd /usr/ports/textproc/py-pystemmer/work-py311/pystemmer-3.0.0 && /usr/bin/env -i HOME=/usr/ports/textproc/py-pystemmer/work-py311  MACHINE_ARCH=amd64  PWD="${PWD}"  GIT_CEILING_DIRECTORIES=/usr/ports/textproc/py-pystemmer/work-py311  __MAKE_CONF=/nonexistent OSVERSION=1305502 PATH=/usr/ports/textproc/py-pystemmer/work-py311/.bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin TERM=xterm XDG_DATA_HOME=/usr/ports/textproc/py-pystemmer/work-py311  XDG_CONFIG_HOME=/usr/ports/textproc/py-pystemmer/work-py311  XDG_CACHE_HOME=/usr/ports/textproc/py-pystemmer/work-py311/.cache  HOME=/usr/ports/textproc/py-pystemmer/work-py311 PATH=/usr/ports/textproc/py-pystemmer/work-py311/.bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin PKG_CONFIG_LIBDIR=/usr/ports/textproc/py-pystemmer/work-py311/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  CC="cc" CFLAGS="-O2 -pipe  -fstack-protector-strong -fno-strict-aliasing "  CPP="cpp" CPPFLAGS=""  LDFLAGS=" " LIBS=""  CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing  " BSD_INSTALL_PROGRAM="install  -s -m 555"  BSD_INSTALL_LIB="install  -s -m 0644"  BSD_INSTALL_SCRIPT="install  -m 555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444" /usr/local/bin/python3.11 -m installer --destdir /usr/ports/textproc/py-pystemmer/work-py311/stage --prefix /usr/local /usr/ports/textproc/py-pystemmer/work-py311/pystemmer-3.0.0/dist/pystemmer-3.0.0*.whl
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/local/lib/python3.11/site-packages/installer/__main__.py", line 98, in <module>
    _main(sys.argv[1:], "python -m installer")
  File "/usr/local/lib/python3.11/site-packages/installer/__main__.py", line 86, in _main
    with WheelFile.open(args.wheel) as source:
  File "/usr/local/lib/python3.11/contextlib.py", line 137, in __enter__
    return next(self.gen)
           ^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/installer/sources.py", line 162, in open
    with zipfile.ZipFile(path) as f:
         ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/zipfile.py", line 1311, in __init__
    self.fp = io.open(file, filemode)
              ^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/usr/ports/textproc/py-pystemmer/work-py311/pystemmer-3.0.0/dist/pystemmer-3.0.0*.whl'
*** Error code 1

===============
Comment 3 John Hein 2025-10-27 15:07:32 UTC
(In reply to John Hein from comment #2)
Regarding the pep517 error, it just looks like python.mk's PEP517_INSTALL_CMD looks for pystemmer-*, while the generated .whl is PyStemmer-*.  But PEP517_INSTALL_CMD doesn't allow for an easy override of the name.  So for now, just live with USE_PYTHON=distutils.
Comment 4 John Hein 2025-10-27 15:40:01 UTC
Created attachment 264942 [details]
[patch] update pystemmer to 3.0.0 (v3)

v3 of patch works with pep517. Changes in v3:

- PORTNAME is now PyStemmer (matches upstream name - see https://wiki.freebsd.org/Python/PortsPolicy)

- fix up DISTNAME to be able to grab the right source tarball name (even though the 'makedist.sh' creates PyStemmer*.tar.gz, for some reason the upstream is doing some packaging that creates pystemmer*.tar.gz now - since 2.2.0.2)

- ran portfmt while here and followed one word sorting recommendation
Comment 5 John Hein 2025-10-27 16:09:12 UTC
Created attachment 264944 [details]
[patch] update pystemmer to 3.0.0 (patch to include update for deps due to name change)

Also including a patch here due to the PORTNAME change to accommodate ports that list PyStemmer as a dependency (just one at this time).
Comment 6 John Hein 2025-11-02 17:19:57 UTC
Comment on attachment 264944 [details]
[patch] update pystemmer to 3.0.0 (patch to include update for deps due to name change)

The patch in comment 5 / attachment 264944 [details] for change to dependent port (i.e., py-snowballstemmer dependency on py-pystemmer) has been moved to a separate bug 290749 for clarity of tracking.
Comment 7 John Hein 2025-11-02 17:26:53 UTC
Created attachment 265114 [details]
[patch] update pystemmer to 3.0.0 (v4)

Very minor update to patch after ports 795bfbe85c61b78359a0e9b8ffa56878142d303b

That commit update USES_PYTHON=cython to USES_PYTHON=cython3 which the previous patches here also changed.  Just update the patch to reflect that is now a non-change after the above commit.

Also deprecate the the patch to py-snowballstemmer here (attachment 264944 [details]) which is now a separate bug (bug 290749).  These two should be committed together (slightly complicated by two separate MAINTAINERS of the two ports - please coordinate for a seamless update).
Comment 8 John Hein 2025-11-02 17:28:35 UTC
CC py-snowballstemmer maintainer for coordination (see comment 7 and bug 290749).
Comment 9 John Hein 2025-11-02 17:33:49 UTC
(In reply to John Hein from comment #7)
summary of changes in v4 of the patch now:

- update pystemmer to latest (3.0.0)
- change PORTNAME to adhere to python ports policy and make USE_PYTHON=pep517 work
- rm old alternative MASTERSITE (no longer available)
- add pytest
- use pep517

These are effectively the same changes as the previous patch except the change to cython3 is not necessary for ports 795bfbe85c61b78359a0e9b8ffa56878142d303b
Comment 10 Charlie Li freebsd_committer freebsd_triage 2025-11-08 05:55:01 UTC
[triage: assign and set maintainer-feedback? to maintainer]

(In reply to John Hein from comment #3)
The package name is not to be modified or overridden in the Makefile except for normalisation as in [0], so the original PORTNAME was correct. Note that later setuptools enforces fully-normalised distribution and package names, which includes lowercasing everything, as in [1]. This is better done as a patch to setup.py (otherwise pyproject.toml) until setuptools is updated.

(In reply to John Hein from comment #9)
This is kind of up to maintainer discretion, but the package can link to textproc/snowballstemmer instead of building its bundled copy by setting PYSTEMMER_SYSTEM_LIBSTEMMER in ${CONFIGURE_ENV} and ${MAKE_ENV}. Unfortunately, this currently cannot be done under USE_PYTHON=pep517 due to continued deficiencies in setuptools's PEP-517 support, namely passing config settings are still not supported yet.

[0] https://packaging.python.org/en/latest/specifications/name-normalization/
[1] https://packaging.python.org/en/latest/specifications/binary-distribution-format/#escaping-and-unicode
Comment 11 Po-Chuan Hsieh freebsd_committer freebsd_triage 2025-11-08 20:09:34 UTC
(In reply to John Hein from comment #9)

I must say that it is quite annoying with inconsistent PORTNAME (mixed case, PyStemmer) and path (lowercase).

I would suggest you use lowercase for both PORTNAME and path, and patch setup.py from "setup(name='PyStemmer'" to "setup(name='pystemmer'".

If you insist using mixed case in PORTNAME, you do not need maintainer approval for such collateral change in bug #290749.
Comment 12 Po-Chuan Hsieh freebsd_committer freebsd_triage 2025-11-08 20:11:04 UTC
(In reply to Po-Chuan Hsieh from comment #11)

Sorry, I just noticed that Daniel is the maintainer.

Daniel, I would suggest keep using the lowercase PORTNAME. Thanks.
Comment 13 Charlie Li freebsd_committer freebsd_triage 2025-11-11 03:19:57 UTC
Created attachment 265317 [details]
link with textproc/snowballstemmer v0

Turns out, {CONFIGURE,MAKE}_ENV to enable linking with textproc/snowballstemmer instead of building the bundled copy does work under USE_PYTHON=pep517, as it seems to be passed through devel/py-build into setuptools the same as USE_PYTHON=distutils. I was operating on old experience with older devel/py-build it seems.

Also includes a setup.py patch to normalise the package name, needed before bug 270358 is committed.
Comment 14 Po-Chuan Hsieh freebsd_committer freebsd_triage 2025-11-11 08:38:48 UTC
(In reply to Charlie Li from comment #13)

Thanks.

And I believe that bug #290749 can be closed now.