Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-01-30

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:05 autarch joined #perl6-toolchain
05:05 hankache joined #perl6-toolchain
05:55 llfourn joined #perl6-toolchain
07:17 domidumont joined #perl6-toolchain
07:28 hankache joined #perl6-toolchain
08:31 domidumont joined #perl6-toolchain
08:36 domidumont joined #perl6-toolchain
09:07 hankache joined #perl6-toolchain
09:32 hankache joined #perl6-toolchain
09:52 nine joined #perl6-toolchain
12:10 leont joined #perl6-toolchain
12:52 nine https://gist.github.com/niner/8ad4cbefde16d9494e16 is a little installer script that's the equivalent of panda install .
12:52 nine In other words it's the minimum code that intalls a dist from a directory. So it's code that we may want to share between installers, because they all have to do this.
12:53 nine I wonder where we could put this code?
12:54 nine I'd also like us to ship a script like this with rakudo. It can for example be used to replace panda's bootstrap script or for use for creating distribution packages for modules. I really don't want to use a full panda or zef in a .spec file
12:57 nine If anyone likes to discuss things like this at FOSDEM, I'd be happy to :)
13:01 flussence wait, slurp() can take multiple arguments‽
13:03 flussence oh never mind, reading that line wrong...
13:08 flussence erm, shouldn't 3s/^role/class/ there?
13:09 flussence besides that, this makes module installing look a lot less scary. I might have a use for it someday :)
13:28 lizmat joined #perl6-toolchain
14:24 tony-o_ flussence: i think role is good in that if it's meant to be shared/reused by core/pkg mgrs
14:24 tony-o_ nine++
14:28 lizmat joined #perl6-toolchain
14:31 nine Panda::Project could for example do this role, so it would fit well with panda's architecture
15:14 jdv79 where's the uninstall part?
15:17 nine uninstall part?
15:22 jdv79 we dont allow uninstallation of a dist?
15:24 nine That's still stuck in the query_repos branch
15:25 ugexe im still willing to write the s22 version of distribution
15:25 ugexe which is a minimal install code for *anything* to install a dist, even a .deb installer
15:28 nine https://gist.github.com/niner/b39258032f70c083e57b is an uninstall-dist.pl script
15:32 ugexe fwiw though that Distribution::Directory is almost exactly what i use now (although im still hoping for s22) https://github.com/ugexe/zef/blob/master/lib/Zef/Distribution/Local.pm6
15:33 jdv79 whats diff about what you want to do for s22?
15:34 nine ugexe: exactly :) I would have been very surprised if I had ended up with something radically different from your code. It's just what I hacked together on the plane to FOSDEM.
15:35 ugexe right, but im saying that stuff is pointless. why not have the dist object inlude sources/scripts/resources in the object itself
15:37 ugexe a Distribution::Directory to me is fine, but i'd like to see it use the s22 base Distribution to access stuff
15:37 jdv79 well, one point of consideration is maybe keeping as much as possible outside rakudo since rakudo has a regulated release sched now
15:37 nine ugexe: having internet on the plane would have helped with that ;)
15:38 flussence fwiw the uninstall part is easy iff the OS is involved: it keeps track of what was installed, so it just rips those files back out. no action needed on the perl6 side.
15:38 domidumont joined #perl6-toolchain
15:38 ugexe Distribution is terribly bad currently, i dont think keeping anything out of it will help
15:38 jdv79 for instance, what happens when and if we change s22 alot like maybe adopting more of p5's CPAN::Meta::Spec ways
15:39 ugexe i dont think that changes anything about Distribution
15:40 jdv79 it will change how meta stuff is handled
15:40 ugexe Distribution requires an API to access the meta data, as well as a method to use that API to access the data itself
15:40 ugexe but that change will affect rakudo no matter what, its not specific to changing Distribution
15:41 jdv79 all i'm saying is hardcoding how meta is handled would be better to keep out of core
15:41 ugexe exactly, it gets put into the distribution with what im saying
15:41 ugexe CU::R::I accesses the Distribution through .content or .meta
15:42 ugexe the core Distribution would just be an interface
15:43 ugexe there would be another Distribution in core (probably like that Distribution::Directory) that would take over the current role of Distribution
15:45 ugexe then its trivial to write Distribution::Tar, Distribution::Github, etc
15:46 jdv79 so Distribution::Directory would be in core?  i don't get it .
15:46 jdv79 that's where the meta handling is happening now - D::D
15:46 ugexe no, there is no Distribution::Directory in core currently
15:47 ugexe meta "handling" doesn't happen anywhere central (a problem). Distribution is used as a sort of key/value store but thats it currently
15:48 jdv79 i'm talking about what nine posted that started today off
15:48 jdv79 that had a D::D in it
15:48 ugexe yeah. which provides a type of API access to the Distribution
15:50 jdv79 ok
15:59 ugexe these are 2 prototypes that show similar distribution model but the Distribution itself does all the meta handling: https://gist.github.com/ugexe/8684abcc89aa2d03d009 https://gist.github.com/ugexe/1026b2730abe6d2a126c
16:01 ugexe dont get me wrong, i want to be able to pass in Distributions like Directory. but i also want a slightly lower level interface to be used for CU::R::I (which Directory can fulfill)
16:04 ugexe then you could even allow it to parse like a metacpan-spec (instead of meta6.json) distribution object and CU::R::I wont care, it just needs to know how to use the API (which your Distribution::METACPAN would provide)
16:04 ugexe not just for files, but all of the meta
16:10 ugexe anywho, can CU handle this custom location itself now? it would allow all the dependencies to be removed (none of which are declared) https://github.com/perl6/doc/blob/master/Build.pm#L14
16:11 ugexe (its for installing to /../doc)
16:20 cognominal joined #perl6-toolchain
17:19 jdv79 is there a way to repro that lock issue you guys were talking about the other day?
17:37 ugexe something like you load Module::A, then spawn a process that tries loading Module::SomethingElse except it depends on Module::A and hasn't been precompiled yet. it cant precompile because the original program is holding the lock, but its holding the lock because its waiting for that process to finish
17:39 ugexe i was reproducing it by installing zef from source (without moving it somewhere else), which later ends up running a test with `use-ok(Module::XXX)`, except it never runs because its stuck waiting for the lock
17:39 jdv79 sounds like a fun little problem
17:45 ugexe i imagine its easier to sweep that one under the disable-precomp-via-env rug
17:45 jdv79 so, i'm loading up the current eco into mc6 along with a current cpan
17:45 jdv79 hopefully that's useful for something.  and then i'll try to get it auto-updating with more useful versions and bug fixes and stuff
17:46 jdv79 so something of a last hurrah for the current super hacky way maybe
17:46 jdv79 lots of new errors though so that'll be fun
17:47 jdv79 well, in general i'm pretty sure there are a few different ways to not have to lock excl like that for reading
17:49 ugexe heh, im glad someone is working on it. it was cool finally installing something from the 'pan
18:11 jdv79 a bunch of installs are timing out
18:11 jdv79 gah
18:19 jdv79 yeah, lovely.  looks like a hung install blocked everything else with a lock.  super!
18:19 jdv79 lunch &
18:45 hankache joined #perl6-toolchain
19:07 kmel joined #perl6-toolchain
19:09 mst joined #perl6-toolchain
19:36 hankache joined #perl6-toolchain
19:42 * ranguard uploads everything to CPAN (as dev releases) again
21:38 hankache joined #perl6-toolchain
23:35 lizmat joined #perl6-toolchain
23:36 leont joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary