New pkg.julialang.org

Thanks for this!

Just picked a corner case: a package like Pkg.jl doesn’t show up in the search results.

2 Likes

Pkg is not registered in General. When more standard libraries get their own repos like Pkg it would be nice with a dedicated section for those on pkg.julialang.org. For the time beeing it could be worthwile to special case Pkg to include it.

1 Like

It would be great if there was some way of coordinating the redundant tags, for example there is a math and a mathematics tag… maybe the result lists could be combined for words like that.

All it would take is a list of synomyms, so that equivalent words and tags get grouped. (#16)

1 Like

Once search works, we’ll probably also want to inlcude Julia’s own docs since that badly needs search that works. We can probably have options to search any of:

  • base
  • stdlibs
  • packages
8 Likes

We can machine learn it! :grin:

2 Likes

Well done guys :champagne::cake::birthday:

2 Likes

It looks like it does not support docs/Project.toml? Is there any plan to support docs-only dependencies?

I think we mostly handle docs-only dependencies correctly, but the implementation is a major hack IIRC. So yes, better handling for docs in their own environment is definitely planned.

1 Like

I have a customized docs/make.jl script that is not handled by rewrite_makefile

There seems to be a major issue in how docs/make.jl works — it builds and deploys the docs. I know Documenter works hard to detect Travis environment but I think it’d be much more straightforward if there are docs/build.jl and docs/deploy.jl.

2 Likes

A more declarative way for specifying docs would make a lot of sense, IMHO. Say there was a config file in the docs folder that had all the kind of settings that one currently passes to the two function calls in make.jl, and then Documenter just exported two functions, say build(packagename) and deploy(packagenmae). I think that would make things quite a bit easier.

3 Likes

Anything that works like Pkg.test(packagename) entrypoint for docs (i.e., something that sets up the environment as well) would be great. This way, package writers can check if the docs build for DocumentationGenerator works by locally invoking the same function.

2 Likes

This is very nice to have! I have two questions:

  • Is there a standard link to the page for a given package, not to a particular version? For example to link to latest docs page from the readme.

  • Is there any way to control what functions are included? Some docstrings on functions used internally are just notes to remind myself; perhaps if these functions are named _fun they could be excluded.

No, not yet. We should just link e.g. https://pkg.julialang.org/docs/IJulia/nfu7T/stable to https://pkg.julialang.org/docs/IJulia/nfu7T/1.9.3 though, just like Documenter does.

There is not, see here for more discussion.

1 Like

It doesn’t sounds hard, some word2vec algorithm will be enough.

Ideally, https://pkg.julialang.org/docs/IJulia would be a redirect to https://pkg.julialang.org/docs/IJulia/nfu7T/ when there’s only one package named IJulia or a disambiguation page when there’s more than one package named IJulia and https://pkg.julialang.org/docs/IJulia/nfu7T/ is a redirect to the docs for the current version of IJulia.

Which brings up another question: are we going to have generated docs for all historical versions? If not, what is the point of having the version number in the URL? Doesn’t that just mean that we’re ruining our own SEO by having transient, ever-changing URLs instead of fixed URLs with content that changes over time?

1 Like

If I understood @Venkatesh_D correctly, yes – at least for all versions registered from now on. We could also generate docs for older versions, but do we want that?

Hmm. This is different from what we decided to do for Julia itself. For Julia itself, we decided to have a single page for a given major version (only v1 so far) and then just note in the docs when a feature was added in a given version, e.g. Julia 1.2, that you need at least that version to use the feature. This has the nice property that everyone can always look at the most recent docs, which are usually better and more complete than historical snapshots of the docs.

This used to happen to me all the time with the julialang docs. Google was constantly taking me to v0.4.

One monkey patch I thought of for this would be a banner at the top (like the one some sites use to tell you they use cookies) that just says “do you know you’re not on the latest version of this page? Click here for the current stable version.”

I have no concept of how hard that would be to implement…

Could pkg.julialang.org data be updated one more time, now that METADATA is finished?

How often will it be updated?

We will be updating tomorrow again hopefully, with some bug fixes

4 Likes