New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support export of software dependencies from OCaml modules in the format “JSON” #7560
Comments
Comment author: @xavierleroy Sounds reasonable. A proof-of-concept implementation as a pull request would be welcome. |
Having to add a json printer to the compiler sounds cumbersome (at least with the current state without vendoring (we cannot depend on third-party OCaml libraries)). On the other hand, several libraries represent JSON with structural types (polymorphic variants), and we could add a function that exports to that without introducing any extra dependency.
To use this, users would then have to build their own executable program, linking with Compilerlibs and their favorite JSON serialization library. It sounds easy to add an external This would still require a refactoring of the ocamldep codebase; |
To be honest JSON is easy enough to output things by hand, it is just a matter of escaping strings correctly (20 lines). In this particular case I more doubt the usefulness of JSON output given the current complexity of the data being output (and unless part of a larger change to output machine readable format in the whole tooling chain, e.g. error messages, etc).
Having recently cargo-culted and tweaked the AST recursion of death that is in parsing/depend.ml to output more precise dependency information for another tool, I'd be glad if that could be the case. I hate when my tools are dependent on the AST since they break at almost every new version of the compiler (moreover the persons evolving the language would do the right thing for me there when they change it...) |
Yes, I think that exposing better, high-level APIs to some compilation services should be a side-effect of any "produce machine-readable output for (Would you be willing to send a PR for this part?) |
Assuming you meant pull request and not problem report, that would be premature for now. But when I think I have the right thing, I might. |
What I had in mind was very simple: I would add a function in |
I see, I'm more interested in getting module usage/definition outlines of the following form: type mod_path = string
type import =
| Open of mod_path * import list
| Using of String.Set.t
type imports = import list
type exports = String.Set.t
type outline = { imports : imports; exports : exports }
val outline_of_file : string -> outline |
What is the second argument of Also codept can already output a more precise version of exports with |
Yes. |
May I ask what is your use case? I am asking because there is not enough information left in this format for inferring precise dependency for instance. |
Best-effort automatic dependency discovery.
What would you add ? |
The minimal information (location information excepted) needed is more or less |
I am still curious how affected software components can be improved also for this issue. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This is being worked on #9538 |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 7560
Reporter: @elfring
Status: acknowledged (set by @xavierleroy on 2017-06-22T18:08:59Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.03.0
Category: tools (ocaml{lex,yacc,dep,debug,...})
Tags: junior_job
Related to: #7559
Child of: #7558
Bug description
I imagine that it would be occasionally nice to perform higher level data processing with dependency information.
How do you think about to export corresponding data from referenced OCaml modules in the format “JavaScript Object Notation” (by the tool “ocamldep”)?
Additional information
https://en.wikipedia.org/wiki/JSON
The text was updated successfully, but these errors were encountered: