Created attachment 207699 [details] astro/pyephem takes astro/py-ephem as a dependency With the newest version 3.7.7.0, the port astro/pyephem only installs a nonfunctional stub without any functional Python code[1]. This is, because the naming scheme of the sources changed from pyephem to ephem. Since some other ports expect the old name pyephem, a new functional port astro/py-ephem with the Python code was created[2]. With the attached patch, astro/pyephem (the existing one) takes a new port astro/py-ephem as a dependency, so that other ports like comms/gnuradio will find the Python code installed by ephem again: From comms/gnuradio Makefile: BUILD_DEPENDS=${PYTHON_SITELIBDIR}/ephem/__init__.py:astro/pyephem@${PY_FLAVOR} [1] Description section of PKG-INFO:l9-17 "This package is a stub that contains no Python code, but lists ``ephem`` as its install requirement in case any old projects depend on this ``pyephem`` package name. New projects are encouraged to directly require the main package, which can be found at: https://pypi.org/project/ephem/ " [2] https://pypi.org/project/ephem/
The new port astro/py-ephem was submitted in bug #240736
Note: Python ports should use package names (not file names) for their dependency lines wherever possible.
(In reply to Kubilay Kocak from comment #2) Hi Kubilay, Not sure, if you mean comms/gnuradio here with its dependency to astro/pyephem? The new port astro/py-ephem (bug #240736) uses the (unflavored) package name (py27-ephem-3.7.7.0), like for example graphics/py-cairo does (py27-cairo-1.18.1_1). Or am I wrong here?
^Triage: - "Summarise change" in issue Title - Add dependent bug to make it clear which one needs to land first Note: See blocking bug #240736 for rationale explanation now that that has been removed from this issues Title.
@Rainer A few questions: 1) As eluded to in comment 0 [1], since: - There's no PORTVERSION (upstream version) change in this diff, and - An astro/py-ephem port (bug 240736) doesn't yet exist - The current astro/pyephem version contains an setup.py:install_requires on ephem in the present version (ie: its just a stub in its present form) This means that the astro/pyephem port is currently and actually broken, and accordingly, so are its dependents. Is that accurate and correct? If so, the question then becomes: 2) How do we get this resolved in quarterly, particularly since normally, new ports are usually not merge'able to the quarterly branch. 3) You mentioned " Since some other ports expect the old name pyephem" in comment 0. Could you provide an exact and complete state of the ports that currently depend on astro/pyephem. ie: Do they all declare a dependency on 'pyephem' in their sources currently? Do any of them now depend on on 'ephem' directly, for either their current freebsd versions, and/or released newer versions? It would be good to get this as a plain list: - cat/port: <paste dependency line from setup.py/setup.cfg/requirements.txt/etc> - repeat for all dependents of astro/pyephem - check upstream versions of dependents to see if they've changed, noting the version in which they changed [1] "with the newest version 3.7.7.0, the port astro/pyephem only installs a nonfunctional stub without any functional Python code"
(In reply to Rainer Hurling from comment #3) yes sorry, I did mean that: ${PYTHON_SITELIBDIR}/ephem/__init__.py:astro/pyephem@${PY_FLAVOR} \ Which is interesting, in that it looks for 'ephem' *not* 'pyephem', but then uses the 'pyephem' port ... I haven't checked, but I assume pyephem installs a 'pyephem' package/module, and the stub imports (or tries to) then import 'ephem' Clarity around this would be great, as it may impact the way we go about resolving this and bug 240736 properly.
@Kubilay Sorry for the late answer. I am very busy in these last days of the year and the questions needed some investigation. Before I answer I should mention, that I am not the maintainer of astro/pyephem and therefore did no analysis before. Answer to question 1): I think your synopsis and conclusion is correct, astro/pyephem is actually broken and so its dependents. Answer to question 2): A possible solution could be to waive the new port astro/py-ephem and instead, change the existing port astro/pyepehm from a stub to the usage of the new functional part of ephem directly. The only problem I see with this is with the naming scheme. In my understanding 'ephem' should be used as py-ephem and not pyephem. If this is secondary, I could live with only one port pyephem ... Answer to question 3): There are three other ports in the FreeBSDs ports tree, that use astro/pyephem directly as a dependent, and and in total three ports that depend on the direct dependends: ------------------------------------------------------------------------------------ devel/py-convertdate/Makefile, version 2.2.0 18:RUN_DEPENDS+= ${PYTHON_PKGNAMEPREFIX}pyephem>0:astro/pyephem@${PY_FLAVOR} -- devel/py-fbprophet/Makefile, version 0.5 27:RUN_DEPENDS+= ${PYTHON_PKGNAMEPREFIX}convertdate>2.1.2:devel/py-convertdate@${PY_FLAVOR} ------------------------------------------------------------------------------------ astro/py-aipy/Makefile, version 2.1.9 [newer version 3.0.1 available] 17: ${PYTHON_PKGNAMEPREFIX}pyephem>=0:astro/pyephem@${PY_FLAVOR} \ ------------------------------------------------------------------------------------ comms/gnuradio/Makefile, version 3.8.0.0 23: ${PYTHON_SITELIBDIR}/ephem/__init__.py:astro/pyephem@${PY_FLAVOR} \ -- comms/gqrx/Makefile, version 2.11.5 17:LIB_DEPENDS= libgnuradio-runtime.so:comms/gnuradio \ -- comms/gr-osmosdr/Makefile, version 0.1.4-127 17:LIB_DEPENDS= libgnuradio-runtime.so:comms/gnuradio \ As far as I found, there is no direct dependency on the (new) ephem in the ports tree. Upstream version has changed only for astro/py-aipy [2.1.9 -> 3.0.1]. aipy changed its dependency from pyephem to ephem on 21 August[1][2]. In summary, in my understanding there is no need in the FreeBSD ports tree to split the ephem functionality into two ports astro/pyephem [stub only] and astro/py-ephem [with new functional code]. It is more a problem with the FreeBSD naming scheme, isn't it? [1] https://github.com/HERA-Team/aipy/blob/master/doc/source/install.rst [2] https://github.com/HERA-Team/aipy/blob/master/requirements.txt
(In reply to Kubilay Kocak from comment #6) @Kubilay Yes, comms/gnuradio expects ${PYTHON_SITELIBDIR}/ephem/__init__.py to be installed, but astro/pyephem (the actual version with the stub in the ports tree) does not install it any more. Because of that comms/gnuradio is not buildable atm.
^Triage: Track blockers/dependencies
This port also needs a rename to py-pyephem. Both changes (missing dependency, rename) are: Approved by: portmgr (blanket(s): build/runtime fix, missing dependencies) Approved by: portmgr (blanket: ports/framework (python) compliance) @Wen May I take care of this issue and the changes to dependents?
The plan to fix dependent ports (see bug 240546) in quarterly is as follows: 1) Land new port py-ephem (bug 240736) and MFH 2) Add py-ephem as a RUN_DEPENDS to existing astro/pyephem and MFH (I may do this as a single commit with (1)) 3) Rename astro/pyephem -> astro/py-pyephem (and *not* MFH)
Both ports (pyephem / py-ephem) should be maintained by the same person since pyephem depends on: setup.py:install_requires=['ephem==' + version], The == requirement could of course be relaxed, but we want to ensure these two port versions stay in (version) sync anyway, so I wouldn't relax the requirement, and it stays in there as a sanity check for future port updates An alternative would be to have one port slave off the other, but this is probably going to be messy and confusing given they are actually different and separate packages that other software can independently depend on. @Wen / @Rainer Could you decide between yourselves who will maintain these two ports. I'll make the maintainer change accordingly.
A commit references this bug: Author: koobs Date: Sun Dec 15 08:33:48 UTC 2019 New revision: 520159 URL: https://svnweb.freebsd.org/changeset/ports/520159 Log: devel/py-convertdate: Fix broken dependencies convertdate does not [1] depend on pyephem, which was replaced with pymeeus in 2.2.0. Dependency astro/py-pymeeus landed in ports r520157 as a new port. This issue was identified while QA'ing pyephem dependents for bug 240735 [1] HISTORY.rst:* Replace pyephem, which is now in maintenance mode, with pymeeus. PR: 240735 Approved by: portmgr (blanket(s): dependencies, runtime bugfix) MFH: 2019Q4 (MFH with r520157) Changes: head/devel/py-convertdate/Makefile
See Also bug 240546 comment 11 on gnuradio, one dependent of pyephem, likely not actually needing to depend on {py}ephem at all
A commit references this bug: Author: koobs Date: Sun Dec 15 09:42:42 UTC 2019 New revision: 520166 URL: https://svnweb.freebsd.org/changeset/ports/520166 Log: astro/pyephem: Add missing (ephem) dependency The 3.7.7.0 release of pyephem was converted [1] into a stub, depending on the ephem package, in order to allow software authors to transition to the new package name. The ports r511276 commit updating the port to 3.7.7.0 missed the additional dependency. This change adds the missing dependency, after astro/py-ephem landed as a new port in ports r520162, and unbreaks all current astro/pyephem dependents, and all transitive dependents, including comms/gnuradio [2]. While I'm here: - Add NO_ARCH - Bump PORTREVISION given this issue did not affect builds, just runtime and dependents accordingly. [1] https://github.com/brandon-rhodes/pyephem/commit/5c32679a8650efd2e79d5f794edd1587b3b6e67b [2] bug 240546 PR: 240735 Submitted by: Rainer Hurling <rhurlin gwdg de> Approved by: portmgr (blanket(s): missing dependencies, build/run fix (dependents)) MFH: 2019Q4 (MFH with r520162) Changes: head/astro/pyephem/Makefile
A commit references this bug: Author: koobs Date: Fri Dec 20 09:53:57 UTC 2019 New revision: 520489 URL: https://svnweb.freebsd.org/changeset/ports/520489 Log: MFH: r520157 [NEW] astro/py-pymeeus: Python implementation of Jean Meeus astronomical routines PyMeeus is a Python implementation of the astronomical algorithms described in the classical book "Astronomical Algorithms, 2nd Edition, Willmann-Bell Inc. (1998)" by Jean Meeus. WWW: https://github.com/architest/pymeeus PR: 240735 Approved by: ports-secteam (joneum) Changes: _U branches/2019Q4/ branches/2019Q4/astro/Makefile branches/2019Q4/astro/py-pymeeus/
A commit references this bug: Author: koobs Date: Fri Dec 20 09:56:48 UTC 2019 New revision: 520490 URL: https://svnweb.freebsd.org/changeset/ports/520490 Log: MFH: r520159 devel/py-convertdate: Fix broken dependencies convertdate does not [1] depend on pyephem, which was replaced with pymeeus in 2.2.0. Dependency astro/py-pymeeus landed in ports r520157 as a new port. This issue was identified while QA'ing pyephem dependents for bug 240735 [1] HISTORY.rst:* Replace pyephem, which is now in maintenance mode, with pymeeus. PR: 240735 Approved by: portmgr (blanket(s): dependencies, runtime bugfix) Approved by: ports-secteam (implicit, via ports r520489 approval) Changes: _U branches/2019Q4/ branches/2019Q4/devel/py-convertdate/Makefile
A commit references this bug: Author: koobs Date: Fri Dec 20 10:11:29 UTC 2019 New revision: 520494 URL: https://svnweb.freebsd.org/changeset/ports/520494 Log: MFH: r520166 astro/pyephem: Add missing (ephem) dependency The 3.7.7.0 release of pyephem was converted [1] into a stub, depending on the ephem package, in order to allow software authors to transition to the new package name. The ports r511276 commit updating the port to 3.7.7.0 missed the additional dependency. This change adds the missing dependency, after astro/py-ephem landed as a new port in ports r520162, and unbreaks all current astro/pyephem dependents, and all transitive dependents, including comms/gnuradio [2]. While I'm here: - Add NO_ARCH - Bump PORTREVISION given this issue did not affect builds, just runtime and dependents accordingly. [1] https://github.com/brandon-rhodes/pyephem/commit/5c32679a8650efd2e79d5f794edd1587b3b6e67b [2] bug 240546 PR: 240735 Submitted by: Rainer Hurling <rhurlin gwdg de> Approved by: portmgr (blanket(s): missing dependencies, build/run fix (dependents)) Approved by: ports-secteam (joneum) Changes: _U branches/2019Q4/ branches/2019Q4/astro/pyephem/Makefile
Committed and merged