How do people feel about putting source compiler directives inside rdmd?

[Petar]

On Monday, 2 December 2019 at 22:18:06 UTC, mipri wrote:
>
> I have a bash script that uses 'dub run' to invoke dfmt, and the
> chief problem with that is that any random use of dfmt may
> trigger a slow library upgrade. If shebang uses of dub work like
> this as well, that's a big problem for scripting. In the more
> limited use of dub scripts that I've used, they're fine. Caching
> is very similar to rdmd.

The first time `dub run dfmt` is run, dfmt will be fetched and 
built.
After that you can run it like this:

    dub run dfmt --skip-registry=standard -- <DFMT args>

to skip network checks.

> I'm not fond of /tmp as a default (it's often noexec) but
> there's no variation here in the tooling.

Dub keeps packages and build artifacts in `$HOME/.dub/packages`, 
and in my experience this works really well.

>>> if you require a makefile whenever someone wants to write a
>>> script then python it is.
>>
>> If that's all it takes for someone to use Python, they'll be
>> using Python regardless. I can understand the idea of rdmd if
>> you can use it without configuration. If you're going to add
>> compiler configuration information to your "script", you no
>> longer have a script, you have something really confusing for
>> Python users.
>
> A script is a file with source code in it that you can execute.
> The essential feature of scripts is that the source code is what
> you're executing.
>
> In deployed systems, on servers, in other people's code, when
> you come across a binary that you have a problem with, it can be
> a long adventure to find the source of that binary, and then you
> may still have not found *the* source to *the* binary, but just
> *some* source that could create similar binaries. For example,
> if you find a repo link in a near by document, what commit to
> that repo was used to build the binary that you have?
>
> With a script, the source is always there. This helps enormously
> in troubleshooting, especially hands-on kind of troubleshooting
> where you temporary modify the program to see how this affects
> what you're investigating. If someone has coded in an 
> ill-advised
> restriction, you can temporarily bypass it. If there's a bug and
> the fix can't be deployed for whatever reason, you can tell
> people about a sed oneliner that fixes the script in situ on
> machines where they need the fix. You may not even have access
> to see the repo that the script's source is in, but since you
> have the script you can fix a problem and email the author a
> patch.
>
> The documentation is also often always there, as it can be
> inline with the script. You may be able to 'perldoc
> /root/bin/special_sysadmin_thing' and get more detailed notes
> about the exact version of the exact thing at hand.
>
> Compiler configuration flags change nothing at all about this.

I completely agree.