sphinx and sphinx
There are two sphinxs: textproc/py-sphinx: "python documentation generator" https://www.sphinx-doc.org/ textproc/sphinx: "free open-source SQL full-text search engine" https://sphinxsearch.com/ The first is the one people usually want, the presence of textproc/sphinx in itself causes some confusion (there's a comment in the port Makefile but mistakes are still sometimes made with this). There's also a problem with the py2/3 versions of py-sphinx because the executables are named sphinx- and sphinx--3 to avoid a conflict; this causes problems for porters wanting to use the doc generator that result in either pulling in an unwanted py2 dependency, or having to patch or add symlinks to cope with the unexpected filename. A proposal in three parts: - Either drop textproc/sphinx (it's unmaintained in ports, hasn't been updated in ports since 2015 despite regular upstream updates, and has no other ports using it), or reimport it as databases/sphinxsearch to avoid confusion. - Remove executables from py-sphinx and py3-sphinx - Either multipackage py3-sphinx or add a separate port, the relevant package depending on py3-sphinx, and containing the executables, named without MODPY_BIN_SUFFIX, i.e. sphinx-apidoc, sphinx-build etc. Maybe name this something like sphinxdoc or sphinx-doc? (Just plain "sphinx" would be easier to use, but probably a bit confusing when coupled with the old sphinxsearch sphinx-XX packages..) I can take a look at actually doing this but wanted a sanity check from other porters first.. any feedback? (This isn't just about sphinx, we also need a way to properly handle the MODPY_BIN_SUFFIXed executables in a bunch of other python ports, but this seems a good a place as any to start with because it's already causing problems for porters, and when we get it to work it would act as a template to use for others..)
Re: sphinx and sphinx
Can’t we just get rid of the python2 sphinx and keep only the python3 version? — Antoine > On 26 Jan 2020, at 22:06, Stuart Henderson wrote: > > There are two sphinxs: > > textproc/py-sphinx: "python documentation generator" > https://www.sphinx-doc.org/ > > textproc/sphinx: "free open-source SQL full-text search engine" > https://sphinxsearch.com/ > > The first is the one people usually want, the presence of textproc/sphinx > in itself causes some confusion (there's a comment in the port Makefile > but mistakes are still sometimes made with this). > > There's also a problem with the py2/3 versions of py-sphinx because the > executables are named sphinx- and sphinx--3 to avoid a > conflict; this causes problems for porters wanting to use the doc generator > that result in either pulling in an unwanted py2 dependency, or having to > patch or add symlinks to cope with the unexpected filename. > > A proposal in three parts: > > - Either drop textproc/sphinx (it's unmaintained in ports, hasn't been > updated in ports since 2015 despite regular upstream updates, and has no > other ports using it), or reimport it as databases/sphinxsearch to avoid > confusion. > > - Remove executables from py-sphinx and py3-sphinx > > - Either multipackage py3-sphinx or add a separate port, the relevant > package depending on py3-sphinx, and containing the executables, named > without MODPY_BIN_SUFFIX, i.e. sphinx-apidoc, sphinx-build etc. > Maybe name this something like sphinxdoc or sphinx-doc? (Just plain > "sphinx" would be easier to use, but probably a bit confusing when > coupled with the old sphinxsearch sphinx-XX packages..) > > I can take a look at actually doing this but wanted a sanity check from > other porters first.. any feedback? > > (This isn't just about sphinx, we also need a way to properly handle the > MODPY_BIN_SUFFIXed executables in a bunch of other python ports, but > this seems a good a place as any to start with because it's already > causing problems for porters, and when we get it to work it would act > as a template to use for others..) >
Re: sphinx and sphinx
On 2020/01/26 22:44, Antoine Jacoutot wrote: > Can’t we just get rid of the python2 sphinx and keep only the python3 > version? I had a bit of a look at this in Bucharest, some things were using it as an imported python module (with whichever python version they normally build with) and some as a script. Maybe it would work to change it so the executables are only in py3-sphinx (with no suffix). I think maybe it's a bit confusing to do this if people have to set dependencies manually and figure out which flavour to use, but I suppose we could abstract it into a new USE_SPHINX or MODULES=textproc/py-sphinx to make that easer.. > — > Antoine > > > On 26 Jan 2020, at 22:06, Stuart Henderson wrote: > > > > There are two sphinxs: > > > > textproc/py-sphinx: "python documentation generator" > > https://www.sphinx-doc.org/ > > > > textproc/sphinx: "free open-source SQL full-text search engine" > > https://sphinxsearch.com/ > > > > The first is the one people usually want, the presence of textproc/sphinx > > in itself causes some confusion (there's a comment in the port Makefile > > but mistakes are still sometimes made with this). > > > > There's also a problem with the py2/3 versions of py-sphinx because the > > executables are named sphinx- and sphinx--3 to avoid a > > conflict; this causes problems for porters wanting to use the doc generator > > that result in either pulling in an unwanted py2 dependency, or having to > > patch or add symlinks to cope with the unexpected filename. > > > > A proposal in three parts: > > > > - Either drop textproc/sphinx (it's unmaintained in ports, hasn't been > > updated in ports since 2015 despite regular upstream updates, and has no > > other ports using it), or reimport it as databases/sphinxsearch to avoid > > confusion. > > > > - Remove executables from py-sphinx and py3-sphinx > > > > - Either multipackage py3-sphinx or add a separate port, the relevant > > package depending on py3-sphinx, and containing the executables, named > > without MODPY_BIN_SUFFIX, i.e. sphinx-apidoc, sphinx-build etc. > > Maybe name this something like sphinxdoc or sphinx-doc? (Just plain > > "sphinx" would be easier to use, but probably a bit confusing when > > coupled with the old sphinxsearch sphinx-XX packages..) > > > > I can take a look at actually doing this but wanted a sanity check from > > other porters first.. any feedback? > > > > (This isn't just about sphinx, we also need a way to properly handle the > > MODPY_BIN_SUFFIXed executables in a bunch of other python ports, but > > this seems a good a place as any to start with because it's already > > causing problems for porters, and when we get it to work it would act > > as a template to use for others..) > > >
