Too much time on my hands

Almost a year has passed, and now it’s a suitable time for me to look back, and to look forward.

Two new packages I consider finished. One is PackageMaker.jl (discussed above under the name PackageInABlink), which is a GUI wrapper around PkgTemplates.jl. Another one is ShareAdd.jl - a tool which IMHO could be useful to most Julia users.

I have already some idea about what could be a next project. However I’m open to your suggestions. E.g. maybe somebody has a project where I could take over some part (not too complex, not too boring, not too mission critical, not too unimportant :grinning_face_with_smiling_eyes:).

P.S. Data Science is not my field of expertise.

23 Likes

Now that is an amazing update love hearing about the contributions. Thank you for the great work.

If I may someone had last year mentioned the VSCode Tooling, which just always needs contributors, if that would be something you are interested in looking into in would want to bump that.

1 Like

I would like to second this past suggestion. Julia needs an easy-to-use GUI capability that doesn’t require the user to already be proficient in Qt, GTK, Javascript, or other technologies besides Julia. This is the last piece of the puzzle IMO for Julia to be competitive with Matlab for a certain class of working engineers.

3 Likes

I’d not think it is realistic for me. There may also be other arguments against, but the first one suffice.

I’ve thought of it, too. Most probably it’s beyond my abilities, too, but let’s see.

An important thing for me is also the relation frustration/fun, which may be quite unfavorable in such a project for different reasons.

2 Likes

Here is a thought: AI Coding Tools improve quite rapidly. Especially for “boring” stuff they are quite good and usable already. I imagine that VSCode extensions fall into this category (JavaScript/TypeScript definitely does). If you are interested in using that technology generally, then trying to accomplish some things on a VSCode extension could potentially be a nice project. And you’ll probably learn some new things about JS/TS :slight_smile:

2 Likes

Just to mention that GitHub - domluna/JuliaFormatter.jl: An opinionated code formatter for Julia. Plot twist - the opinion is your own. needs some help to update to JuliaSyntax v1. This is an important tooling for the community and everyone would appreciate work on this, though, I had to admit this might not be too much fun work.

Just another thought: could you make a tool to help us migrate Documenter.jl documentation to DocumenterVitepress.jl? Both are nice documentation offerings, but I find it challenging to migrate Documenter → DocumenterVitepress personally and it takes some time. If there was a package that did this mostly automatically, that would be amazing! :smiley:

1 Like

I’ll take a look: That could be realistic.

1 Like

Great! If there is any info or thoughts I could add, let me know; I’ve worked with both packages quite a lot! I thought you might find it interesting since it kinda goes along in spirit with your previous packages that you were working on.

I personally find DocumenterVitepress.jl terrible. It was not made with end users in mind. Documentation is harder to read IMHO.

First and foremost, with documentation generator for Unitful.jl :grinning_face:

Now, my first questions:

  • What is the rationale of migration to VitePress?
  • VitePress is currently at v2.0.0-alpha. In now the suitable timing for migration?
  • Any examples of DocumenterVitepress.jl docs sites?
1 Like

None.

And keep in mind that VitePress requires external dependencies that are not written in Julia. It simply complicates the documentation builds. At least that is what I remember the last time I looked into it.

Great questions! Let me see if I can help; I’ll also CC the DocumenterVitepress guru @asinghvi17 for adding additional thoughts:

These are my own subjective thoughts but:

  1. The searching built into DocumenterVitepress is super robust. It is much nicer and featureful than the search in Documenter.jl
  2. I find the layout to be a bit more intuitive and the organization hierarchy easier to manage (i.e. you can have tabs and drop-down tabs for multiple pages)
  3. Navigation across pages feels easier
  4. Highly subjective but I think it looks quite beautiful and streamlined for advertising a package

I’ll let @asinghvi17 answer on this; it’s a good question. I didn’t realize that was the current version so thanks for the heads-up!

Sure! Here are some nice ones:

  1. Makie.jl
  2. Lux.jl
  3. Tidier.jl

In particular, I like how nice it can be for larger ecosystems like Makie or Tidier. Feels like it can help with unifying things.


Let me know if I can help with any more thoughts or pointers! :smiley:

1 Like

Well, first and foremost obviously the docs of the DocumenterVitepress.jl :grin:

Now, the documentation of the Documenter.jl itself, in the ideal case, should

  • Illustrate how the standard no-frills Documenter-produced docs look like. That is what IMO >90% package authors are interested in and would be happy with,
  • Showcase some special options,
  • Well, actually document the package.

For the first two items, the Documenter.jl docs should be produced with Documenter.jl itself. IMO it would be very strange to have it done with some additional package.

All these three items are equally subjective. Actually I find the Documenter navigation easier, also because it is consistent between many packages and the docs of Julia itself.

As for advertising a package: The docs of e.g. Makie.jl should be beautiful, if possible. The docs of Documenter.jl could better be modest and functional.

In short: Maybe I’m misunderstanding or overlooking something, but as I see it now, I’d strongly prefer for Documenter.jl docs to stay as they are, i.e. produced by the package itself.

3 Likes

On the cursory check of the DocumenterVitepress.jl, it doesn’t seem to be the case. Are you sure? In any case this is IMO irrelevant for the case in question.

May I politely note you are not in the position to know it for sure, as it was not your decision :neutral_face:

2 Likes

Of course. What I am trying to say is that the DocumenterVitepress.jl movement is not a community movement. It is a movement by 3 or 4 people. That is why I interfered to make sure it is crystal clear to anyone interested in this topic that Documenter.jl is the most widely adopted documentation system for Julia packages.

Appreciate the polite note.

2 Likes

Ah those are totally fair points! Yea, I agree with your back of the envelope estimate of ~90% of package authors are interested in something more no frills – although I may slightly drop that estimate to 80% :joy:

Ah that might’ve been me not being terribly clear: I was thinking of a tool that could migrate previous repos that use Documenter.jl to DocumenterVitepress.jl. Definitely would not want to change what Documenter.jl is doing at all and as DocumenterVitepress builds on Documenter.jl, it would not. What I was hopeful for was that if there was a tool that could make this transfer easier.

As an example, within JuliaHealth, we are trying to more or less migrate a majority of our package documentation to DocumenterVitepress to modernize it as well as promote consistency and branding of JuliaHealth across our packages.


But yea, this is a highly subjective thing, but I was thinking it could be a fun/nice option. But definitely if it doesn’t inspire you, then this could be a project for another day!

Thanks so much for the consideration nonetheless @Eben60, eager to see what you come up. :smiley:

OK, so it obviously a misunderstanding. So, you don’t want to migrate the documentation of Documenter.jl itself, which can be found under Home · Documenter.jl , to have that very documentation to be produced by anything else than Documenter.jl – do you?

Now, DocumenterVitepress.jl tells:

Basic usage

  1. Import the package in make.jl,
  2. Pass format = DocumenterVitepress.MarkdownVitepress(...) to makedocs
using Documenter
using DocumenterVitepress
makedocs(;
    format=DocumenterVitepress.MarkdownVitepress(repo = "...", devbranch = "...", devurl = "dev"),
    )

and enjoy the fruits of your labour!

Do I understand you correctly, that’s not enough, and some additional conversions are desirable?