|
Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec Set by moderator on 25 January 2016. |
|||
|
01:05
autarch joined
05:05
hankache joined
05:55
llfourn joined
07:17
domidumont joined
07:28
hankache joined
08:31
domidumont joined
08:36
domidumont joined
09:07
hankache joined
09:32
hankache joined
09:52
nine joined
12:10
leont joined
|
|||
| nine | gist.github.com/niner/8ad4cbefde16d9494e16 is a little installer script that's the equivalent of panda install . | 12:52 | |
| 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. | |||
| I wonder where we could put this code? | 12:53 | ||
| 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:54 | ||
| If anyone likes to discuss things like this at FOSDEM, I'd be happy to :) | 12:57 | ||
| flussence | wait, slurp() can take multiple arguments‽ | 13:01 | |
| oh never mind, reading that line wrong... | 13:03 | ||
| erm, shouldn't 3s/^role/class/ there? | 13:08 | ||
| besides that, this makes module installing look a lot less scary. I might have a use for it someday :) | 13:09 | ||
|
13:28
lizmat joined
|
|||
| tony-o_ | flussence: i think role is good in that if it's meant to be shared/reused by core/pkg mgrs | 14:24 | |
| nine++ | |||
|
14:28
lizmat joined
|
|||
| nine | Panda::Project could for example do this role, so it would fit well with panda's architecture | 14:31 | |
| jdv79 | where's the uninstall part? | 15:14 | |
| nine | uninstall part? | 15:17 | |
| jdv79 | we dont allow uninstallation of a dist? | 15:22 | |
| nine | That's still stuck in the query_repos branch | 15:24 | |
| ugexe | im still willing to write the s22 version of distribution | 15:25 | |
| which is a minimal install code for *anything* to install a dist, even a .deb installer | |||
| nine | gist.github.com/niner/b39258032f70c083e57b is an uninstall-dist.pl script | 15:28 | |
| ugexe | fwiw though that Distribution::Directory is almost exactly what i use now (although im still hoping for s22) github.com/ugexe/zef/blob/master/l.../Local.pm6 | 15:32 | |
| jdv79 | whats diff about what you want to do for s22? | 15:33 | |
| 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:34 | |
| ugexe | right, but im saying that stuff is pointless. why not have the dist object inlude sources/scripts/resources in the object itself | 15:35 | |
| 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 | ||
| nine | ugexe: having internet on the plane would have helped with that ;) | ||
| 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 | |
|
15:38
domidumont joined
|
|||
| 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 | ||
| ugexe | i dont think that changes anything about Distribution | 15:39 | |
| 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 | ||
| but that change will affect rakudo no matter what, its not specific to changing Distribution | |||
| 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 | ||
| CU::R::I accesses the Distribution through .content or .meta | |||
| the core Distribution would just be an interface | 15:42 | ||
| there would be another Distribution in core (probably like that Distribution::Directory) that would take over the current role of Distribution | 15:43 | ||
| then its trivial to write Distribution::Tar, Distribution::Github, etc | 15:45 | ||
| jdv79 | so Distribution::Directory would be in core? i don't get it . | 15:46 | |
| that's where the meta handling is happening now - D::D | |||
| ugexe | no, there is no Distribution::Directory in core currently | ||
| meta "handling" doesn't happen anywhere central (a problem). Distribution is used as a sort of key/value store but thats it currently | 15:47 | ||
| jdv79 | i'm talking about what nine posted that started today off | 15:48 | |
| that had a D::D in it | |||
| ugexe | yeah. which provides a type of API access to the Distribution | ||
| jdv79 | ok | 15:50 | |
| ugexe | these are 2 prototypes that show similar distribution model but the Distribution itself does all the meta handling: gist.github.com/ugexe/8684abcc89aa2d03d009 gist.github.com/ugexe/1026b2730abe6d2a126c | 15:59 | |
| 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:01 | ||
| 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 | ||
| not just for files, but all of the meta | |||
| anywho, can CU handle this custom location itself now? it would allow all the dependencies to be removed (none of which are declared) github.com/perl6/doc/blob/master/Build.pm#L14 | 16:10 | ||
| (its for installing to /../doc) | 16:11 | ||
|
16:20
cognominal joined
|
|||
| jdv79 | is there a way to repro that lock issue you guys were talking about the other day? | 17:19 | |
| 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:37 | |
| 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 | ||
| 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 | ||
| 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 | |||
| so something of a last hurrah for the current super hacky way maybe | 17:46 | ||
| lots of new errors though so that'll be fun | |||
| well, in general i'm pretty sure there are a few different ways to not have to lock excl like that for reading | 17:47 | ||
| ugexe | heh, im glad someone is working on it. it was cool finally installing something from the 'pan | 17:49 | |
| jdv79 | a bunch of installs are timing out | 18:11 | |
| gah | |||
| yeah, lovely. looks like a hung install blocked everything else with a lock. super! | 18:19 | ||
| lunch & | |||
|
18:45
hankache joined
19:07
kmel joined
19:09
mst joined
19:36
hankache joined
|
|||
| ranguard uploads everything to CPAN (as dev releases) again | 19:42 | ||
|
21:38
hankache joined
23:35
lizmat joined
23:36
leont joined
|
|||