Use of nbconvert, nbconvert-core for downstreams?

[bollwyvl]

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 using nbconvert 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 are noarch.

However, users of (new) platforms without pandoc builds will get 6.4.5_*_0, even if later versions come along.

Ideas

• encourage use of nbconvert-core for:
  • noarch downstreams consuming it as a library
    • e.g. jupyter_server
• encourage use of nbconvert for:
  • downstreams that explicitly make use of latex/pandoc features
    • e.g. ???
• encourage choosing between them with selectors
  • non-noarch downstreams
    • e.g. jupyter already special-cases qtconsole

Alternatives

• it is possible to do some tricks with conda_build_config.yaml to achieve multiple noarch: python packages
  • can't really recommend in this case, as the behavior of these can be rather tricky to anticipate... and might not work at all, as the solver "savings" of not installing pandoc, even if available, can "outweigh" the higher build number
• go back to non-noarch, but that puts us back into every python and platform migration

[minrk]

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).

[bryan-hunt]

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.

[bollwyvl]

Some objective information, as best as i can tell:

• downloading the 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 API

I 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.

[bryan-hunt]

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.