Parse optional dependencies

[ocefpaf]

It would be nice to get the optional dependencies either as a comment or in a different block.

The reason for that is b/c some conda-forge package chose to ship optional dependencies other did not, so we need a way to guide maintainers to what needs to get updated.

As an example see the current dask recipe vs what grayskull produces.

[marcelotrevisani]

Should we add those optional dependencies as run_constrain?

[ocefpaf]

I'm not sure that is the best way to support it. I thought about something like a top level comment with the extra names and the list of the "extra" dependencies. Getting those names may be tricky though. For example, this is the run section of the requests recipe created with grayskull

requirements:
  host:
    - python
    - pip
  run:
    - certifi >=2017.4.17
    - chardet >=3.0.2,<4
    - idna >=2.5,<3
    - python !=3.0,!=3.1,!=3.2,!=3.3,!=3.4
    - urllib3 >=1.21.1,<1.26,!=1.25.0,!=1.25.1

The extras section has:

    extras_require={
        'security': ['pyOpenSSL >= 0.14', 'cryptography>=1.3.4'],
        'socks': ['PySocks>=1.5.6, !=1.5.7'],
    },

That is ignored by grasyskull at the moment but maybe we could do:

 run:
   - certifi >=2017.4.17
   - chardet >=3.0.2,<4
   - idna >=2.5,<3
   - python !=3.0,!=3.1,!=3.2,!=3.3,!=3.4
   - urllib3 >=1.21.1,<1.26,!=1.25.0,!=1.25.1
   # security
   - pyopenssl >= 0.14
   - cryptography>=1.3.4
   # socks 
   - pysocks>=1.5.6,!=1.5.7

[marcelotrevisani]

We can try to add something like that, that should be interesting to do

The only problem is, those names may change very much, those "socks", "security" and so on
I also saw in some setup.py some packages which do not have any name

[ocefpaf]

The names are in the "spec" in a way, they keys of the extras dict.

[woutdenolf]

We could achieved this with a meta package with different outputs (see for example matplotlib)

pypi	conda
pip install mypackage	conda install mypackage
pip install mypackage[option1]	conda install mypackage-option1
pip install mypackage[option2]	conda install mypackage-option2
pip install mypackage[option1,option2]	conda install mypackage-option1 mypackage-option2

This can a done in a single recipe

{% set name = "mypackage" %}
{% set version = "1.0.0" %}

package:
  name: {{ name|lower }}-meta
  version: {{ version }}

source:
  ...

outputs:
  - name: {{ name|lower }}
    build:
      ...
    requirements:
      ...
    test:
      ...
  - name: {{ name|lower }}-option1
    build:
      ...
    requirements:
      run:
        {{ name|lower }}
        ...
      ...
    test:
      ...
  - name: {{ name|lower }}-option2
    build:
      ...
      run:
        {{ name|lower }}
        ...
      ...
    test:
      ...

about:
  ...

extra:
  ...

The dependency of mypackage in mypackage-option. needs to be pinned I suppose.

In the matplotlib example they have {{ pin_subpackage('matplotlib-base', max_pin="x.x.x") }}. Maybe this is some magic to pin to the version of this recipe?

Edit: yes that seems to be the case. For example if the version is 1.6.34, that pinning expression would evaluate to >=1.6.34,<1.6.35. Perhaps we should just pin to {{ name|lower }}={{ version }} instead?

[woutdenolf]

@marcelotrevisani I'll work on my proposal for optional dependencies soon.

[marcelotrevisani]

added in #341

[bjudkewitz]

This seems to work for projects using setup.py/setup.cfg, but not yet for pyproject.toml. See #506