-
Notifications
You must be signed in to change notification settings - Fork 351
Fix ExDoc.CLI.main/2 to keep --source-ref #680
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
Conversation
Hello, @eksperimental! This is your first Pull Request that will be reviewed by Ebert, an automatic Code Review service. It will leave comments on this diff with potential issues and style violations found in the code as you push new commits. You can also see all the issues found on this Pull Request on its review page. Please check our documentation for more information. |
b1fcc68
to
1ba0620
Compare
lib/ex_doc/issue446.ex
Outdated
@source_root File.cwd! | ||
|
||
def run(relative_path) do | ||
ExDoc.Retriever.docs_from_dir(relative_path, relative_path |> doc_config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a function call when a pipeline is only one function long
lib/ex_doc/issue446.ex
Outdated
source_beam: Path.expand relative_path | ||
} | ||
end | ||
end No newline at end of file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a final \n at the end of each file.
lib/ex_doc/issue446.ex
Outdated
@@ -0,0 +1,17 @@ | |||
# file: lib/ex_doc/issue446.ex | |||
defmodule ExDoc.Issue446 do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modules should have a @moduledoc tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eksperimental Thanks! I just leave some comments.
lib/ex_doc/cli.ex
Outdated
e: :extra, v: :version, n: :canonical, s: :extra_section, | ||
a: :assets, i: :filter_prefix], | ||
switches: [extra: :keep]) | ||
{opts, args, _invalid} = OptionParser.parse(args, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not something like this?
{opts, args, _invalid} =
OptionParser.parse(args, ...
lib/ex_doc/cli.ex
Outdated
a: :assets, | ||
l: :logo, | ||
n: :canonical, | ||
v: :version, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT about sorting this aliases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope. the idea (as the title of the commit suggests) is to keep the same order as the exdoc --help
command lists them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see, then, It would be nice to see an inline note about your suggestion because it's easy to see the pattern when those aliases are ordered alphabetically, but no when they are listed in same order as the docs, wdyt?
lib/ex_doc/issue446.ex
Outdated
@@ -0,0 +1,17 @@ | |||
# file: lib/ex_doc/issue446.ex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really want to include this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope. it was a mistake. it's from a really old PR
test/ex_doc/cli_test.exs
Outdated
] | ||
|
||
{project, version, opts} = | ||
run(args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not something like this:
{project, version, opts} = run(args)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops. that was not intented
--source-ref passed to the CLI was being lost, meaning all links to commits/tags were being lost and the docs were always linked to master
1ba0620
to
ea6cf10
Compare
@milmazz thank your for your input. please have a look again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eksperimental Sure!
lib/ex_doc/cli.ex
Outdated
|
||
switches: [ | ||
extra: :keep, | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing comma after ]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will be weird to have a )
after the comma, ex: switches: [...], )
lib/ex_doc/cli.ex
Outdated
a: :assets, | ||
l: :logo, | ||
n: :canonical, | ||
v: :version, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see, then, It would be nice to see an inline note about your suggestion because it's easy to see the pattern when those aliases are ordered alphabetically, but no when they are listed in same order as the docs, wdyt?
output: "doc", | ||
project: nil, | ||
retriever: ExDoc.Retriever, | ||
source_beam: nil, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT about removing those nil
from defstruct/1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, I was thinking of that. should we use an empty string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default value is nil
, so, you can have something like this:
defstruct [
:main,
:project,
output: "doc",
retriever: ExDoc.Retriever
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but what's the point since those are not required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh. I see now what you mean.
I was thinking why not have a default empty string.
I will be submitting another PR, and because we are using nil
I need to check agains nil
, false
or ""
to see if an option is unset. If by default we set to to empty, we just need to check against false
or ""
(and false is because people may have just used --foo
without value, and it because a boolean argv.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will be submitting another PR, and because we are using nil I need to check agains nil, false or "" to see if an option is unset.
We should continue only checking for nil
. In Elixir, nil
is used for absence of information (except if we have a field that may be boolean).
If the field can be an empty string and an empty string also mean "emptiness", we need to convert the empty string to nil before putting it in the struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have another PR that is waiting for this one to be merged, and it deals with normalizing options individually, I guess I can include this one rule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the field can be an empty string and an empty string also mean "emptiness", we need to convert the empty string to nil before putting it in the struct.
Yes, we should preprocess those empty strings and convert the data to nil
. Also, it looks better doing this:
if options.string_field do
# ...
end
than this:
if options.string_field != "" do
# ...
end
:)
lib/ex_doc.ex
Outdated
project: nil, | ||
retriever: ExDoc.Retriever, | ||
source_beam: nil, | ||
source_ref: "master", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why this is needed. :source_ref
is not needed in the struct inside ExDoc. We only use it initially when building the source_url.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't the struct reflect what can be passed via config, such as CLI or the docs
task?
Line 62 in 05eb89e
* `:source_url_pattern` - Public URL of the project. Derived from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to keep the source_ref around if we don't use it internally. The goal of ExDoc.build_config is build a set of options and build a struct that is relevant internally, if we don't use source_ref past building the config, there is no point in keeping it in the struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I guess if we ever need to find out what was passed by the user, we can add it later to it
|
||
switches: [ | ||
extra: :keep, | ||
source_ref: :string, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. This is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the line that was missing and that caused source_ref to be ditched. So I would say it is a total must to be here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, it is missing it because of the changes in Elixir v1.4 regarding atoms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be best for us to use :strict
then and define all inputs. We can even move to use parse!
so we get proper argument handling.
|
||
@type t :: %__MODULE__{ | ||
canonical: nil | String.t, | ||
deps: [{ebin_path :: String.t, doc_url :: String.t}], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josevalim according to what you said, I am uncertain whether these typespecs should be nil | String.t
or just String.t
as they are.
I have merged this right now so we get proper docs but further improvements based on the comments are still welcome. :) |
--source-ref passed to the CLI was being lost,
meaning all links to commits/tags were being lost and the docs were always
linked to master