|
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 21 January 2016. |
|||
|
07:07
hankache joined
07:28
domidumont joined
07:33
domidumont joined
09:08
kmel joined
09:11
kmel joined
09:16
hankache joined
10:13
leont joined
10:17
hankache joined
|
|||
| nine | ugexe: I'm now reading through gist.github.com/ugexe/1026b2730abe6d2a126c after beeing afk for a week. It's certainly a fascinating read. I have a bit of a hard time powering up again, so don't be surprised if feedback is slow in coming. | 12:25 | |
| masak | nine++ ugexe++ | 12:36 | |
| nine | ugexe: I do wonder why S22 speculates about a general "content" method using dispatch based on the arguments instead of specialized methods dispatched on method name like .bin, .resource and so on. The general version would only make sense for providing an open interface where new keys could easily be added to the META data. | 12:46 | |
| ugexe: I think what I don't like about "content" is that it really makes Distribution just an interface for a nested hash data structure while the fact that it's usually derived from some JSON file should be hidden. While "content" makes it trivial to extend the META file format and access those new keys from tools it makes it actually harder to add specialized behavior for keys (like resources/libraries) | 12:53 | ||
| ugexe: if we find the need to provide new special treatment in the future (as we likely will), we can do this with roles providing those accessor methods and tools can check the presence of these roles. How would a tool check if the .content method provides the special handling? | 12:55 | ||
| ugexe: resourcs/libraries is actually a good first example, as you've correctly pointed out that the special handling should be done by the repo's install method instead of by every installation manager. | 12:56 | ||
| ugexe: I love the idea of using Distribution as the single interface between installer and the .install method. We could even go a step further and instead of paths mandate IO::Handle to read data from. That way the github distribution wouldn't need to create those temp files. Same would be true for a tool accessing installed distributions. A repo is free to store a dist in an SQL database, as long as it can provide an IO::Handle interface to the stored | 13:05 | ||
|
13:07
FROGGS joined
|
|||
| jdv79 | nine: why are the 2 mutually exclusive? | 13:08 | |
| nine | jdv79: you mean .content + .resources/.whatever? | 13:09 | |
| jdv79 | yeah. actually i'm not sure it matters that much now that i think about it. | 13:11 | |
|
13:23
hankache joined
|
|||
| jdv79 | though, instead of an attr containing a hash i think meta would be better as a real obj/class. | 13:24 | |
|
13:52
FROGGS_ joined
|
|||
| nine | From the backlog: I really want to avoid us doing a readdir for every precomp file we load. It also seems to be clear that we cannot overwrite or delete files as they may be in use elsewhere. Luckily we already have lookup tables: the dist files record the mapping between module and precomp id. | 15:11 | |
| So if there's already a precomp file with the same name, we can use a different id for the new file. | 15:12 | ||
| Incidentally, I think I just stumbled over the (hopefully) last missing invalidation problem: CompUnit::Repository::Installation::id uses the id of all installed dists so a repo ahead in the change can use the changing id as a signal to invalidate all precomp files. But the dist ids don't change on a --force install, so reverse dependencies in repos ahead in the chain won't be recompiled. | 15:14 | ||
| This stuff is really _hard_ to get right. Who'd have thought? | 15:15 | ||
| At the same time, we really should aim for a Linux distribution's package manager to be able to install module packages by just dropping files. Which for me is a killer argument against any centralized mapping files or counters or other shared state. | 15:17 | ||
| ugexe | nine: using an IO::Handle was my idea too, but i was hoping for an interface that also worked on IO::Socket | 16:50 | |
| nine | Oh I kind of assumed that IO::Handle would cover sockets, too. | 16:54 | |
| ugexe | to do that you use `IO` so it would have to be .read | 16:56 | |
| nine | Oh and as we're pondering having different Distribution implementations, we'll need to think about $*REPO.uninstall($dist) and where the $dist will come from and which kind of Distribution it will be. | 17:00 | |
| ugexe | after its installed i dont think the type of dist is relevant anymore | 17:01 | |
| nine | I don't think it will be either. At least as long as it's used as an id mostly by uninstall. | 17:03 | |
| ugexe | once CU.install touches the dist it could be considered a CompUnit(s). so you would be uninstalling a CompUnit, and since all modules have to be CompUnits they can all be installed with a CompUnit specific method | ||
| nine | Uninstalling a single module out of a dist? | 17:06 | |
| ugexe | post-uninstall scripts in hooks/ may help with needing an actual Distribution object too | ||
| i mean uninstalling a module (or distribution of them) | |||
| nine | I'm not sure if we're on the same terminology here? A distribution contains 0 or more modules which when loaded become CompUnits. Installation and uninstallation work in terms of distributions. | 17:08 | |
| ugexe | the reason for .content accepting arbitrary keys is because resources was specced to accept arbitrary nodes/leafs | 17:09 | |
| so a package manager could for instance use a node to store reverse dependencies so it knows how to orphan packages for instance | |||
| nine | Oh, and this is also where we could store the bit about if a dist was installed as dependency or directly! | 17:10 | |
| Which is exactly what you just said... | |||
| ugexe | heh | 17:11 | |
| nine | Maybe we do want both: the general access mechanism and the specialized methods in easily detectable roles | ||
| ugexe | either way. any specialized methods should be able to do the same things through general access methods (just abstracting the call to .meta to gets keys, the logic to figure out which key to pick, and calling .content to get it) | 17:15 | |
| when ive done this with roles I would also add a `.files` method to the required interface. so ::FileSystem would do $iopath.dir, ::Git would do run(`git`, `ls-files`, cwd($path-dir)), ::Tar would do `tar --list -f $path-dir` | 17:17 | ||
| that helps get rid of special handling of bin files (which are not listed in a Distribution anywhere) | 17:18 | ||
| (presumably because installing bin/ scripts could be an optional thing) | 17:19 | ||
| also re: resource node/leafs; they can be used for hooks as well. "resources" : { "libraries" : { "libblah" : build-time } }, | 17:22 | ||
| but instead of build-time it might be something telling to automatically do the VM platform-name thing (or tell it *not* to) | 17:23 | ||
| or maybe "resource" : { "some-folder" : { "libblah" : library } } # so libraries can go in any folder under resources | 17:26 | ||
| in the former example it probably makes things like Distribution -> .deb/.rpm/makefile a lot easier | 17:47 | ||
| on the bright side its under key "resource" in s22, but currently everyone uses "resources" | 17:54 | ||
|
18:34
lizmat joined
19:10
hankache joined
19:21
domidumont joined
20:04
domidumont joined
|
|||
| jdv79 | wait. what? resources is just an additional filestore, right? since when is it used as an ad hoc datastore? | 20:40 | |
| use another key for that i'm guessing | 20:41 | ||
| ugexe | s22 has always had it as such | 22:26 | |
| otherwise, as it currently is, its not really any different from bin/ (which is not declared in the meta) | 22:27 | ||
| well, other than access to %?RESOURCE | |||
| i also think it would be neat if you could just store arbitrary config data in there too | 22:37 | ||