Summary Julz is a command line utility for creating ambitious Julia applications. Its goal is to remove many of the petty decisions involved in starting a project and establish a standard that can be adopted by the entire Julia ecosystem. In this way it channels Ruby on Rails’ mantra of “convention over configuration”: tell people where files should go, but allow them to tweak it if they so desire.
- Code available at: https://github.com/djsegal/julz - (see readme.rst as well as included dummy Julia project) Description >> julz new <app_name> // start new julz project The problem Julz attempts to resolve is architecting a Julia project that is resilient to both the frequent on-boarding/turnover of engineers as well as the mass accumulation of files. In this way, a person reading a codebase for the first time does not get bogged down by the sheer number of files that have accumulated over time inside a shallow depth src directory. >> julz generate <generator> <name> // generate julia files The way to alleviate this problem is to treat the src folder and the test folder as boxes that hold smaller boxes of like content. In a Julia context, this means that the src and test folder each have corresponding subdirectories for: methods, types, functions, macros, etc. Each subdirectory then has an associated generator command that can be used to make files of that format. For example, generating a SymArrow type with two array fields from the command line would use boiler-plate templates to compile: - a working sym_arrow.jl file in the ‘src/types’ directory - an associated sym_arrow_test.jl in the ‘test/types’ directory >> julz test // test julz project This may not seem like a big idea at first, but getting every project to adopt this level-deeper folder structure is the cornerstone to a successful framework. With it, packages can be created that expand on the native collection of data structures, i.e. to produce singletons, compilers, etc. Here, the addition of generators just make everything less user-error prone and promotes adequate test coverage of code. >> julz install // install Julia packages One aspect of Julia that is currently lacking is a comprehensive solution to package management. The REQUIRE file and the currently unreleased “.lock” file are obviously the right ways to go, but I personally think reinventing the wheel for this case is a little extreme. Therefore julz uses a “Gemfile” and “Gemfile.lock” approach taken directly from the Ruby community. Imitation is the finest form of flattery and their backend support of package installation is second to none. Out of the box it supports local packages, multiple package hosts, version compatibility resolution, and environmental controls. >> julz run // run julz project The final piece of the puzzle julz adds is a config folder for user’s to both alter the default conventions of the language/framework *and* separate environmental logic. Altering the default conventions could be something: - as language specific as allowing -0 to equal +0 - or something more architectural, like adding a “services” subdirectory to both the /src and /test folders. Environmental logic, on the other hand, is used in its web development context in which labels are applied to the different ways you run your code: - development (local machine) - test (testing suite) - production (network clusters) Then, decisions can be made built off this knowledge. For example, you could default to single precision for your test suite, double precision on your local box, or quadruple precision in production — all set without explicit reference inside your src directory. >> julz send // send julz project elsewhere (unimplemented) This is where julz stands. Admittedly, it is still very much in its infancy. The goal therefore is to accomplish what ember-cli did for the ember.js community and get everyone on the same page when it comes to project layout and development. In this process, hopefully we can foster a sense of community for our users and lessen the fatigue of navigating through a project.
