Joel Purra

@ECMAScript3: good news =) Hope to see a new issue in `uvcc`, looking forward to your findings!

@ECMAScript3: oh, and which changes did you do to make it work in your previous comment? Do you have a patch?

As you can see in the linked `jq` discussions, work stalled. The `jq` maintainer didn't like the they way I've suggested `jq` to resolves (nested, recursive, global) dependencies, similar to...

@nicowilliams wrote: ### Default `src/main.jq` path per package > Let me summarize possible proposals: > - no intermediate path; let the pkg's build system "install" built artifacts where they "belong"...

@nicowilliams wrote: > Even a lot of script-type systems end up "building" their scripts (see, e.g., GNU auto\* tools)... I don't think this is just about C versus not-C. >...

> And I see now that a module could have many local -- and private modules this way. And if they are to be private then maybe we do need...

@nicowilliams wrote: > But having to read a JSON file, having to describe its schema -- that would be a significant complication. The schema to `jq` is `.main` (string path...

> The layout will be any of these > > ``` > $dir/$mod_rel_path.jq > $dir/$mod_rel_path/$(basename $mod_rel_path).jq > $dir/$mod_rel_path/jq/main.jq > ``` > > The third one is for @joelpurra, if that...

> By the way, I completed a preliminary working version of jqpm (a julia-like package manager for jq) some time ago, but it was evident that the jq library/module system...

> @nicowilliams wrote: > > > Even a lot of script-type systems end up "building" their scripts (see, e.g., GNU auto\* tools)... I don't think this is just about C...