Open bollwyvl opened 2 years ago
I think for the most part, depending on nbconvert-core is right as a package dependency unless it specifically uses pandoc (e.g. jupyter-server depends on -core, but maybe nbsphinx still depends on nbconvert).
One item of note for the nbconvert package is that it is marked as BSD licensed but it has a hard dependency on pandoc which is GPL without a linking exception. Overall it seems like there is a license propagation error.
Some objective information, as best as i can tell:
nbconvert
package distribution (from pypi or conda-forge, including any metapackages) does not include pandoc
(in source or compiled form)nbconvert
invokes the pandoc
via subprocess and communicates over its published APII am not qualified to assess whether those two pieces of information mean this feedstock is in violation, but there is some received wisdom which might provide a more precise definition.
The issue here is that conda as a framework doesn't offer the same extras mechanisms as pip does - nbconvert as a package requires nbconvert-pandoc which requires pandoc. Yes this is a gray area when it comes to GPL and I also am no expert in the nuance. When it comes to things like constructor however the result is a distributed application that includes a GPL'd package. Thus in the long run it would make the most sense for downstream packages to call out the subpackages explicitly for the features they require which I think is confirming the bullet points you present here as being the proper and best.
nbconvert: https://github.com/conda-forge/nbconvert-feedstock/blob/main/recipe/meta.yaml#L28-L37
nbconvert-pandoc: https://github.com/conda-forge/nbconvert-feedstock/blob/main/recipe/meta.yaml#L128-L139
As for license promotion - would it likely encourage people to use the proper subpackage? Likely. Is it strictly necessary for licensing terms given how pandoc is being used? Probably not.
Comment:
Question
How might we best balance
nbconvert
builds and features for all users?Problem
With #47, most users that directly install
nbconvert
will see no change, and will continue to see updates as they are released, and have access to pandoc-driven features. If usingnbconvert
as a general purpose CLI tool, this is probably the right behavior.New platforms/pythons will not require new builds of any of the
nbconvert(-*)
packages, because all of them arenoarch
.However, users of (new) platforms without
pandoc
builds will get6.4.5_*_0
, even if later versions come along.Ideas
nbconvert-core
for:noarch
downstreams consuming it as a libraryjupyter_server
nbconvert
for:noarch
downstreamsjupyter
already special-casesqtconsole
Alternatives
conda_build_config.yaml
to achieve multiplenoarch: python
packagespandoc
, even if available, can "outweigh" the higher build numbernoarch
, but that puts us back into every python and platform migration