Making life easier for new users

What is already easy is to install packages.

What is not so easy yet is:

  1. to create a new user project
  2. to find, copy and execute examples
  3. to create custom system image

I wrote three feature requests for package manager that would make
these three steps easier.

https://github.com/JuliaLang/Pkg.jl/issues/3092
https://github.com/JuliaLang/Pkg.jl/issues/3093
https://github.com/JuliaLang/Pkg.jl/issues/3094

Because not everybody sees Pkg feature requests I post them also here.

Any comments?

2 Likes

Ok, I think the suggestion from Kristoffer Carlsson to prototype these functions in a separate package is a good idea…

1 Like

I kinda agree with the comments there and your conclusion. The functions do not do anything very complex (they take about 5~10 lines of code) and could either be implemented as a convenience by the users that feel the need to use it, or obtained by means of a package. The Pkg is for the building blocks that are impossible to implement outside of it.

Well this one is already 30 lines of code…

I mean, it is not about the question if its only a few lines of code or not, it is about establishing a standard way to:

  1. create user projects
  2. to locate and copy examples
  3. to create system images

To establish a well documented standard way of doing this is important for the user experience. For achieve this goal functions to do this should become part of Pkg at some point in time.

Other modern languages like Rust have standard tools to create a default user project.

3 Likes

Isn’t it Pkg.generate() ?

No, not at all. This generates a new package, but most new users do NOT want to write packages, just want to use a package or a set of packages, run some examples and then write there own code, which will never gets published. And if you teach bachelor students they will not even use git. So a user project is NOT a package. It took me 5 years of being a Julia user before I wrote my first package.

I think of a user project as a place for scripts that use a common set of existing packages without defining any modules.

3 Likes

I thought that Pkg.activateing a directory that doesn’t exist implicitly created a new project?

I am a happy user of the simple jeeves command line utility in Windows.

1 Like

Some of this functionality exists in the Julia for VSCode extension, which is one place to reach new users. For example, system image creation:
https://www.julia-vscode.org/docs/stable/userguide/compilesysimage/

A Wizard.jl package that provided a high level interface over PackageCompiler.jl, PkgTemplates.jl, and Pkg from a standard REPL would be nice.

This is a good concept in general. Iterating this within Pkg.jl would really slow down progress.

1 Like

I will try it out.

Worth mentioning:

DrWatson.jl was designed for scientific projects and has many setup features.

1 Like

Just FYI, I threw jeeves together very quickly and I’d be happy to put some more work into it to make it more usable for a broader audience. I use it for every new project I start and haven’t really wanted anything new (I did add some functionality to make it check for the latest available Julia version a while back, but that won’t work for non-Windows users) but I’d be happy to implement any good ideas that others want to see incorporated : )

2 Likes

From my point of view, item 2 “to find, copy, and execute examples” is the most critical one.
PkgTemplates could be a bit easier to use and get simple default settings, but at least the mechanism is there.
We have add to include packages and dev to work on packages, but there is no good way to get a package and play with the examples.
I am using a slightly cumbersome workflow similar to what I described here: How to use VSCode and REPL to write and test a package? - #33 by mefob
Something like this should absolutely become part of Pkg to establish a standard way to setup packages with examples.