Generating a package with PkgTemplate for existing code

I’ve been writing code a (first) Julia package with src and test folders. It’s saved on my laptop and pushed to a GitHub repo. I’d like to turn my code into a package so that it can be run by others, checks code coverage, to try out Travis etc.

I tried to follow the QuantEcon tutorial, but those instructions are for starting a package from scratch. Since I already have code, I’m wary of deleting something in the process of generating the package, or messing with the git history, leaving me unable to recover my work. If I execute in the REPL:

using PkgTemplate
myTemplate = Template(; dir="mydir", plugins = [TravisCI(), Codecov()])
generate( myTemplate, "MyPackageName; git=false)

will that generate the package with the code in folder mydir, including the mydir git files?

1 Like

I think you are right to be paranoid. The last time I checked, PkgTemplates did git operations on what was generated. I would strongly prefer that it just generated files and left git operations to us, but so be it…

My suggestion is to get the files generated from PkgTemplates and manually merge. For example, generate MyPackageName2, get the generated files and do global search/replace to get rid of the 2,then merge into your project.

1 Like

There is

which does a git init, and nothing more. And it also aborts if the destination directory exists.

3 Likes

Great. Does it support windows?

I haven’t tried. It is written in Julia and needs a git binary, nothing else. Happy to fix if necessary for Windows, just open an issue.

1 Like

Thanks, I will take a look over the summer. Looks like https://github.com/invenia/PkgTemplates.jl/blob/master/src/generate.jl uses LibGit2 instead, which doesn’t rely on having git in the path. I fear a lot of non-programmer users wouldn’t have git installed at the command-line which makes it less robust, but worth pointing out for others who know what they are doing.

What do you see as the primary difference with Skeleton? Do you think of it as being more bare-bones and opinionated on choosing specific options (which, for the most part, I am usually a fan of).

I don’t know enough about PkgTemplates to compare, but I guess when it comes to the implementation, skeleton.jl is more lightweight. The whole code is 100 LOC including frills. It is something one could hammer out in an afternoon (I did), basically replacing text in template files.

When it comes to templates, I don’t think I am very opinionated, I pretty much try to keep up with standard good practices.

3 Likes

Yes, provided that git is correctly found in the PATH (which, as you noted a few posts later, seems to be less frequently the case on windows machines than e.g. Linux in my experience)

Skeleton’s and PkgTemplates’ approaches are very different. Skeleton is definitely more lightweight, with the code being kept to a bare minimum, and all the knowledge in the template (which is nothing more than a bunch of files with anchors). This means it is very easy to use, very easy to extend (just copy/modify the template to include everything you want) but at the same time not very flexible (i.e. it more or less always does the same thing). Also, Skeleton is a script, meant to be run from a command-line (with which I have found Windows users to be sometimes unfamiliar)

On the contrary, PkgTemplate is a Julia package, providing various functions allowing to build templates according to user-provided options (i.e. you may select a different set of options for each project you build, and you can easily create several projects with the same settings). This makes it more flexible, but also less easy to extend (I haven’t looked much into it, but at least I’m sure it’s not as straightforward to extend/modify the templates as with Skeleton; this has been the main showstopper for me). PkgTemplates being a Julia package also makes it easier to user directly from the Julia REPL (e.g. from Juno/VScode for the less tech-savvy users)

On the whole, I have not spent too much time investigating PkgTemplates, but I’ve been a happy user of Skeleton for a few months, the only downside being that when I use it for training windows users, I always run into problems with the git environment and users not being very much at ease with the console…

1 Like

Thanks, much appreciated. Yeah, my general feeling is to push tools that are usable by non-programmers (i.e. usually windows and loath to use a console). But Skeleton sounds like a great solution for those that are a tiny bit more advanced.

I’ve been meaning to transform Skeleton.jl into a package so that users could use it within Juno. (I think Tamas also has it on his TODO list, for different reasons: it would simplify the QA & testing process)

Added to your suggestion of eliminating the need for a specific git configuration (via the use of LibGit2), I think this would make a very fine package generator which would be very easy to use for all users, on all platforms.

But I’ve never really gotten around to it. I do have a hackish solution which I use as a last resort when I encounter too many problems during the Julia trainings, but it’s far from being ready for public consumption. Maybe we could work on this together… What do you think?

Excellent, thanks! I’m now getting stuck in the code_warntype rabbit hole, but will try this once out.

I guess I am not sold that we need a second beginner friendly package template package? If the bread and butter of skeleton.jl is for people willing to work with shell scripts, that seems a perfectly reasonable niche to doubleedown on.

Skeleton will be packaged (as as Julia package) soon. I will also explore using Libgit2. I already have started working on this, just didn’t make it public yet.

1 Like

When I package skeleton.jl, it will be easy to wrap that in a way that can be called from the shell. One package can easily do both things.

Nice! I’m looking forward to it. If you need help doing it or testing it, please don’t hesitate to ask.

1 Like

The new package is here:

@jlperla: thanks for the suggestion about LibGit2, I implemented it.

Testing, code reviews, and feedback is always appreciated.

4 Likes