Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2014-03-05

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:30 klapperl joined #metacpan
06:29 [Sno] joined #metacpan
07:07 dpetrov_ joined #metacpan
07:41 alh joined #metacpan
07:41 neilb joined #metacpan
08:47 neilb joined #metacpan
09:10 neilb joined #metacpan
11:43 chansen joined #metacpan
11:43 diegok joined #metacpan
11:43 michael joined #metacpan
11:43 omega joined #metacpan
11:43 avenj joined #metacpan
11:43 ilmari joined #metacpan
11:43 tobyink joined #metacpan
11:43 gry joined #metacpan
11:43 mattp_ joined #metacpan
11:43 Ralesk joined #metacpan
11:43 mo_ joined #metacpan
11:43 alh joined #metacpan
11:43 dpetrov_ joined #metacpan
11:43 kentnl joined #metacpan
11:43 genehack joined #metacpan
11:43 tianon joined #metacpan
11:43 Seveas joined #metacpan
11:43 priodev joined #metacpan
11:43 alnewkirk joined #metacpan
11:43 ribasushi joined #metacpan
11:43 devin joined #metacpan
11:43 GumbyNET5 joined #metacpan
11:43 GumbyNET7 joined #metacpan
11:43 t0m joined #metacpan
11:43 andrefs joined #metacpan
11:43 rGeoffrey_zzz joined #metacpan
11:43 jibsheet joined #metacpan
11:43 haarg joined #metacpan
11:43 BooK joined #metacpan
11:43 rwstauner joined #metacpan
11:43 wreis joined #metacpan
11:43 berekuk joined #metacpan
11:43 charsbar___ joined #metacpan
11:43 shibayu36 joined #metacpan
11:43 ranguard_ joined #metacpan
11:45 lestrrat joined #metacpan
11:45 oalders joined #metacpan
11:45 klapperl joined #metacpan
11:45 fernando joined #metacpan
11:45 neilb joined #metacpan
11:45 ether joined #metacpan
11:45 b_jonas joined #metacpan
11:45 sivoais joined #metacpan
11:45 gugod joined #metacpan
11:45 mtj joined #metacpan
11:45 danaj joined #metacpan
11:45 Khisanth joined #metacpan
11:45 daxim joined #metacpan
11:45 punytan joined #metacpan
11:45 ivan joined #metacpan
11:45 trs joined #metacpan
11:45 cooper joined #metacpan
11:45 rafl joined #metacpan
11:45 hanekomu joined #metacpan
11:45 bricas joined #metacpan
11:45 mdk joined #metacpan
11:45 tokuhirom joined #metacpan
11:45 celogeek joined #metacpan
11:45 nuba joined #metacpan
11:45 cjm joined #metacpan
11:45 ingy joined #metacpan
11:45 idn joined #metacpan
11:45 dpetrov joined #metacpan
11:45 Mithaldu joined #metacpan
12:05 rashi joined #metacpan
13:46 clintongormley joined #metacpan
13:47 clintongormley heya all, to mark a module as deprecated, i should just add it into the name and add a big DEPRECATED warning in the DESCRIPTION?  Anything else?
13:48 rwstauner I suggest putting it in the abstract
13:48 clintongormley yep
13:48 rwstauner like =head1 NAME \n \n ES - Deprecated \n \n
13:48 clintongormley sorry, that's want i meant by name
13:48 rwstauner gotcha
13:48 rwstauner that way it shows up pretty much everywhere
13:48 clintongormley cool
13:48 clintongormley thanks rwstauner
13:49 rwstauner ;-)
14:44 Talina_ joined #metacpan
15:42 genehack joined #metacpan
16:09 talina__ joined #metacpan
17:09 bowtie joined #metacpan
17:23 rashi joined #metacpan
17:29 [Sno] joined #metacpan
17:31 kentnl ether: actually, might want to tack that on to your lyon talking point list, I don't know of a formal way to mark anything deprecated in META.*, there's only POD side conventions
17:33 ether good point
17:33 ether there's release status = stable/testing right now; perhaps make that a trinary? or a separate flag
17:40 kentnl I'm feeling it should be independent atm, because stability is a function of the release ( ie: Arity = 1 ), but deprecatedness is a function of the dist ( ie: Arity = all N )
17:41 kentnl Though thats probably one reason why not to include it perhaps, because its extending beyond the scope of the meta it pertains to *shrug*
17:41 kentnl I can see however  deprecated => { Module::Name } being of use though
17:42 kentnl ie: "In this distribution, at this release, the following modules are no longer recommended to be used"
17:42 kentnl there's less temporal inference there.
17:44 user_8665 joined #metacpan
17:46 kentnl just the "property of this release" vs "Property of all releases" is something that might confuse somebody really.
17:46 kentnl Would hate for people to go "well, I'll just not upgrade then, and then it wont be deprecated!" ;)
17:53 ether added: https://github.com/Perl-Toolchain-Gang/CPAN-Meta/issues/50
17:53 dipsy [ spec: flag to indicate distribution deprecation status · Issue #50 · Perl-Toolchain-Gang/CPAN-Meta · GitHub ]
17:55 ether if there was a meta flag, you could use deprecation as a field to search on in elasticsearch
17:55 ether as well as display it more prominently in search results etc
17:56 kentnl yeah, would be nice for tooling to go "Hey, you've just installed a bunch of deprecated shit!"
17:57 kentnl and in the case of "deprecated => { Module::Name => somethinghere }" it could go "You installed X, which dependend on Module::Name, which is deprecated, OH NOES!"
18:03 ether ++
18:03 dipsy Thanks!
18:04 ether or run a tool on an existing perl installation that looks at everything I've got installed and tells me what things are deprecated and what other things depend on them
18:04 ether I'd do something similar with x_breaks data actually
18:04 ether "given that you have all the meta files of everything I have installed, tell me if I've got any conflicting modules that I really need to upgrade"
18:04 ether (or broken prereqs etc etc)
18:06 kentnl well, we can do that now somewhat with metacpan, I think, but I think it nukes x_* or something before it saves the json :/
18:06 kentnl cpanm*
18:06 ether boo, why does it nuke x_? :(
18:06 ether that's useful stuff in there!
18:07 kentnl phew, nope x_ is kept :D
18:08 kentnl hm, that could be a useful tool, something just walking that meta stash and re-checking the cpan metas and shit are still happy
18:08 ether "verify my installation"
18:26 kentnl grep.cpan++
18:48 neilb joined #metacpan
19:01 nuba joined #metacpan
19:01 avenj joined #metacpan
19:19 neilb joined #metacpan
20:38 ranguard ether: thanks for trying with CPAN::Meta
20:40 ether o/
20:40 ether it should be fairly uncontroversial I think
20:47 bluefeet joined #metacpan
20:49 bluefeet Hey all - I'm having issues with carton where metacpan is not able to resolve versions.  This is happening for modules declare semver version as strings, as in our $VERSION='0.1.0';  For example 'cpanm --info -v MooseX::Attribute::Chained@0.1.0` and `cpanm --info -v Net::Braintree@0.15.0`.
20:50 bluefeet When I add, for example 'requires "Net::Braintree", "== 0.15.0";' to my cpanfile it bails with "Found Net::Braintree 0.018000 which doesn't satisfy == v0.15.0.".  Miyagawa suggested I come here and see if you guys have any ideas.
20:51 bluefeet If you run those cpanm commands you'll see something like this:
20:51 bluefeet Searching Net::Braintree (== 0.15.0) on metacpan ...
20:51 bluefeet ! Could not find a release matching Net::Braintree (== 0.15.0) on MetaCPAN.
20:52 rwstauner i'm not familiar with the code in cpanm/carton, but using version->parse(...)->numify ought to be doable
20:52 rwstauner there is a version_numified in the metacpan docs, although that probably shouldn't be necessary, as you should be able to filter on the regular version field
20:53 rwstauner and then do the parse/numify for cmp
20:53 rwstauner which was a long way of saying "it should work, but i haven't seen the carton code, and don't have time to look atm"
20:54 bluefeet Allright, I'l dig in to that.  Miyagawa thought it wasn't carton but MateCPAN's response.
20:54 bluefeet https://github.com/miyagawa/carton/issues/169
20:54 dipsy [ Net::Braintree version detection failing? · Issue #169 · miyagawa/carton · GitHub ]
20:55 rwstauner i can try to look into it later
20:55 rwstauner but metacpan should be returning the regular version string, however it was in the code, i think
20:55 rwstauner which i assume it gets from Module::Metadata
20:56 ether rwstauner: are you sure ->numify is what you want here?
20:56 rwstauner oh, well i guess not if it's ==
20:57 rwstauner i was thinking something was doing <=>
20:57 rwstauner if you want to satisfy >= then you'd probably want numify
20:58 ether version.pm has a cmp operator overload - that should be used ahead of anything else
20:58 rwstauner so idk, maybe you'd still want it for normalization
20:58 rwstauner ok
20:58 rwstauner sounds right
20:58 ether I see a Net::Braintree 0.15.0 on cpan, so that prereq should be satisfiable
20:59 bluefeet Seems to something is numifying the version in the module (so 0.15.0 becomes 0.015000) and that is compared against what is being requested (0.15.0) and it says nope, not here!
21:00 rwstauner bluefeet: where's that code?  in Carton?
21:00 * rwstauner &
21:00 bluefeet Finding out...
21:13 rashi joined #metacpan
21:29 rashi joined #metacpan
21:57 trs bluefeet: cpanm --info -v Net::Braintree@0.15.0 requests version "v0.15.0" from metacpan.
21:57 trs bluefeet: and metacpan has version: "0.15.0" and version_numified: "0.015"
21:58 trs replaying cpanm's request with s/v0\.15\.0/0.15.0/ works as expected.
21:58 trs this seems like a cpanm bug
21:58 ether why does it insert a 'v' into the request?
21:59 ether two dots does not imply vstring
21:59 ether so yeah.. cpanm
22:05 trs this is not exactly (GET vs POST, data versus ?source=...) but equivalent to the request cpanm is making: http://tsibley.net/paste/2014-03-05AUspH3KJ-cpanm-request
22:05 trs the JSON is straight from cpanm
22:05 trs after json_pp
22:06 trs bluefeet: I'm happy to chat with miyagawa about this if you point me to a channel :)
22:07 oalders trs++
22:13 bluefeet trs: thanks!  I've posted some of this conversation on the github issue.  Miyagawa has been responding quickly on the ticket, so I'm hoping he'll just popup in here shortly.
22:14 miyagawa_ joined #metacpan
22:15 miyagawa_ bluefeet: cpanm does add 'v' to avoid confusion between numified vs v-strings
22:15 miyagawa strictly speaking '0.15.0' isn't a valid version string at all
22:18 ether trs: the best channel for this is #toolchain
22:18 ether we've been discussing a lot of "interesting version problems" lately there
22:19 ether miyagawa: yes it is. perl -Mversion -wle'print version::is_lax("0.15.0")'
22:20 miyagawa no
22:21 ribasushi miyagawa: ether is being reeducated in #toolchain, cpanm is doing the right thing, we'll figure out what metacpan got wrong
22:22 miyagawa ✗ perl -MCPAN::Meta::Requirements -e '$r=CPAN::Meta::Requirements->new;$r->add_string_requirement("Foo", "0.15.0"); warn $r->requirements_for_module("Foo")'
22:22 miyagawa v0.15.0 at -e line 1.
22:23 miyagawa could be a bug in CMR, but anyway this is how cpanm internally processes the version requirement before sending it to metacpan
22:23 ether yes, I was confused. two-dot versions are lame. sorry!
22:23 miyagawa np, it is confusing... :)
22:23 ether I'm not sure what is going wrong in this issue then
22:23 ether i.e. the Net::Braintree query
22:23 miyagawa guess it could force numified query if there are two dots
22:24 ether 0.15.0 does pass the is_lax test though
22:24 trs so why is the metacpan module.version field "0.15.0" instead of "v0.15.0" ?
22:24 bluefeet Other modules too like MooseX::Attribute::Chained
22:25 miyagawa https://gist.github.com/miyagawa/9377947
22:25 dipsy [ a.diff ]
22:26 miyagawa don't like this, but seems to work for the module in question
22:27 trs presumably for comparisons everyone should be doing the same normalization.
22:27 trs whether that normalization is numify or not, I dunno.
22:27 miyagawa right
22:28 ether IMO metacpan should be using the overloaded comparison in version.pm for everything
22:29 ether which does mean turning every known version into a version object and then comparing to see if it satisfies the query
22:29 trs ether: we can't put version.pm into ES
22:29 trs and the api is ES
22:29 ether my @matches = map { version->parse($_) == version->parse("0.15.0") } @all_braintree_versions
22:30 trs so, we can provide a bunch of normalized fields
22:30 trs and the query author can pick which one to use
22:31 ether at a minimum I think the version.pm docs need to specify which accessor should be used to get something to use for external comparisons
22:32 ether ribasushi: agreed?
22:32 ether I'm not sure if numify will dtrt in all cases
22:33 ether plus, jpeacock has signalled his intention to remove that API
22:34 chansen_ joined #metacpan
22:34 ether trs: the QA hackathon is next week, at which there is intention to discuss some version issues; we can figure this out then
22:35 * trs 's been hearing that a lot recently ;)
22:35 ether :)
22:35 ether versions are hard!
22:35 jibsheet hopefully they confiscate weapons at the door of the versions discussion room
22:35 trs it seems that the simplest solution is metacpan providing another normalized version type
22:35 trs i.e. one that matches v0.15.0 which is what CPAN::Meta... produces
22:37 trs the release.version metacpan provides does appear to use that format.
22:37 trs presumably because it's also directly from CPAN::Meta :)
22:38 trs but module versions vs. release versions make this harder :)
22:42 miyagawa left #metacpan
22:46 controlpanel joined #metacpan
22:48 bluefeet ok, so sounds like this is on hold for about a week.  I guess I'll take another shot at using Carton/cpanm in a couple weeks.  Thanks all!

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary