Introducing “tinpig”

Years ago, I was a big fan of Sublime Text as an editor. It’s a great general purpose editor. There was one thing I missed though. Prior to that, I had mostly worked in dedicated, language/platform IDEs. These always had a “new project” functionality. They knew how to set up a new project in the language they were dedicated to. Because Sublime is a general purpose editor, it couldn’t really supply that functionality, because every type of project is different.

So, I wrote a plugin called STProjectMaker, now, just ProjectMaker. This allowed you to create a template for whatever language/platform you wanted, and create a new project from within Sublime. It actually became fairly popular, with over 6000 installs.

But about four years ago, I stopped using Sublime Text. So I stopped working on the plugin. Issues and PRs and feature requests piled up. Recently Ben Felder asked if the project was still alive and if he could help out getting it into shape. He’s been doing a great job cleaning things up and has brought the project back to life again, which I’m really excited about, and very grateful for.

But, personally, I’m still not using Sublime. So this got me thinking about recreating the basic functionality as a standalone project. Last Friday I sat down and wrote up a list of features I wanted in such a tool. And one week later, yesterday, I released v1.0 of a project codenamed “tinpig”.

tinpig

The concept is pretty simple. You have templates, which are folders of files, potentially with replaceable tokens in them. You choose a template, specify a location and it copies the files over, replacing the tokens with values you define. Not rocket science.

There are other tools out there that are probably way more powerful. I think one of tinpig’s key features is its simplicity. The whole reason you would use a tool like this is to quickly spin up projects of different types. For prototyping, testing stuff, great for creative coding, etc. You don’t want to have to learn a whole new tool or templating language to do that. You can just create a project the way you like it, copy the files over into your templates directory and add a json file with a name and description, and you have a new template that lets you recreate that project anywhere you want within about 20 seconds.

But if you want, you can go in and add tokens and a few other power features to make the project even more powerful.

Just thinking… I should make a tinpig template template. A meta template that makes setting up a template even easier… Sorry, got sidetracked.

Anyway, try it out. If you want. Let me know if it’s useful. Tell me how it could be better.

Oh, if you come up with a useful template, feel free to do a PR in the tinpig-templates repo. Or just chuck it over to me and I’ll put it in there.

12 Comments

  1. Pingback:Introducing “tinpig” – Javascript World

  2. Hi Keith, Thanks for making tinpig! I’ve been wanting something like it for a while. I had a thought for a feature that would be nice for my primary use case.

    I have a boilerplate python Google App Engine project I often manually copy and then update a whole bunch of paths. Because Python module namespaces match their corresponding directory structure, most of the time updating is spent updating module namespace imports to match wherever the particular project was copied to. An example:

    Say the boilerplate project lives at `corp/experimental/boilerplate/googleappengine/`. Several of the files will have include lines like `from corp.experimental.boilerplate.googleappengine import appconstants`

    I _could_ create a token prompt called “namespaced project destination” and during tinpig project creation manually type the namespaced version of the destination. But since I already tell tinpig the destination path to which I’d like to copy the template project, it’d be great if tinpig could do this path -> namespace translation for me. Perhaps there could be a couple special path-related tokens tinpig is aware of for use in templates:

    1. One that represent the specified destination to which the template is copied. Something like “${TIN_PIG_DESTINATION}”
    2. A dot-delimited, namespace version of the specified destination to which the template is copied. Something like “${TIN_PIG_DESTINATION_AS_NAMESPACE}”.

    So then in the main.py template you could have something like:
    `from ${TIN_PIG_DESTINATION_AS_NAMESPACE} import constants`
    and it will translate `~/path/that/was/entered` to `path.that.was.entered`

    Thoughts?

    PS: I first read ‘tinpig’ as ‘tinyping’.

    Reply

    • I was already planning on adding TINPIG_PROJECT_DIR, TINPIG_PROJECT_PATH, TINPIG_FILE_NAME, TINPIG_FILE_PATH. Maybe TINPIG_FILE_DIR too. But these would be absolute paths.

      From there, I could subtract the project dir from the file path to get the path from the root of the project. Then turn that into dot-separated for a namespace.

      The only problem is that that assumes the name space root is the same as the project root. What if a project was set up as project/src/com/foo/thing. The namespace would wind up as “src.com.foo.thing”

      So I think I’d have to add another template property, something like TINPIG_NAMESPACE_ROOT, which in the example would be set to “src”. If left blank, it would assume the project root.

      So, all doable. I just have to evaluate the extra complexity along with how many people would find this useful.

      Reply

      • But… I keep going back and forth on whether or not I actually fully understand your use case. 😐 I may be going down the wrong path entirely here.

        Reply

  3. Nice, I have been looking for something like this for a while.

    I’m not sure if you are looking for features/help (didn’t want to just start making issues in the repo) but if there was a way to display a description of each template and if the project path could auto-complete or auto-suggest, I know that there are some inquirer modules that facilitate this.

    I could probably help with the above features if you are looking for contributors

    Reply

    • Definitely open to any suggestions and will consider any pull requests. My main concern is keeping the tool simple and avoiding feature bloat.

      Reply

  4. Pingback:tinpig 1.4.0 and sales pitch – BIT-101

Leave a Comment

Required fields are marked *.