How to make the hydra output directory configurable from configuration?
Like, I'd like to be able to specify the directory that hydra dumps it's hydra.yaml to, instead of it being hardcoded to outputs.
I imagine one way to achieve this could be something like:
have an option to instantiate hydra without dumping the config to outputs
have a hydra method taht will dump the hydra config to a folder of our choice
Thoughts?
You can override hydra.output_subdir.
See this.
Related
Is there a way to have build.sbt configured so that (additional) specified subdirectories are created if they do not already exist?
I would like build.sbt to create: ./target/test-temp, and ./target/test-log.
For example, I intend to have logback-test.xml configured to log to ./target/test-log/output.log. As far as I can tell, this will make it easier to write tests on the log output itself.
I have just set up MRTG server. Now It can get SNMP info from our router.in the first we create config file by using cfgmaker, everything is ok. We can get graph well. We have edit something on our config file about maxbytes or something like that. Afterthat we have just bring up new interface on our router. When we run cfgmaker again, it will create config file with new interface, but all thing that we edited, has been reset to default.
How can I create config file for specific interface that I can point out it. I don't want it run again for old interface that I create in previous. Please help me!!!
The cfgmaker utility will always generate a complete new configuration file. It will not modify an existing file.
If you have customisations that you need to be done, you have a few options.
Firstly, you could just cut and paste the new interface stanza from the newly generated configuration file into the old one.
Secondly, you could use the various options to cfgmaker to customise global options, or how the interfaces are filtered, labelled and identified; whether this is enough will depend on what your customisations are.
Thirdly, you could use a host template or interface template to fully customise the output, adding targets or options. Various templates are available at http://cfgmaker.steveshipway.org/ for download. This will require a little Perl coding knowledge.
I used to write my configs for Symfony project like this in config.yml file:
my_bundle:
internal_identifier: %test%
key: %someparam%
endpoint: %nobil_endpoint%
and used parameters.yml (which was ignored by git) for allowing other developers to have different values.
Bu I think using this:
my_bundle:
internal_identifier: my-identifier
key: 12345
endpoint: www.endpoint.com
still allows developers to have different values because they can use config_dev.yml which is also ignored by Git.
So my question is this: what's the purpose of parameters.yml file if config_dev.yml can be used for the same thing?
I think two things are being asked here:
Why is parameters.yml ignored be the default Symfony .gitignore file?
Why use parameters.yml instead of config_dev.yml?
Per the first question, parameters.yml is ignored by default because this file is meant to hold settings which are per-installation. For instance different developers might need different database settings. If parameters.yml wasn't ignored, your "personal" settings would be copied to every developer.
As of Symfony 2.3 you should put the needed parameters, along with default values, in a file called parameters.yml.dist. Then, when you run composer install a composer script will check for this file and create/update your local parameters.yml file, prompting you for each setting which gives you the opportunity to change the settings to be relevant to the given install.
Per the second issue, parameters are considered different than config settings. Parameters are settings which will change install to install, whereas config settings will stay the same for all installs of a particular app (although they may be different from dev to production environments.)
first, what is ignored by git is up to you, there is a .gitignore file in your repo-root
my advice to use different parameters would be:
you have different parameter.yml´s like :
parameters.yml.dev.one
parameters.yml.dev.two
parameters.yml.dev.three
and for example you are developer one then you make a symbolic link to "your" parameters.yml.dev.one like :
cd app/config; ln -s parameters.yml.dev.one parameters.yml
so now there is a parameters.yml on your machine that points on your parameters
developer two would make a symbolic link to his parameters and so on
if you are not clear about the difference between parameters and config, please check symfony book
you can do the same with your stages when you need for example another database-connection on prelive or live or whatever by using symbolic links
the advantage of this is that every developer has the parameters of every stage and developer on his machine
cheers
Being ignored by Git is the most useful, but it also prompts you for missing values when doing composer install.
If you want to have common parameters that are not ignored, you can create a parameters_common.yml and source it in config.yml (or add them directly in config.yml).
For an advanced use of config/parameters files, I suggest you check https://github.com/wemakecustom/DirectoryLoaderBundle
Because where you are in production environment, symfony needs to work in PRODuction environment and not in DEV.
Why you removed config_dev.yml from repository?
I'm trying to leverage GruntJS to create a build process that is uniform across multiple teams and projects at my company. The idea hear is that we have a config file for each application that only specifies the files that need to be processed and what bundles they need to be concatenated into at the end. The build process would be the same for all apps: pick up the config for the app, process files in each bundle using a uniform build process.
For Example:
asset.json config file specifies two bundles, "main" with 1.js + 2.js and "secondary" with 2.js and 3.js
Build process says for each bundle, preprocess, minify, then concatenate into a js file based on the bundle
Get output of "main.js" and "secondary.js"
The problem I'm running into is that Grunt takes a "static" configuration and executes it. I've already abstracted out the building of the configuration so that I can add chunks dynamically, but right now I don't see a better way forward than literally looping over each bundle and building out a unique task for each section of the build process for each bundle, building up queues of tasks to execute, and then running each task in the queues during the build process. Its definitely possible, but its a lot of manual work and seems prone to breaking. Is there way to just execute each task in order as I loop over the bundles? Any better way to achieve the same net result of config + source in, N bundles out?
I want to be clear that I am fully aware that Grunt CAN build multiple files. What I'm trying to do is separate the specification of how many bundles from the build steps themselves. Grunt core has to bake these two things together which means each project would have to go in and alter their build steps rather than an external configuration. As per the example above, I should be able to swap out the asset.json file specified in step 1 for any config file that has 1, 2, 3, ... N bundles with N files in each one (and potentially specifying a "type" like scripts or styles).
Edit 10/12/13: The Nitty Gritty posted an article yesterday that might be another approach to tackling your issue.
This can be done by passing the module name you want to build as a command line argument and loading in the whole assets file in your grunt config. Please note this is example code, I have not tested this, so it's possible you need to set paths etc. correct for your case.
Start with updating the assets.json file to a plain JavaScript file, and reform it like so:
module.exports = {
main: ["1.js", "2.js"],
secondary: ["2.js","3.js"]
}
Next, you can pass a command line argument to Grunt, which should specify one of the module names in assets.js. Example:
grunt --bundle=main
Now, you'll need to load in the assets.js file in the Gruntfile:
var assets = require('./assets'); // assuming assets.js is on the same level as your Gruntfile
And then you can get the argument name by using:
var bundle = grunt.option("bundle");
Now you can use bundle as your output file name and assets.bundle to get the array files for that bundle.
in my project, I want to refer to an other xcconfig file, located in InDesign SDK. As this SDK may be installed at different locations, depending upon the machine, I prefer to declare an environment variable for locating it.
Nest step is obviously to use variable (aptly named ID_CS5_SDK_DIR) in my xcconfig include directive.
Unfortunatly, when I try the simple
// InDesign sdk project build settings (based on common build settings)
#include "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
XCode throws me a
[WARN]AutocatPlugin.xcconfig line 7: Unable to find included file "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
How can I make it work ?
I've been trying to do this too and also came to the conclusion that it is not possible.
I once tried to achieve that and came to the conclusion that you can't. I would be happy if someone proves us it's possible though then delete my answer
It seems like .xcconfig files can only DEFINE and set value to environment variables (which prevail only throughout the build session) but not USE or evaluate environment variables.
Maybe it is because .xcconfig files serve as a base layer of build-settings, and are not parsed.
Unfortunately this is not possible, but instead of making one include the other, you can use two different xcconfig files per target. Just select one for the Project and one for the Target.
If you put the environment variable in /etc/config/launchd.conf and then reboot it will be accessible to the .xcconfig file.
Short Instructions for experienced users:
Edit the read-only file /etc/launchd.conf and add 'setenv VARIABLENAME /FOLDER/PATH' to the file, then reboot.
Steps For Inexperienced Users
Open Application/Utilities/Terminal, and entersudo nano /etc/launchd.conf
Create the Environment Variable by adding a line like setenv VARIABLENAME FOLDER/PATH and then pressing ENTER.
Save the file using Ctrl-O, Ctrl-M, (Possibly Ctrl-Y to overwrite), then Ctrl-X to exit the editor.
(Optional) type cat /etc/launchd.conf to see that your changes are present
Restart your computer. (Logoff doesn't work)
You can now access the variable in your .xcconfig file as$(VARIABLENAME)
Notes:
This creates a GLOBAL environment variable, accessible to all users. It probably doesn't make sense to set this to something in your home directory (e.g ~/MyFolder). If you do this, however, you need to use the full pathname, such as /Users/MyUserName/MyFolder).
References:
Stack Overflow - Setting Environment Variables in OSX
Stack Overflow - Are there any differences between /etc and /private /etc