|
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 1 June 2016. |
|||
|
01:49
ilbot3 joined
|
|||
| moderator | 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 | ||
|
02:33
ribasushi joined
03:40
ribasushi joined
04:06
ribasushi joined
04:26
ribasushi joined
06:37
ribasushi joined
06:51
ribasushi joined
07:12
ribasushi joined
08:37
nine_ joined
08:38
ribasushi joined
08:51
b2gills joined
10:03
nine joined
10:04
camelia joined
|
|||
| nine | ugexe: your recent change to Repository::FileSystem means that the META6.json is no longer the authoritative source for which modules are in that repo. | 11:04 | |
| lizmat | nine: should I revert ? | 11:05 | |
| nine | ugexe: I don't have a preference either way, just wanted to mention this clearly, so we're aware of the consequences. | ||
| Because I'm not sure this has really been discussed before. Looks like it's always been just a result of some implementation. | 11:06 | ||
| lizmat: an authoritative META6.json would give results closer to the installed dist while the current behavior makes extras like Build.pm work more consistently. | 11:07 | ||
| lizmat | nine: but the idea of the FS repo would always be that just adding a file to the filesystem was enough to make it "installed" ? | 11:08 | |
|
11:09
ribasushi joined
|
|||
| nine | Yes, and it would be confusing if that didn't work. Obviously someone also thought that it would be nice if the META6.json were not only significant for installed dists, leaving us with the question of what exactly its role is in a FileSystem repo. | 11:16 | |
| sjn | is there a MANIFEST? | 11:17 | |
| sjn sees Bailador's META.info contains a provides field that looks eerily like a manifest | 11:22 | ||
| lizmat | sjn: not that I know of, only a dummy Manifest object afaik | ||
| sjn likes the fact that it's possible to check if a distribution is complete | 11:23 | ||
| but that kinda assumes someone has to spend a little attention on making either the manifest, or a manifest.skip equivalent (when auto-generating the manifest) | 11:24 | ||
| also, | |||
| (warning: pet peeve coming up) | |||
| I think there should be a smarter way of managing files in a distribution | 11:25 | ||
| lizmat | sjn: but this is about the FileSystem repo, which has files managed by the user by adding/removing them from the file system | 11:26 | |
| like in Perl 5 | |||
| sjn | yes | ||
| some hints about file types would be really, really useful | |||
| "this is a perl6 module file": "foo.bar" | 11:27 | ||
| keeping track of which modules in a repo is fine and definitely the most important thing to do in a META6.json file (or eqv. metadata file) | 11:28 | ||
| but it really isn't enough | 11:29 | ||
| "templates": { "index.tpl": "templates/index.tpl" }, "css": { "mobile.css": "static/mobile.css" } | 11:52 | ||
|
12:06
ribasushi joined
13:09
sufrostico joined
13:15
patrickz joined
|
|||
| ugexe | nine: i'm not sure it was meant to act as an authority though, just to allow one to use non-standard name-path mappings through `provides` | 13:21 | |
| the better solution is to make build-time/Build.pm stuff declarative (of course), but thats probably better left for when we know everything that needs to be broken so we can break everything at once | 13:32 | ||
| sjn: see the last paragraph of design.perl6.org/S22.html#%25%3FRESOURCE for an idea on how the manifest could be built | 13:33 | ||
| sjn | ugexe: righht | 13:36 | |
| ugexe | there is some support for that in my distribution PR, where given a known meta6 key-path (like %meta<a><b><c> key-path is a, b, c) it can accept a string or a hash (but would use the key of this hash as the original string value). the .value of that hash would then be ignored by anything that isn't concerned with build time stuff | 13:37 | |
| sjn | useful, but how about resources that aren't supposed to be used from the library/application? | ||
| ugexe | but build tools would want to check that .value and use it for things | ||
| they can follow the same thing. the PR i reference does this for `provides` as well | 13:38 | ||
| sjn | e.g. crontab entries, application-specific nagios scripts... | ||
| ugexe | the files that get build get tacked on the end as a hash of the generated files | ||
|
13:39
ribasushi joined
|
|||
| ugexe | wouldnt you handle those in your Build script, and let whatever Build module you would likely use handle it? | 13:39 | |
| i understand what you're after, im just not sure | 13:40 | ||
| sjn thinks would be positive if *less* would be done by a custom build script | |||
| ugexe | because we do need install/uninstall hooks | ||
| sjn | I'm just saying "we should have a place for these things too" | ||
| ugexe | i dont think META6 is the place to handle crontab entries | ||
| sjn | ugexe: you could refer to them (like a manifest with filetype information) | 13:41 | |
| then let the builder/installer do the right thing | 13:42 | ||
| e.g. files listed as "crontab" are copied to /etc/cron.d/myapp.cron | |||
| or whatever is correct for that system | 13:43 | ||
| </pet-peeve> | |||
| ugexe | "whatever is correct for that system" wouldnt be as simple as you make it out (i dont think anyway) | 13:44 | |
| sjn | sure it would | ||
| ugexe | it has to know how your cron is configured to even be. if you're on windows... i don't even know | 13:45 | |
| sjn | you need a matching file for each system (e.g. in Ubuntu, we put httpd configuration in /etc/apache/sites-available or something like that | ||
| ) | |||
| and if the file type/service/system feature isn't available, just don't do anything and maybe offer a warning with a pointer to the file and a few words about how to fix the installation? | 13:47 | ||
| such a matching file, I would probably put in /etc/perl6/locations.json or something like taht | |||
| ugexe | build a service locator into the core? | ||
| sjn | nah, make it configurable, let the packagers make the file | 13:48 | |
| all with flat files and no smarts needed to figure out where files are supposed to end up | |||
| (fsvo "flat" json :) | 13:49 | ||
| also, with a little thought, this could be made into something user-overridable | |||
| ugexe | my first thought is thats turning Build.pm into a type of configuration-file-as-script, but it sounds like you have a much better general idea than i do here | 13:50 | |
| sjn | e.g. "in our shop, we want to install stuff in /opt/ourshop/perl6" | ||
| and just to inflate the wishful thinking even more; there's nothing blocking us from making this into a generic installation protocol. "Install Anywhere Protocol" :) | 13:51 | ||
| perhaps with options to specify dependencies across domains or on system features and resources ("I need an unused port 80 for my app") | 13:52 | ||
| ugexe | sure, those are good idea. but i think the scope is too big for CUR::Installation. however the foundation could be laid to allow those things with hooks or whatnot (requiring some sort Module::Build to handle most of those specifics) | 13:57 | |
| not that such a module couldn't be included with rakudo (like Test or NativeCall) | 13:58 | ||
| sjn | mm | 14:02 | |
| Hm. Anyone here who would like to take a stab at an "Install Anywhere Protocol"? :) | 14:03 | ||
|
14:14
ribasushi joined
14:44
ribasushi joined
|
|||
| ugexe | nine: gist.github.com/ugexe/017672ef3972...d08a854872 something like this may be worthwhile as well (cache `provides` to avoid later meta6 lookups, and single assignment for found) | 15:24 | |
|
15:28
sjn joined
|
|||
| nine | ugexe: yes sounds very reasonable | 16:47 | |
|
17:14
ribasushi joined
17:47
FROGGS joined
17:50
Kassandry joined
20:34
ribasushi joined
20:45
sufrostico joined
21:36
patrickz joined
22:42
ribasushi joined
23:44
sufrostico joined
|
|||