Scriptlike: New lib to aid in writing script-like programs

[Nick Sabalausky]

On 2/11/2014 8:10 PM, Jesse Phillips wrote:
> On Wednesday, 12 February 2014 at 00:07:42 UTC, Nick Sabalausky wrote:
>> I think that would fit very well into Scriptlike, as long as you don't
>> mind it all being in the same module as the rest of scriptlike, and
>> preferably using same formatting style (not that that's strictly
>> important, but consistency is nice of course).
>
> Forgot that I wanted to say, I think considering the goals of the files
> it may be reasonable to have them separate. Solving the extra import can
> be done with something like package.d, but maybe you also want to reduce
> file count for some reason?

Honestly, I had a hard time deciding whether to do single-file or 
package.d.  Package.d is great, but the (minor) downsides are:

1. If you download the source files manually (maybe someone who isn't 
onboard with git or dub yet?), there's more to do: Either download more 
than one file, or download one file and unzip. Versus just "download 
this file and use it".

2. You still have to either pass all the files to DMD, or add an extra 
-Ipath to your RDMD call.

Normally I'd consider both of those trivialities and wouldn't worry 
about them, but scripts are usually just trivial single-files anyway, so 
just adding any dependency at all to a script is a potential deterrent. 
Even if only a subconscious one. So I wanted to keep it as trivial as 
possible.

Ordinarily, separate source files and maybe a package.d would definitely 
be the way to go. But the idea of expecting people to add a dependency 
to typically zero-dependency scripts seems like it's already a battle 
against inertia right from the start. So a "whole package" instead of 
"one file" just seems like needlessly hurting things even more.

However, maybe I could get the best of both worlds...

What if it was maintained as separate source files, with a package.d, 
but then I had a pre-commit hook to run a script that combined it all 
into one file (just stripping out the "module xxxx;" statements)? 
Pre-commit hooks, unfortunately, can't be included in the repository, so 
it wouldn't run for contributors (unless they went to the bother of 
setting it up), but I wouldn't mind doing it myself after merging pull 
requests.

Then again, maybe *that* complication could scare people off (esp. 
contributors), and maybe I'm worrying too much about the subconscious 
(or conscious) resistance to including external dependencies into 
trivial scripts?