{"action":"created","issue":{"url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/issues/112","repository_url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta","labels_url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/issues/112/labels{/name}","comments_url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/issues/112/comments","events_url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/issues/112/events","html_url":"https://github.com/Perl-Toolchain-Gang/CPAN-Meta/issues/112","id":162029798,"number":112,"title":"SPEC: create standard key for communicating dynamic dependencies to vendors/packagers","user":{"login":"xdg","id":7625322,"avatar_url":"https://avatars.githubusercontent.com/u/7625322?v=3","gravatar_id":"","url":"https://api.github.com/users/xdg","html_url":"https://github.com/xdg","followers_url":"https://api.github.com/users/xdg/followers","following_url":"https://api.github.com/users/xdg/following{/other_user}","gists_url":"https://api.github.com/users/xdg/gists{/gist_id}","starred_url":"https://api.github.com/users/xdg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xdg/subscriptions","organizations_url":"https://api.github.com/users/xdg/orgs","repos_url":"https://api.github.com/users/xdg/repos","events_url":"https://api.github.com/users/xdg/events{/privacy}","received_events_url":"https://api.github.com/users/xdg/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/labels/spec","name":"spec","color":"fad8c7"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":21,"created_at":"2016-06-23T21:39:59Z","updated_at":"2016-06-29T10:06:59Z","closed_at":null,"body":"From discussion with @xsawyerx, we have a gap in META when dynamic config is true (or missing) that vendors or packagers have no way to know what might be included in any standard way.  They have to run the .PL file or read it in order to discover it.\r\n\r\nWe could have a meta field that provides module names as keys and data structures with version and rationale that explains the conditions for a dynamic dependency (in a human-readable way).\r\n\r\nEg.\r\n```\r\ndynamic_prereqs => {\r\n    runtime => {\r\n        requires => {\r\n            \"Win32::Foo::Bar\" => {\r\n                version => \"1.23\",\r\n                condition => \"Required on Win32\",\r\n            },\r\n            \"Wibble::XS\" => {\r\n                version => \"0\",\r\n                condition => \"needs a compiler\",\r\n                use => \"speed\"\r\n            },\r\n            \"Devel::ReallyAnnoying\" => {\r\n                version => \"0.17\",\r\n                condition => \"perls before 5.14\",\r\n                use => \"avoid RT#666\",\r\n            },\r\n            \"Data::ReallyOptional::Foo\" => {\r\n                version => \"0\",\r\n                condition => \"during runtime, if installed\",\r\n                use => \"prettier output\",\r\n            },\r\n        }\r\n    }\r\n}\r\n\r\nThis would help vendors decide on what environment is necessary to run the .PL file to get certain dynamic dependencies configured. It would also allow metadata sites like MetaCPAN to provide some information about what non-canonical requirement might possibly be required at configuration time."},"comment":{"url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/issues/comments/229314326","html_url":"https://github.com/Perl-Toolchain-Gang/CPAN-Meta/issues/112#issuecomment-229314326","issue_url":"https://api.github.com/repos/Perl-Toolchain-Gang/CPAN-Meta/issues/112","id":229314326,"user":{"login":"kentfredric","id":44790,"avatar_url":"https://avatars.githubusercontent.com/u/44790?v=3","gravatar_id":"","url":"https://api.github.com/users/kentfredric","html_url":"https://github.com/kentfredric","followers_url":"https://api.github.com/users/kentfredric/followers","following_url":"https://api.github.com/users/kentfredric/following{/other_user}","gists_url":"https://api.github.com/users/kentfredric/gists{/gist_id}","starred_url":"https://api.github.com/users/kentfredric/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kentfredric/subscriptions","organizations_url":"https://api.github.com/users/kentfredric/orgs","repos_url":"https://api.github.com/users/kentfredric/repos","events_url":"https://api.github.com/users/kentfredric/events{/privacy}","received_events_url":"https://api.github.com/users/kentfredric/received_events","type":"User","site_admin":false},"created_at":"2016-06-29T10:06:59Z","updated_at":"2016-06-29T10:06:59Z","body":"I'm just going to dump a non-JSON alternative solution to poison your mind with, because personally, inventing a new turing complete language when everyone is going to have Perl at the ready anyway ( and will *need* it anyway for an implementation of this new language ):\r\n\r\nInspired by CPANFile syntax hybridised with syntax from @karenetheridge's [DZP:DynamicPrereqs](https://metacpan.org/pod/Dist::Zilla::Plugin::DynamicPrereqs#SYNOPSIS).\r\n\r\n```perl\r\nfor \"Additional Win32 Support\" => sub {\r\n      condition sub { $^O =~ qr/Win32/ };\r\n      requires \"Win32::Foo::Bar\" => \"1.23\";\r\n};\r\nfor \"Acceleration via Wibble::XS\" => sub {\r\n      condition \\&has_compiler;\r\n      requires \"Wibble::XS\";\r\n};\r\nfor \"perls before 5.14, avoid RT#666\" => sub {\r\n     condition => sub { $] <= 5.14 };\r\n     requires \"Devel::ReallyAnnoying\" => \"0.17\";\r\n};\r\n\r\nfor \"Prettier output, optional\" => sub  {\r\n       condition => sub { has_module(\"Data::ReallyOptional::Foo\", \">=0\"); };\r\n       on \"test\" => sub {\r\n           recommends \"Data::ReallyOptional::Foo\";\r\n       };\r\n};\r\n```\r\n\r\nThis structure can be both statically extracted to produce a non-executable textual description that a Vendor can read without needing to know any deep magic, doesn't require them to learn a new language.\r\n\r\nAnd the structure itself can also be directly executable by installer toolchains. ( because the \"condition\" block simply associates a reference to the sub, which can then be executed as needed )\r\n\r\nThe non-executable descriptive parts of this can be statically extracted and stuffed in a JSON file somewhere as \"information only\" usages similar to how cpanfile currently serves as a staging ground for META.json."}}
{"actor":{"display_login":"kentfredric"}}