required or contradindicated OS

[karenetheridge]

It would be useful to have a standard way in metadata to specify positive or negative OS requirements.

re #toolchain 2013-07-10/11:

19:44 < garu> is there a documented standard way of telling cpan that a certain dist is unsupported on that OS?
19:45 < garu> xdg: cpan::reporter just parses the harness output looking for either 'No support for OS' or 'OS unsupported'
19:45 < garu> (from any .t file)
19:45 < garu> but that seems... fragile :)
19:49  * garu wonders if there is a $city consensus on this somewhere
20:01 <@ether> garu: Dist::Zilla::Plugin::AssertOS
20:01 <@ether> or copy what it does, via Devel::CheckOS, if you don't use Dist::Zilla
20:02 <@Getty> somethingsomething autodie::exception somethingsomething 5.18
20:03 <@Getty> somethingsomething cpanm autodie::exception => 2.20 somethingsomething perl -Mautodie::exception\ 999 => you have 2.13 somethingsomething... package Path::Tiny; use autodie::exception 2.14;... hmpf...somethingsomething
20:03 < crazed-> somethingsomethingelse no problems with it here at all somethingelse
20:06 < garu> ether: so... "no"? :)
20:07 < garu> ether: oh, I don't want to use it! I just want to know if there's a standard for that
20:07 < garu> ether: since I'm maintaining cpan::reporter and it checks for that, I wanted to make sure this is the proper way (or if there is a proper way, for that matter) :)

11:45 <@xdg> ether, open a ticket for it on CPAN-Meta and whenever we open up a CFP for v3,                 
             we'll get it discussed                                                                         
11:46 <@xdg> ether, for reference, the prior proposals can be seen here:                                    
             http://www.dagolden.com/index.php/519/list-of-cpan-meta-spec-proposals/                        
11:46 <+dipsy> [ List of CPAN Meta Spec Proposals | David Golden ]                                          
11:46 <@xdg> And the results here:                                                                          
             http://www.dagolden.com/index.php/538/summary-of-cpan-meta-spec-public-discussions/            
11:46 <+dipsy> urgh. long url. Try http://tinyurl.com/laxodpj                                               

[dagolden]

Keep in mind that "NA: platform not supported" has a very loose definition of "platform". And meta needs to be careful not to require a turing complete language to do all the OS logic. :-)

[karenetheridge]

Indeed! I was thinking of a syntax that could say "only things in this list will work" or "things in this list are disallowed", where "thing" is something like what is in $Config{osname}.

See also: https://metacpan.org/pod/Devel::AssertOS

[Leont]

Yeah, I've had requirements like "linux or FreeBSD or darwin 9+". I suspect this will only help in a limited set of circumstances.

[dagolden]

That said, 90%+ of cases will be "Unix" vs "Not Unix".

[Leont]

That said, 90%+ of cases will be "Unix" vs "Not Unix".

More like "Unix" vs "Windows", with VMS being ignored and anything else no longer existing in a meaningful sense.

[dagolden]

More like "Unix" vs "Windows", with VMS being ignored and anything else no longer existing in a meaningful sense.

Well, yeah. I originally wrote that, but thought that usually the restriction of "won't work on Windows" also means "won't work on VMS either".

[Leont]

Well, yeah. I originally wrote that, but thought that usually the restriction of "won't work on Windows" also means "won't work on VMS either".

True, but Win32::* won't work on VMS either. Actually, I suspect quite a bit of CPAN doesn't.

[rfdrake]

I don't think anyone is running a smoke tester for VMS, so it's an impossible target for most people unless they run the box themselves. A long time ago I wanted to put VMS on a Multia so I signed up for the compaq user's group to get a "free educational edition." They sent me a CD and no license and signed me up for permanent mailing lists.

That said, I was looking for this feature because I've had to blacklist Win32 before in some of my modules. I realized that having smoke testers download and attempt to build them is a waste of I/O.

Yes, that's optimizing somebody elses problem, or a tragedy of the commons, but it seems like it might be nice to be able to pull the META first and ignore it if the OS is wrong.

[Leont]

Quite frankly, the only way forward is for someone to add some x_os_hints field to their meta and add support to smokers. It only takes two patches…