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: #!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source 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: #!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source 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: #!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source 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