FAQ
I am currently aware of the Module::Install-specific targets of
`make listdeps` (only what is needed to satisfy test/runtime prereqs)
`make listalldeps` (everything the metadata knows about)

There is the dzil alternative of:
`dzil listdeps` (everything)
`dzil listdeps --missing` (only what is needed for test/runtime)
`dzil authordeps` (and the kitchen sink, unclear whether --author or
--develop or both)
`dzil authordeps --missing` (only the defective kitchen sinks)


Are there other things out there targeting the same problem-domain? Is
there something approaching a "cross-tooling convention" ?

Cheers

Search Discussions

  • David Golden at Mar 1, 2016 at 9:15 pm
    cpanm had --scan-deps, though it's now listed as deprecated.

    And CPAN has plenty of these sorts of things, eg. Perl::PrereqScanner
    On Tue, Mar 1, 2016 at 3:43 PM, Peter Rabbitson wrote:

    I am currently aware of the Module::Install-specific targets of
    `make listdeps` (only what is needed to satisfy test/runtime prereqs)
    `make listalldeps` (everything the metadata knows about)

    There is the dzil alternative of:
    `dzil listdeps` (everything)
    `dzil listdeps --missing` (only what is needed for test/runtime)
    `dzil authordeps` (and the kitchen sink, unclear whether
    --author or --develop or both)
    `dzil authordeps --missing` (only the defective kitchen sinks)


    Are there other things out there targeting the same problem-domain? Is
    there something approaching a "cross-tooling convention" ?

    Cheers


    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Neil Bowers at Mar 1, 2016 at 9:21 pm

    cpanm had --scan-deps, though it's now listed as deprecated.

    And CPAN has plenty of these sorts of things, eg. Perl::PrereqScanner
    App::Midgen and the midgen script were designed to determine and list prereqs of different types, in the formats expected by various things:

      https://metacpan.org/release/App-Midgen
  • Peter Rabbitson at Mar 1, 2016 at 9:36 pm

    On 03/01/2016 10:14 PM, David Golden wrote:
    cpanm had --scan-deps, though it's now listed as deprecated.
    I didn't phrase my question correctly. What I am after is:

    Imagine you get a random checkout of some dist and/or extract a tarball.
    Aside from running `perl Makefile.PL` and visually checking what is
    missing, there is nothing semi-standard that will answer "what do I feed
    to | cpanm, so that prove -l will work".

    Hope this makes more sense.
  • David Golden at Mar 1, 2016 at 10:19 pm

    On Tue, Mar 1, 2016 at 4:35 PM, Peter Rabbitson wrote:

    Imagine you get a random checkout of some dist and/or extract a tarball.
    Aside from running `perl Makefile.PL` and visually checking what is
    missing, there is nothing semi-standard that will answer "what do I feed to
    cpanm, so that prove -l will work".
    cpanm --installdeps .

    You can do "cpan ." but it installs the module if tests succeed.



    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Peter Rabbitson at Mar 1, 2016 at 10:24 pm

    On 03/01/2016 11:19 PM, David Golden wrote:
    On Tue, Mar 1, 2016 at 4:35 PM, Peter Rabbitson wrote:

    Imagine you get a random checkout of some dist and/or extract a
    tarball. Aside from running `perl Makefile.PL` and visually
    checking what is missing, there is nothing semi-standard that will
    answer "what do I feed to | cpanm, so that prove -l will work".


    cpanm --installdeps .
    Yes I am aware of the above.

    Is there something for passive (non-installing) listing *besides* the
    Module::Install / Dzil examples I showed in the original email?
    Does Module::Build offer something similar?
    Or "that's about it" ?
  • David Golden at Mar 1, 2016 at 10:55 pm

    On Tue, Mar 1, 2016 at 5:23 PM, Peter Rabbitson wrote:

    Is there something for passive (non-installing) listing *besides* the
    Module::Install / Dzil examples I showed in the original email?
    Does Module::Build offer something similar?
    Or "that's about it" ?
    From a side email exchange with Peter, I offered this technique:

    $ perl -MCPAN::Meta -wle 'print for
    CPAN::Meta->load_file("MYMETA.json")->effective_prereqs->merged_requirements->required_modules'

    That's not what he means by his question, but I'm sharing it here so that
    it's findable in the list archives for posterity.

    I'll let Peter follow up with his own clarification of what he wants.

    David

    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Leon Timmermans at Mar 1, 2016 at 10:50 pm

    On Tue, Mar 1, 2016 at 10:35 PM, Peter Rabbitson wrote:

    I didn't phrase my question correctly. What I am after is:

    Imagine you get a random checkout of some dist and/or extract a tarball.
    Aside from running `perl Makefile.PL` and visually checking what is
    missing, there is nothing semi-standard that will answer "what do I feed to
    cpanm, so that prove -l will work".
    Hope this makes more sense.
    The first complication there is that our dependency resolution is
    inherently a two-phase process due to configure-requires. The second
    complication is that systems like dzil make it a three stage process (and
    possibly so do other systems). I agree a better way to deal with this would
    be nice, but I don't expect it to look like you want it to look.

    Leon
  • Olivier Mengué at Mar 1, 2016 at 11:41 pm

    2016-03-01 21:43 GMT+01:00 Peter Rabbitson <ribasushi@cpan.org>:

    Are there other things out there targeting the same problem-domain? Is
    there something approaching a "cross-tooling convention" ?

    cpanfile-dump

    https://metacpan.org/pod/distribution/Module-CPANfile/script/cpanfile-dump
  • Peter Rabbitson at Mar 2, 2016 at 9:40 am

    On 03/01/2016 09:43 PM, Peter Rabbitson wrote:
    I am currently aware of the Module::Install-specific targets of
    `make listdeps` (only what is needed to satisfy test/runtime
    prereqs)
    `make listalldeps` (everything the metadata knows about)

    There is the dzil alternative of:
    `dzil listdeps` (everything)
    `dzil listdeps --missing` (only what is needed for test/runtime)
    `dzil authordeps` (and the kitchen sink, unclear whether
    --author or --develop or both)
    `dzil authordeps --missing` (only the defective kitchen sinks)


    Are there other things out there targeting the same problem-domain? Is
    there something approaching a "cross-tooling convention" ?
    To summarize after the false-start yesterday:

    The use case in question is that I am preparing to replace
    Module::Install's `perl Makefile.PL && make listdeps` idiom with a
    pure-EUMM-based "something else".

    I was looking for available prior art in order to converge on *naming*.
    Given further searching and the replies in this thread, I am simply
    going to recreate the 'listdep' target more-or-less-as-is.

    Thanks for the thoughts!
    Cheers
  • Olivier Mengué at Mar 2, 2016 at 11:18 am

    2016-03-02 10:39 GMT+01:00 Peter Rabbitson <ribasushi@cpan.org>:

    The use case in question is that I am preparing to replace
    Module::Install's `perl Makefile.PL && make listdeps` idiom with a
    pure-EUMM-based "something else".
    I was looking for available prior art in order to converge on *naming*.
    Given further searching and the replies in this thread, I am simply going
    to recreate the 'listdep' target more-or-less-as-is.
    Is 'listdep' just a typo or will we really have both 'listdeps' and
    'listdep'?

    Thanks for the thoughts!
    Cheers
  • Peter Rabbitson at Mar 2, 2016 at 11:20 am

    On 03/02/2016 12:18 PM, Olivier Mengué wrote:
    Is 'listdep' just a typo or will we really have both 'listdeps' and
    'listdep'?
    Typo ;)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedMar 1, '16 at 8:44p
activeMar 2, '16 at 11:20a
posts12
users5
websitecpan.org

People

Translate

site design / logo © 2018 Grokbase