I’ve been prototyping a tool for performing basic Julia language operations from the command line; it’s intended to be used by new users to Julia, especially students and first-time programmers. Because of this, the tool is able to:
download and install Julia (via juliaup)
set up a startup.jl file, with a pre-configured template compatible with PkgTemplates.jl
start the Julia repl (mce jl)
start a Pluto notebook (mce jl pluto)
start VSCode with a Julia Repl in the terminal (ie. in the terminal from which the mce jl edit command is called)
set up a quick script (using Pkg.generate(), but also set up docs and testing along with it) (mce new script <script_name>)
set up a package (using PkgTemplates) (mce new package <package_name>)
generate an app, which can be compiled with either PkgCompiler or via the Maurice (mce) tool (mce new app <app_name>)
compile an app (mce compile app <src_dir> <target_dir>)
and also perform basic package management functionality such as adding, removing, updating (listing) packages, etc.
(for the full list of features and commands, see the README file on Github; link below)
The tool tries to be friendly - for instance, if you don’t provide the names of source and target directories when compiling an app, then Gaston will ask you for them explicitly.
I was wondering if anyone would be interested in providing some feedback at this stage?
I’d like to know more about people’s workflows, and how we can make them faster / easier with this command-line tool.
There are a few more features I plan to add, but the basics are in place, and I’m very open to feedback or (kind) criticism…
Or, if anyone would like to help out with further development, let me know and I’ll clean up & the document the code base more fully to make it easier for collaborators to contribute.
Note: the project is written primarily in Rust, with some Julia mixed in.
I’d like to include some hooks within the Julia code so that it becomes more “hackable” for Julia users, too, as they progress in their understanding of Julia.
Just a quick comment… there’s already another package with that name. This package and yours are different enough that it might not be a problem, but it may end up confusing users.
Stupid question from me as usual. If I run mce new to set up an environment in a particular directory then I start Julia - is the current working directory my project directory?
This is one of my pet peeves about Julia on Windows - by default the current working directory when a simple Julia session is started is C:\Users I often give up on investigating a dataset or an example code as I cant be bothered to navigate the Windows directory structure.
I have OneDrive as my Documents folder and I find it a pain to navigate to there.
Also I use MobaXterm which when a terminal is opened has my ‘home’ directory under Documents.
just be aware that the project isn’t fully Windows compatible at the moment; however, once I get my windows machine up and running on my old computer I’ll be working on Windows compatiblity.
There’s just a few commands to modify to make it fully compatible with Windows.
I’ve tried to operate by “the principle of least surprise” with this tool: if you’re working in a directory, then that’s where your files show up.
Even packages are created in the current directory, by default (instead of in $HOME/.julia/dev).
I know that particular choice goes against the grain for the Julia community, but it’s what most people expect when you create a new script/app/package.
(To be precise, mce new script or ..new app or ..new package will request a name from you if one is not provided, then a folder will be created with that name in the current directory. As you would expect. You don’t have to go hunting around for where your files were created the first time you encounter Julia with mce).
@diversable I like the concept of being prompted and a new directory created. That would make good sense. Of course please add a check to stop existing directories being clobbered
As of now, nothing is over-written. The worst that can happen is a there’s a few extra files in a pre-existing directory when you create a new project.
Would you prefer it if checks were done to prevent the “extra files in an unintended (pre-existing) directory” behaviour?
I am not sure about the answer here.
I would think a simple check if the directory exists.
Then a message “Dave - I really think you should not do that”
Add a --force flag which goes ahead with the configuration even if the directory exists
@johnh: I’ve done a little patch that changes the default behaviour to just ‘bail’ when trying to create a script, app, or package in a pre-existing directory (no garbage/clutter will be created).
Wow this looks very nice. I think that at some points it overlaps with ION and the Comonicon project. Posted them if it is helpful to contrast and get some ideas.
There is indeed some overlap, but I’m not sure if the goals of our projects are the same: I’m primarily targeting new (as well as experienced) Julia users and CLI UX for a range of common (primarly non-repl) workflows in Julia. (Hence features like mce jl pluto which starts up Pluto notebooks for the user).
Our differing areas of focus lead to much different choices, and hopefully a differentiated UX: for instance, Maurice will both install Julia for you and create a default (github-based) PkgTemplates template for you in your startup.jl file on first launch; Maurice will ask for arguments if you forget to provide them; etc. The idea is to teach new users Julia ‘best practices’ and concepts (like using a startup.jl file) by using the Maurice tool; and for experienced users, provide them one single tool that can speed up their command-line development workflow, no matter whether the user is working on a simple script, a Julia application, or a Julia package to be used by others in the community.
The other tools you mention don’t seem to provide these kind of ‘nice-to-have’ UX & teaching features for Julia newbies. Ion in particular does seem like a great project though, if you’re looking for a more package-management-focused feature-set…
Also, in the future, I’ll be adding a GUI to the application - I don’t know if those two projects would appreciate the added complexity that I’m willing to introduce in the Maurice repo to make a GUI happen for new Julia users.
That being said, there is certainly something to learn from each of the projects you mention - so thank you for pointing them out!!!
What a coincidence! I was going to release this new version of Ion written in rust (it was previously written in Julia with Comonicon). And yeah indeed there are some overlapping, Ion is focused as a developer tool in the terminal that is similar to cargo, npm, yarn so it is a terminal client for Julia’s Pkg with a few convenient tools for developers.
Some of the feature in mce is definitely inspiring, such as starting a Pluto notebook, I was actually thinking to support CLI plugin like what cargo does, but this gonna take some time. As for building system image or application that’s something already supported in Comonicon’s builder, maybe it’s a good idea to have it in ion.
but anyway, just want to say it might be worth joining efforts on some overlapping features.
@Roger-luo - I’m very glad you got in touch! There are indeed some areas of overlap that warrant further discussion and collaboration.
I don’t think we need to replicate package management code across multiple projects, so perhaps we should try to collaborate on a re-usable Rust crate to provide Pkg features…? It looks like you’re further along in package management features as of now, so your code base may be the best place for us to start - if you’re interested in creating a shared abstraction, of course.
If you’re interested in implementing some of the other features Maurice (mce) has, let me know and I can help – whatever it takes to provide helpful and efficient tools for the Julia community!
If not for the GUI planned for Maurice, I would say that we should just collaborate on a single shared project - that is, unless you’re willing to get on board with that (admittedly large and hairy) feature…?
Thoughts?
–
I really like your plan to support CLI plugins for a Julia package manager, similar to Cargo – that’s something I also had on my “sometime in the future” list of features to implement!
Two other features I’m working on which you might find interesting are:
a command execution system for Julia one-liners (such as “using Franklin; Franklin.serve()”). It’s inspired by and with some code borrowed from the Pier cli app wrtten in Rust (see: GitHub - pier-cli/pier: A Linux script management CLI written in Rust). Users would be able to create aliases for their one-liners like the Franklin serve example, and run them with mce run <alias> - for example, mce run franklin.
a hooks system, to enable Maurice to be more ‘hackable’. That is, Maurice users could write their own custom Julia code to run after any mce ... command. I’m not sure how people might end up making use of it yet, but once it’s there I’m sure people will think of some way to make it interesting.
Looking forward to seeing how we can work together to move forward on our projects, @Roger-luo !
Ion actually has two parts, the ion crate that implements the functionality as a rust crate, and the ion(bin) which is the thing you download. Maybe we could just use this crate, or I could move out some of the functionality to a separate on. The crate is not registered because it was mainly used by myself, but you could try it by giving the cargo the URL. The Julia script runner is in https://github.com/Roger-luo/Ion/blob/main/src/ion/utils/julia.rs
you can find examples of using this crate in the binary project.
Thanks, I’m currently mainly not sure how this would be provided, a separate registry or just use crate.io, the latter seems easier. I think clap already supports this so just need to turn it on.
I actually had the same thought at the beginning, e.g npm and yarn also have something similar to this, but then I see just which makes me decide to just let people use just. It may take an extra step to install, but I think just has a lot richer feature than script alias.
I think Ion will mainly focus on a developer’s CLI tool, I also don’t have GUI use cases from my end, so please feel free to use the crate for your GUI development and we can probably share some common functions.
