Grokbase › Groups › Perl › cpan-workers › October 2009
FAQ
21. Formalize optional_features

Proposal:

Optional features: is supported in META.yml, but it requires a lot of
manual intervention and trickery to make it work. And it is very poorly
documented. (Tux)

Comments:

* Not all YAML parsers parse that structure the same way, so the order of
this section inside META.yml is vital (still :()

* I for one would be happy to see optional_features: removed entirely,
since actual actions resulting from this information only apply in the
human-in-the-loop cases. It also locks downstream packagers into either
supporting it or not supporting it, none of THEIR users actually get a
choice (AdamKennedy).

* optional_features may be used automatically. This is already implemented
in CPAN.pm in conjunction with the "features" key of distroprefs.
(SlavenRezic)

* optional_features can be however quite practical to people with source
based distributions as long as they're done properly. Gentoo tends to
match each optional_feature to a corresponding 'use' flag. ( Set it and
forget it ). (kentnl)

* The example of optional_features express a optional 'feature' as having
'requires' prerequisites as an 'alternative' to specifying 'recommends'.
But what would 'build_requires' within an 'optional_features' entry mean?
Is 'recommends' allowed within 'optional_features'? What should
CPAN(PLUS) do for each of the prerequisite types if found under an
optional_feature entry? (Dagolden)

Search Discussions

  • Ricardo Signes at Oct 9, 2009 at 1:16 pm ⇧
    * David Golden [2009-10-09T07:51:56]
    21. Formalize optional_features

    Proposal:

    Optional features: is supported in META.yml, but it requires a lot of
    manual intervention and trickery to make it work. And it is very poorly
    documented. (Tux)
    Either ditch optional_features or make its contents reflect the top-level
    (build)_(requires)-like stuff.

    Mostly I am opposed to optional features.

    --
    rjbs
  • Graham Barr at Oct 9, 2009 at 2:16 pm ⇧

    On Oct 9, 2009, at 8:15 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:51:56]
    21. Formalize optional_features

    Proposal:

    Optional features: is supported in META.yml, but it requires a lot of
    manual intervention and trickery to make it work. And it is very
    poorly
    documented. (Tux)
    Either ditch optional_features or make its contents reflect the top-
    level
    (build)_(requires)-like stuff.

    Mostly I am opposed to optional features.
    Agreed. I think adding the ability to add a description field to
    suggests/recommends
    so an author can describe why they are suggested would be better

    Graham.
  • Steffen Mueller at Oct 9, 2009 at 2:33 pm ⇧

    David Golden wrote:
    21. Formalize optional_features
    I've had more hassle than luck with optional features, but since some
    people make valid use of it, I'd be (slightly) against removal.

    +1 to formalization

    Steffen
  • David E. Wheeler at Oct 9, 2009 at 6:22 pm ⇧

    On Oct 9, 2009, at 7:33 AM, Steffen Mueller wrote:

    I've had more hassle than luck with optional features, but since
    some people make valid use of it, I'd be (slightly) against removal.

    +1 to formalization
    +1 I've stayed away from optional_features because of the hinky extra
    library that Module::Build creates when you use it. Too weird.

    Best,

    David
  • David Golden at Oct 9, 2009 at 8:32 pm ⇧

    On Fri, Oct 9, 2009 at 7:51 AM, David Golden wrote:
    21. Formalize optional_features

    Proposal:

    Optional features: is supported in META.yml, but it requires a lot of
    manual intervention and trickery to make it work. And it is very poorly
    documented. (Tux)
    I'm for doing something, either formalizing or removing. I think it's
    a mess as currently exists.

    It would be nice to allow "Do you want to add support for blah?"
    questions during install rather than a list of scads of modules to
    install, but that could all be done in *.PL as dynamic configuration.
    I don't see why the bundles really need to be listed in META.

    -- David
  • Slaven Rezic at Nov 1, 2009 at 7:27 pm ⇧

    David Golden wrote:
    On Fri, Oct 9, 2009 at 7:51 AM, David Golden wrote:
    21. Formalize optional_features

    Proposal:

    Optional features: is supported in META.yml, but it requires a lot of
    manual intervention and trickery to make it work. And it is very poorly
    documented. (Tux)
    I'm for doing something, either formalizing or removing. I think it's
    a mess as currently exists.

    It would be nice to allow "Do you want to add support for blah?"
    questions during install rather than a list of scads of modules to
    install, but that could all be done in *.PL as dynamic configuration.
    I don't see why the bundles really need to be listed in META.
    Because that's the only way to do automatic installation of optional
    features possible, in a standardized way. Currently I may say that I
    want the feature "fulltext_search" for Tk::Pod via a distropref file.
    Theoretically I could also list the required dependencies for fulltext
    search in the distropref file, but what if some day Tk::Pod's fulltext
    feature is implemented using other modules?

    I vote for formalization.

    Regards,
    Slaven
  • Zbigniew Lukasiak at Nov 2, 2009 at 9:25 am ⇧

    On Sun, Nov 1, 2009 at 8:27 PM, Slaven Rezic wrote:
    David Golden wrote:
    On Fri, Oct 9, 2009 at 7:51 AM, David Golden wrote:

    21. Formalize optional_features

    Proposal:

    Optional features: is supported in META.yml, but it requires a lot of
    manual intervention and trickery to make it work. And it is very poorly
    documented. (Tux)
    I'm for doing something, either formalizing or removing.  I think it's
    a mess as currently exists.

    It would be nice to allow "Do you want to add support for blah?"
    questions during install rather than a list of scads of modules to
    install, but that could all be done in *.PL as dynamic configuration.
    I don't see why the bundles really need to be listed in META.
    Because that's the only way to do automatic installation of optional
    features possible, in a standardized way. Currently I may say that I want
    the feature "fulltext_search" for Tk::Pod via a distropref file.
    Theoretically I could also list the required dependencies for fulltext
    search in the distropref file, but what if some day Tk::Pod's fulltext
    feature is implemented using other modules?

    I vote for formalization.
    I don't know the history of this, but - risking that I'll add
    something already covered - I would propose that if optional features
    are to be formalized - then they should be allowed to appear in
    'require_*'. Otherwise optional features lead to much chaos with
    packages relying on them but not being able to specify that.

    Cheers,
    Zbigniew Lukasiak
    http://brudnopis.blogspot.com/
    http://perlalchemy.blogspot.com/
  • David Golden at Nov 2, 2009 at 11:28 am ⇧

    On Mon, Nov 2, 2009 at 4:25 AM, Zbigniew Lukasiak wrote:
    I don't know the history of this, but - risking that I'll add
    something already covered - I would propose that if optional features
    are to be formalized - then they should be allowed to appear in
    'require_*'.  Otherwise optional features lead to much chaos with
    packages relying on them but not being able to specify that.
    Ricardo and I iterated through the implications and semantics last night on IRC.

    In short, optional_features serve two purposes: (a) they define a set
    of requirements such that if the "requires" portion is satisfied, then
    a feature is considered "available" (whatever that means); (b) they
    define a set of requirements that are merged to the main requirements
    if an install tool chooses to do so (by prompting the user or other
    means).

    What I think you're asking about is beyond the scope of this META spec
    round. You'd like a way to have Distribution X to say that it wants
    distribution Y + distribution Y's optional feature Z. As others have
    said, a better way for features to be packaged is via a separate
    distribution. For example, Foo-Bar-1.23 has optional feature "wibble"
    which requires Foo::Bar::Wibble, which comes in the
    Foo-Bar-Wibble-1.23 distribution. In Foo-Bar-Wibble, all sorts of
    other modules could be required.

    Then, if your module Really::Awesome needs the "wibble" feature, you
    just say it requires Foo::Bar and Foo::Bar::Wibble and it all just
    works.

    On reflection, a note about that should probably be added to the
    omnibus prereq branch that describes optional_features.

    http://github.com/dagolden/cpan-meta-spec/tree/prereq-omnibus

    -- David
  • Adam Kennedy at Nov 2, 2009 at 10:52 pm ⇧
    I still think I prefer Zefram's approach, remove optional_features entirely.

    Adam K
    On Mon, Nov 2, 2009 at 10:27 PM, David Golden wrote:
    On Mon, Nov 2, 2009 at 4:25 AM, Zbigniew Lukasiak wrote:
    I don't know the history of this, but - risking that I'll add
    something already covered - I would propose that if optional features
    are to be formalized - then they should be allowed to appear in
    'require_*'.  Otherwise optional features lead to much chaos with
    packages relying on them but not being able to specify that.
    Ricardo and I iterated through the implications and semantics last night on IRC.

    In short, optional_features serve two purposes: (a) they define a set
    of requirements such that if the "requires" portion is satisfied, then
    a feature is considered "available" (whatever that means); (b) they
    define a set of requirements that are merged to the main requirements
    if an install tool chooses to do so (by prompting the user or other
    means).

    What I think you're asking about is beyond the scope of this META spec
    round.  You'd like a way to have Distribution X to say that it wants
    distribution Y + distribution Y's optional feature Z.  As others have
    said, a better way for features to be packaged is via a separate
    distribution.  For example, Foo-Bar-1.23 has optional feature "wibble"
    which requires Foo::Bar::Wibble, which comes in the
    Foo-Bar-Wibble-1.23 distribution.  In Foo-Bar-Wibble, all sorts of
    other modules could be required.

    Then, if your module Really::Awesome needs the "wibble" feature, you
    just say it requires Foo::Bar and Foo::Bar::Wibble and it all just
    works.

    On reflection, a note about that should probably be added to the
    omnibus prereq branch that describes optional_features.

    http://github.com/dagolden/cpan-meta-spec/tree/prereq-omnibus

    -- David
  • David E. Wheeler at Nov 2, 2009 at 11:06 pm ⇧

    On Nov 2, 2009, at 2:51 PM, Adam Kennedy wrote:

    I still think I prefer Zefram's approach, remove optional_features
    entirely.
    +1

    David
  • Shlomi Fish at Nov 4, 2009 at 7:17 am ⇧

    On Tuesday 03 Nov 2009 01:06:50 David E. Wheeler wrote:
    On Nov 2, 2009, at 2:51 PM, Adam Kennedy wrote:
    I still think I prefer Zefram's approach, remove optional_features
    entirely.
    +1
    +1 too. I hate optional_features with a passion.

    Regards,

    Shlomi Fish
    David
    --
    -----------------------------------------------------------------
    Shlomi Fish http://www.shlomifish.org/
    Parody on "The Fountainhead" - http://shlom.in/towtf

    Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
  • Slaven Rezic at Nov 3, 2009 at 11:50 pm ⇧

    Adam Kennedy wrote:
    I still think I prefer Zefram's approach, remove optional_features entirely.
    I would rather get rid of "suggests" and "recommends". optional_features
    is not that different from these both, but it has a name and a
    description. I'd rather pick the feature "fulltext_search" than follow
    the recommended prereq "Text::English".
    Adam K
    On Mon, Nov 2, 2009 at 10:27 PM, David Golden wrote:
    On Mon, Nov 2, 2009 at 4:25 AM, Zbigniew Lukasiak wrote:
    I don't know the history of this, but - risking that I'll add
    something already covered - I would propose that if optional features
    are to be formalized - then they should be allowed to appear in
    'require_*'. Otherwise optional features lead to much chaos with
    packages relying on them but not being able to specify that.
    Ricardo and I iterated through the implications and semantics last night on IRC.

    In short, optional_features serve two purposes: (a) they define a set
    of requirements such that if the "requires" portion is satisfied, then
    a feature is considered "available" (whatever that means); (b) they
    define a set of requirements that are merged to the main requirements
    if an install tool chooses to do so (by prompting the user or other
    means).

    What I think you're asking about is beyond the scope of this META spec
    round. You'd like a way to have Distribution X to say that it wants
    distribution Y + distribution Y's optional feature Z. As others have
    said, a better way for features to be packaged is via a separate
    distribution. For example, Foo-Bar-1.23 has optional feature "wibble"
    which requires Foo::Bar::Wibble, which comes in the
    Foo-Bar-Wibble-1.23 distribution. In Foo-Bar-Wibble, all sorts of
    other modules could be required.

    Then, if your module Really::Awesome needs the "wibble" feature, you
    just say it requires Foo::Bar and Foo::Bar::Wibble and it all just
    works.

    On reflection, a note about that should probably be added to the
    omnibus prereq branch that describes optional_features.

    http://github.com/dagolden/cpan-meta-spec/tree/prereq-omnibus

    -- David
  • Zefram at Oct 11, 2009 at 7:40 am ⇧

    David Golden wrote:
    Optional features: is supported in META.yml, but it requires a lot of
    manual intervention and trickery to make it work. And it is very poorly
    documented. (Tux)
    Get rid of it. I think each such feature should be reified as a module,
    which one can declare as a dependency of another distro in the normal
    manner.

    -zefram

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:52a
activeNov 4, '09 at 7:17a
posts14
users10
websitecpan.org

10 users in discussion

David Golden: 3 posts Slaven Rezic: 2 posts David E. Wheeler: 2 posts Zbigniew Lukasiak: 1 post Graham Barr: 1 post Adam Kennedy: 1 post Steffen Mueller: 1 post Zefram: 1 post Ricardo Signes: 1 post Shlomi Fish: 1 post

Content

People

Support

Translate

site design / logo © 2021 Grokbase