~skiqqy/skelly

The standalone project init system
7f4a4f7b — Stephen Cochrane 11 months ago
Small fix to C production
f93cd850 — Stephen Cochrane 11 months ago
Moved away from log4j2 towards slfj and using logback as an impl
7db07c9c — Stephen Cochrane 1 year, 9 months ago
Updated java git ignore

refs

master
browse  log 

clone

read-only
https://git.sr.ht/~skiqqy/skelly
read/write
git@git.sr.ht:~skiqqy/skelly

You can also use your local clone with git send-email.

#Skelly

A standalone project init system.

#Usage

Simply run:

$ skelly help

#Quickstart

To jump right in:

$ skelly new PROJECTNAME LANGUAGE LICENSE

#Description

Skelly solves the problem of setting up the skeleton files and directory layout of a new project, these files include.

  • License
  • Man Page
  • Makefile
  • Basic build environment
  • A CI yml file (for source hut builds).
  • Init a local git repo.

#Productions

So before you can use skelly, you must first understand the concept of a production.

A production is simply a set of instructions (written in bash or POSIX sh) that setup a project directory.

Now that you understand what a production is, let us explore how to create them, currently there are two methods, namely "in script" and "local" productions.

Note that a language can have at most 1 local and in script production (ie you can have both).

#In Script Production

An in script production is simply a function defined in skelly of the form

init_<LANGUAGE> With language specifying which (you guessed it) programming langauge that production is for.

By default skelly ships with:

  • init_sh -> Init any shell script (bash, sh etc).
  • init_c -> Init a C project.
  • init_java -> Init a java (maven) project.
#Local Productions

Please note this feature is still a WIP and is subject to change.

Local productions are directories of the form:

<LANGUAGE>:
          |
          |-- init.sh     [MANDATORY]
          |
          |-- artifact(s) [OPTIONAL]

With the name of the direcory specifying the the language that production targets, the only mandatory file that needs to be present is init.sh, which purpose will be explained below. Artifacts are optional, and can either be files or other directories.

The init.sh is very similar to an init_<LANGUAGE> function used by in script productions. The job of init.sh is just to setup the project directory, you can do this however you want, but it must be written in either bash or sh.

These local productions are normally kept inside a single directory, by default this is $HOME/.skelly, but this can be changed through command line arguments.

#Scripting of init*

Both productions take 2 arguments,

  • First Argument: Name of the project
  • Second Argument: Name of the project

Finally it is important to note that when writing init_<langauge> or init.sh functions or scripts respectively that you must write it from the perspective that you are inside the root directory of the project being created.

That is, suppose we have the following instructions for a project MyProject (written in either init_<LANGUAGE> or init_.sh).

echo "$1" # Print the name of the project.
echo "$2" # Print the license to be used.
mkdir -p a/{b,c}
echo ABCD > README.md

Then the directory MyProject that was created will look something like:

MyProject:
         |
         |-- a:
         |    |
         |    |-- b
         |    |
         |    |-- c
         |
         |-- README.md
#Production conflict resolutions

Earlier I said,

Note that a language can have at most 1 local and in script production (ie you can have both).

Skelly will always defer to local productions before script productions, that is a script production is used iff a local production cannot be found.

#Commands

Simply run:

$ skelly list

#Command Help

To get help with a specific command, run:

$ skelly help <command>

#TODO

  • Bootstrap skelly with skelly!

License: