-
Notifications
You must be signed in to change notification settings - Fork 327
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
Generate docs for Erlang projects #1291
Conversation
This addresses: $ elixir /Users/erszcz/work/elixir-lang/ex_doc/bin/ex_doc kvs "wip" _build/default/lib/kvs/ebin/ --main kvs -o ex_doc ** (UndefinedFunctionError) function :kvs.__info__/1 is undefined or private :kvs.__info__(:compile) (ex_doc 0.23.0) lib/ex_doc/retriever.ex:591: ExDoc.Retriever.source_path/2 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:131: ExDoc.Retriever.do_generate_node/3 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:125: ExDoc.Retriever.generate_node/3 (elixir 1.11.0-dev) lib/enum.ex:3425: Enum.flat_map_list/2 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:43: ExDoc.Retriever.docs_from_modules/2 (ex_doc 0.23.0) lib/ex_doc.ex:26: ExDoc.generate_docs/3
This addresses: $ elixir /Users/erszcz/work/elixir-lang/ex_doc/bin/ex_doc kvs "wip" _build/default/lib/kvs/ebin/ --main kvs -o ex_doc ** (RuntimeError) content type "application/erlang+html" is not supported (ex_doc 0.23.0) lib/ex_doc/retriever.ex:172: ExDoc.Retriever.doc_ast/3 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:217: ExDoc.Retriever.get_module_docs/2 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:134: ExDoc.Retriever.do_generate_node/3 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:125: ExDoc.Retriever.generate_node/3 (elixir 1.11.0-dev) lib/enum.ex:3425: Enum.flat_map_list/2 (ex_doc 0.23.0) lib/ex_doc/retriever.ex:43: ExDoc.Retriever.docs_from_modules/2 (ex_doc 0.23.0) lib/ex_doc.ex:26: ExDoc.generate_docs/3
$ elixir /Users/erszcz/work/elixir-lang/ex_doc/bin/ex_doc kvs "wip" _build/default/lib/kvs/ebin/ --main kvs -o ex_doc ** (FunctionClauseError) no function clause matching in ExDoc.Autolink.fragment/4 The following arguments were given to ExDoc.Autolink.fragment/4: # 1 :no_tool # 2 :type # 3 :t # 4 0 Attempted function clauses (showing 2 out of 2): defp fragment(:ex_doc, kind, name, arity) defp fragment(:otp, kind, name, arity) (ex_doc 0.23.0) lib/ex_doc/autolink.ex:556: ExDoc.Autolink.fragment/4 (ex_doc 0.23.0) lib/ex_doc/autolink.ex:395: anonymous fn/7 in ExDoc.Autolink.do_typespec/2 (elixir 1.11.0-dev) lib/regex.ex:738: Regex.apply_list/5 (elixir 1.11.0-dev) lib/regex.ex:733: Regex.apply_list/5 (elixir 1.11.0-dev) lib/regex.ex:675: Regex.do_replace/4 (ex_doc 0.23.0) lib/ex_doc/autolink.ex:402: anonymous fn/7 in ExDoc.Autolink.do_typespec/2 (elixir 1.11.0-dev) lib/regex.ex:738: Regex.apply_list/5 (elixir 1.11.0-dev) lib/regex.ex:733: Regex.apply_list/5
@erszcz great, thank you! It's marked as WIP so please let us know when you think it's ready to be merged in - we don't have to solve everything in this one PR of course, but if we can find an incremental step and merge that, I think that's a good path forward. Regarding having to use your EDoc branch, I was able to find a workaround. It might be using private code so take it with a grain of salt. Here's generating chunk for foo module in ex_doc app:
|
Hi @wojtekmach!
Clever! I’ll have to see how these compare with EDoc chunks - I guess they might be missing callback docs, but I’m not sure right now.
First, I was interested in your approach to exposing Then, we have the problem with tests. The failing test is
This is consistent with the module’s comment in I guess this should be explored further, since we can expect links to project-local Erlang modules (rare, I guess, though In the scope of this PR, though, I propose to distinguish between Erlang OTP and non-OTP modules and only link to OTP docs. This does not introduce functionality changes and therefore carries no changes in tests. |
I'm now a bit puzzled with the CI results of 390c561. When run locally, the first |
@wojtekmach I've removed the WIP label. I think this is now ready to merge or review further if you see anything fishy :) |
This sidesteps: ** (SyntaxError) nofile:1:15: syntax error before: in. "in" is a reserved word in Elixir and therefore its usage is limited. For instance, it can't be used as a variable or be defined nor invoked as a regular function (elixir 1.11.0-dev) lib/code.ex:654: Code.format_string!/2 (ex_doc 0.23.0) lib/ex_doc/autolink.ex:342: ExDoc.Autolink.typespec/2 (elixir 1.11.0-dev) lib/enum.ex:1399: Enum."-map/2-lists^map/1-0-"/2 (ex_doc 0.23.0) lib/ex_doc/formatter/html.ex:86: anonymous fn/5 in ExDoc.Formatter.HTML.render_all/4 (elixir 1.11.0-dev) lib/enum.ex:2185: Enum."-reduce/3-lists^foldl/2-0-"/3 (ex_doc 0.23.0) lib/ex_doc/formatter/html.ex:83: anonymous fn/4 in ExDoc.Formatter.HTML.render_all/4 (elixir 1.11.0-dev) lib/enum.ex:1399: Enum."-map/2-lists^map/1-0-"/2
@erszcz after #1329 lands, we'll have basic support on master! This is how it'll look like: http://wojtekmach.pl/docs/stdlib/api-reference.html. We still have some internal changes to do before we even introduce the language contract, but we're very close. Then we'd cherry pick things from this PR. THanks! |
Hi! This PR fixes some small issues when generating docs from Erlang doc chunks (created by
erl_docgen
oredoc
). These are mostly earlier @wojtekmach's changes and my fixes from #1143, applied on top of the current master.This PR also exposes the
ExDoc.Config.proglang
field as a command line switch--proglang
. This way it's possible to determine which (Elixir, the default, or Erlang) stylesheet is used for the generated documentation. This might not be flexible enough for projects shipping both Erlang and Elixir APIs, but seems to be a good enough starting point.A preview of a trivial lib's docs is available at https://erszcz.github.io/kvs.
Currently, the prerequisite to generate Erlang docs is having EDoc with EEP-48 support installed - either as a standalone app from https://github.com/erszcz/edoc or from erlang/otp#2803. With that in place: