Bug 263956 - textproc/py-mistune0: Add CONFLICTS with text/py-mistune
Summary: textproc/py-mistune0: Add CONFLICTS with text/py-mistune
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Po-Chuan Hsieh
URL:
Keywords: easy, needs-patch
Depends on:
Blocks:
 
Reported: 2022-05-13 18:22 UTC by John Hein
Modified: 2022-05-17 08:45 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (sunpoet)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2022-05-13 18:22:17 UTC
If both textproc/py-mistune0 and textproc/py-mistune are installed, the latter masks the former.  Doing 'import mistune' loads the newer mistune instead of mistune0.
Comment 1 John Hein 2022-05-13 21:43:11 UTC
The problem is that for textproc/mistune0, site-packages/mistune.py exists.

For textproc/mistune, it is site-packages/mistune/__init__.py (and other .py files in that mistune/subdir).

This is not a file conflict, but it is a sort of conflict when it comes to importing the module in python code.  When you do 'import mistune', python picks the second way (mistune/__init__.py) and ignores the existence of the mistune0 way (lone mistune.py file).

This would be a good candidate for a CONFLICTS_INSTALL marker perhaps.

To work around this issue, one could modify the mistune0 port to install mistune0.py and update all consumers in the ports tree to import mistune0.  This doesn't help consumers that are not in the ports tree that were dependent on the older mistune.  A note in UPDATING might be warranted to explain this.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2022-05-16 23:13:50 UTC
(In reply to John Hein from comment #1)

Multiple versions of python packages installed at the same time is a broad and non freebsd specific  (python ecosystem) issue that we can currently only handled (scalably) by adding CONFLICTS. In fact, given that this is expected behaviour, we should probably handle it in some automated manner. Unfortauntely the current method of version suffixing separately named ports (with unique package names) is not trivially amenable to this.