www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - rdmd configuration files

reply Jonathan Marler <johnnymarler gmail.com> writes:
The use case is you have a collection of D scripts within the 
same directory subtree (maybe a git repo) that all share some 
common configuration. Maybe they all require extra search paths 
to find source/libraries, or they all throw exceptions to the 
user and should be compiled with debug symbols so exceptions 
print their full stacktrace, etc.  Rather then requiring the user 
to call the script in a particular way or wrapping all the 
scripts with yet another tool, what about adding support in rdmd 
for configuration files?  The configuration file could live in 
any parent directory of the script being ran:

FileSystem:
   /a/b/c/myscript.d

Shell:
/a/b/c> rdmd myscript.d

rdmd checks for /a/b/c/rdmd.config
rdmd checks for /a/b/rdmd.config
rdmd checks for /a/rdmd.config
rdmd checks for /rdmd.config

The rdmd.config file would apply to all rdmd scripts in all 
subdirectories on the file system.  It works similar to how git 
determines whether or not it lives in a repository (searches all 
parent directories for the .git directory).

Additionally, allowing rdmd to be configured through files makes 
more complicated configurations more reasonable.  For example, if 
your scripts depend on a dub package, you could do this easily in 
a configuration file, whereas doing this on the command line 
would be a nightmare.

Supporting this type of configuration could easily be implemented 
in a wrapper around rdmd (rdmdc?), however, if this idea is 
generally useful then it should be added to rdmd itself so 
everyone benefits.  The question is, is this feature general and 
useful enough to justify adding to rdmd itself, or is this only 
useful in rare cases meaning it should live inside an rdmd 
wrapper?
Aug 11 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Thursday, 11 August 2016 at 18:47:05 UTC, Jonathan Marler 
wrote:

 The use case is you have a collection of D scripts within the 
 same directory subtree (maybe a git repo) that all share some 
 common configuration. Maybe they all require extra search paths 
 to find source/libraries, or they all throw exceptions to the 
 user and should be compiled with debug symbols so exceptions 
 print their full stacktrace, etc.  Rather then requiring the 
 user to call the script in a particular way or wrapping all the 
 scripts with yet another tool, what about adding support in 
 rdmd for configuration files?  The configuration file could 
 live in any parent directory of the script being ran:

 FileSystem:
   /a/b/c/myscript.d

 Shell:
 /a/b/c> rdmd myscript.d

 rdmd checks for /a/b/c/rdmd.config
 rdmd checks for /a/b/rdmd.config
 rdmd checks for /a/rdmd.config
 rdmd checks for /rdmd.config

 The rdmd.config file would apply to all rdmd scripts in all 
 subdirectories on the file system.  It works similar to how git 
 determines whether or not it lives in a repository (searches 
 all parent directories for the .git directory).

 Additionally, allowing rdmd to be configured through files 
 makes more complicated configurations more reasonable.  For 
 example, if your scripts depend on a dub package, you could do 
 this easily in a configuration file, whereas doing this on the 
 command line would be a nightmare.

 Supporting this type of configuration could easily be 
 implemented in a wrapper around rdmd (rdmdc?), however, if this 
 idea is generally useful then it should be added to rdmd itself 
 so everyone benefits.  The question is, is this feature general 
 and useful enough to justify adding to rdmd itself, or is this 
 only useful in rare cases meaning it should live inside an rdmd 
 wrapper?


In my opinion, adding this complexity to rdmd is overkill. When 
you need to use this, IMHO, you should write a little shell 
script that calls rdmd passing the correct arguments. It's very 
easy, just a couple of lines of shell script. Maybe even a 
one-liner.

In file rdmd_wrapper.sh:
rdmd -my-special -command-line -parameters $*

When you call it this way:
./rdmd_wrapper mymodule.d

It will execute this:
rdmd -my-special -command-line -parameters mymodule.d

If you need the same configuration really often, you can add the 
wrapper to the path, so you can call it from everywhere.

But this is just my opinion, many may disagree.
Aug 11 2016
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 11 August 2016 at 20:44:12 UTC, Lodovico Giaretta 
wrote:

 On Thursday, 11 August 2016 at 18:47:05 UTC, Jonathan Marler 
 wrote:

 ...
 Additionally, allowing rdmd to be configured through files 
 makes more complicated configurations more reasonable.  For 
 example, if your scripts depend on a dub package, you could do 
 this easily in a configuration file, whereas doing this on the 
 command line would be a nightmare.


 In my opinion, adding this complexity to rdmd is overkill. When 
 you need to use this, IMHO, you should write a little shell 
 script that calls rdmd passing the correct arguments. It's very 
 easy, just a couple of lines of shell script. Maybe even a 
 one-liner.

 In file rdmd_wrapper.sh:
 rdmd -my-special -command-line -parameters $*

 When you call it this way:
 ./rdmd_wrapper mymodule.d

 It will execute this:
 rdmd -my-special -command-line -parameters mymodule.d

 If you need the same configuration really often, you can add 
 the wrapper to the path, so you can call it from everywhere.

 But this is just my opinion, many may disagree.


I don't necessarily agree or disagree with you, thanks for 
providing your opinion.  A wrapper script would certainly solve 
the simple cases.  The con is that it adds an extra layer to the 
script and every application will have their own solution which 
makes a project more isolated.  The wrapper script was the first 
solution that came to my mind but as I thought about 
configuration files, they seemed worth considering.

I'm curious what you think about the more complex operations that 
configuration files could facilitate. The example I gave was that 
this could enable a script to use dub package dependencies that 
are automatically downloaded and built by rdmd, but I'm sure 
there are other interesting use cases.  An argument could be made 
that this should go in an external tool rather then rdmd though, 
but that thought seemed a bit odd since rdmd is already a wrapper 
around dmd itself, but maybe that's ok.  Do you have any new 
features rdmd could support if it had configuration files?
Aug 11 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Thursday, 11 August 2016 at 21:33:24 UTC, Jonathan Marler 
wrote:

 On Thursday, 11 August 2016 at 20:44:12 UTC, Lodovico Giaretta 
 wrote:

 On Thursday, 11 August 2016 at 18:47:05 UTC, Jonathan Marler 
 wrote:

 [...]


 [...]


 I don't necessarily agree or disagree with you, thanks for 
 providing your opinion.  A wrapper script would certainly solve 
 the simple cases.  The con is that it adds an extra layer to 
 the script and every application will have their own solution 
 which makes a project more isolated.  The wrapper script was 
 the first solution that came to my mind but as I thought about 
 configuration files, they seemed worth considering.


I agree that a custom wrapper script has the drawbacks you said.
But I fear that a configuration-file-based system would either 
only solve simple cases or would become very complex and 
difficult to master in order to accomodate to most special uses, 
thus becoming less appealing than a simple script.
A config file format is one more thing to know and to look up: 
"how do I do this with rdmd-config?", while the Internet is full 
of tutorials on "how to do this with bash". The same happens to 
DUB: it allows to do many things when building the project, so 
people asks "how can I do this with DUB?" while it would probably 
be easier to just write a shell script that calls DUB and then 
(or before) does the other thing.
We should avoid reinventing the wheel.


 I'm curious what you think about the more complex operations 
 that configuration files could facilitate. The example I gave 
 was that this could enable a script to use dub package 
 dependencies that are automatically downloaded and built by 
 rdmd, but I'm sure there are other interesting use cases.  An 
 argument could be made that this should go in an external tool 
 rather then rdmd though, but that thought seemed a bit odd 
 since rdmd is already a wrapper around dmd itself, but maybe 
 that's ok.  Do you have any new features rdmd could support if 
 it had configuration files?


I think that many reasonable but not-trivial things can already 
be done with DUB, which allows custom compiler and linker flags, 
custom commands before and after the build, different 
configurations and so on. It is already a very complex 
configuration system, and can also do the job of rdmd ("dub run" 
executes the project, using a cached compiled file if available 
and up to date, as rdmd).
DUB also allows to have single-source packages, where the DUB 
configuration and dependencies are embedded in a comment at the 
beginning of the source, which would be a great solution for your 
example, as it doesn't even require a configuration file.
Aug 11 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 11 August 2016 at 22:14:35 UTC, Lodovico Giaretta 
wrote:

 [...]


I didn't know about that last feature, that's pretty cool. Maybe 
dub is the right way to go, thanks for the input.
Aug 11 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Thu, 11 Aug 2016 20:44:12 +0000, Lodovico Giaretta wrote:

 In file rdmd_wrapper.sh:
 rdmd -my-special -command-line -parameters $*
 
 When you call it this way:
 ./rdmd_wrapper mymodule.d


You can add parameters inside the file itself:


void main() {}

Maybe not ideal but it works.
Aug 11 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 11 August 2016 at 21:58:35 UTC, Chris Wright wrote:

 On Thu, 11 Aug 2016 20:44:12 +0000, Lodovico Giaretta wrote:

 In file rdmd_wrapper.sh:
 rdmd -my-special -command-line -parameters $*
 
 When you call it this way:
 ./rdmd_wrapper mymodule.d


 You can add parameters inside the file itself:


 void main() {}

 Maybe not ideal but it works.


This does work when you use rdmd myscript.d does it?  Only when 
you run ./myscript.d?
Aug 11 2016
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 08/11/2016 06:04 PM, Jonathan Marler wrote:

 On Thursday, 11 August 2016 at 21:58:35 UTC, Chris Wright wrote:

 On Thu, 11 Aug 2016 20:44:12 +0000, Lodovico Giaretta wrote:

 In file rdmd_wrapper.sh:
 rdmd -my-special -command-line -parameters $*

 When you call it this way:
 ./rdmd_wrapper mymodule.d


 You can add parameters inside the file itself:


 void main() {}

 Maybe not ideal but it works.


 This does work when you use rdmd myscript.d does it?  Only when you run
 ./myscript.d?


And only on posix, not windows.
Aug 26 2016