There's a lot of programs out there that can utilize .env files. Most of them support the basic bash-syntax, others support more advanced things like templating within the .env files. The way you're supposed to use .env files varies a lot as well. Often in this context, you'll year from the 12-factor-app which states that you should export (some) configuration as environment variables, that apparently lead to two use cases:
Some dotenv programs do just that: you prefix your command on the shell with dotenv and the variables in the dotenv file will magically be available in you process.
Others however provide libraries that actually read .env files from within your code -- a very different approach since your code is suddenly interpreting .env files directly and does not "see" the environment variables anymore.
Since there's so many different interpretations of usage, use-cases and syntax, is there a proper definition of .env files or some commonly accepted standard? If not, at least some historical references?
It appears that .env files lack a complete definition.
This reference:
https://devcenter.heroku.com/articles/heroku-local
Links here:
http://blog.daviddollar.org/2011/05/06/introducing-foreman.html
Which leads here:
https://ddollar.github.io/foreman/
Which contains this:
ENVIRONMENT
If a .env file exists in the current directory, the default
environment will be read from it. This file should contain key/value
pairs, separated by =, with one key/value pair per line.
FOO=bar
BAZ=qux
Related
I have a directory structure as follows to build the Terraform resources for my project:
s3
main.tf
variables.tf
tag_variables.tf
ec2
main.tf
variables.tf
tag_variables.tf
vpc
main.tf
variables.tf
tag_variables.tf
When I want to build or change something in s3, I run the Terraform the s3 directory.
When I want to build the ec2 resources, I cd into that folder and do a Terraform build there.
I run them one at a time.
At the moment I have a list of tags defined as variables, inside each directory.
This is the same file, copied many times to each directory.
Is there a way to avoid copying the same tags file into all of the folders? I'm looking for a solution where I only have only one copy of the tags file.
Terraform do offer a solution of sorts using the "local" verb, but this still needs the file to be repeated in each directory.
What I tried:
I tried putting the variables in a module, but variables are internal to a module, modules are not designed to share code into the main file.
I tried making the variables an output from the module but it didn't like that either.
Does anyone have a way to achieve one central tags file that gets used everywhere? I'm thinking of something like an include of a source code chunk from elsewhere? Or any other solution would be great.
Thanks for that advice ydaetskcoR, I used symlinks and this works perfectly.
I placed the tags list.tf file in a common directory. Each Terraform project now has a symbolic link to the file. (Plus I've linked some other common files in this way, like provider.tf).
For the benefit of others, in Linux a symbolic link is a small file that is a link to another file, but it can be used exactly like the original file.
This allows many different and separate Terraform projects to refer to the common file.
Note: If you are looking to modularise common Terraform functions, have a look at Terraform modules, these are designed to modularise your code. They can't be used for the simple use case above, however.
According to Apple's Developer Docs the Library global allows one to import compiled scripts so they can be used as a library in one's current script. This works just fine if you were to do something like the below code with myLibName.scpt located at ~/Library/Script Libraries:
myLib = Library('myLibName');
myLib.myLibMethod() // Works just fine
But, the docs also claim that one can export an environment variable — OSA_LIBRARY_PATH containing a string of : delimited paths — and Library() would then defer to that list of paths before proceeding to it's default path: ~/Library/Script Libraries. Ya know, like the bash environment variable Path. Here's the relevant piece of documentation below; it describes the path hierarchy:
The basic requirement for a script to be a script
library is its location: it must be a script document in a “Script
Libraries” folder in one of the following folders. When searching for
a library, the locations are searched in the order listed, and the
first matching script is used:
If the script that references the library is a bundle, the script’s
bundle Resources directory. This means that scripts may be packaged
and distributed with the libraries they use.
If the application running the script is a bundle, the application’s bundle Resources
directory. This means that script applications (“applets” and
“droplets”) may be packaged and distributed with the libraries they
use. It also enables applications that run scripts to provide
libraries for use by those scripts.
Any folders specified in the environment variable OSA_LIBRARY_PATH. This allows using a library
without installing it in one of the usual locations. The value of this
variable is a colon-separated list of paths, such as /opt/local/Script
Libraries:/usr/local/Script Libraries. Unlike the other library
locations, paths specified in OSA_LIBRARY_PATH are used exactly as-is,
without appending “Script Libraries”. Supported in OS X v10.11 and
later.
The Library folder in the user’s home directory, ~/Library.
This is the location to install libraries for use by a single user,
and is the recommended location during library development.
The
computer Library folder, /Library. Libraries located here are
available to all users of the computer.
The network Library folder,
/Network/Library. Libraries located here are available to multiple
computers on a network.
The system Library folder, /System/Library.
These are libraries provided by OS X.
Any installed application
bundle, in the application’s bundle Library directory. This allows
distributing libraries that are associated with an application, or
creating applications that exist solely to distribute libraries.
Supported in OS X v10.11 and later.
The problem is that it doesn't work. I've tried exporting the OSA_LIBRARY_PATH variable — globally via my .zshrc file — and then running a sample script just like the one above via both the Script Editor and the osascript executable. Nothing works; I get a "file not found" error. I found this thread-where-the-participants-give-up-hope online; it doesn't explain much. Any thoughts?
On a somewhat related note, the Scripting Additions suite provides two other methods — loadScript and storeScript — that seem like they might be useful here. Unfortunately, when you try to use them, osascript gives you the finger. Though, I did manage to return what looked like a hexadecimal buffer from a compiled script using loadScript. Anyway, any insight you guys can shed on this would be much appreciated. Thanks.
The OSA_LIBRARY_PATH environment variable is ignored by restricted executables when running with System Integrity Protection enabled.
To workaround this limitation you can either turn off SIP, or you can use an unrestricted executable.
For instance, to make osascript unrestricted, you should first make a copy, and then re-sign it with an ad-hoc signature:
cp /usr/bin/osascript ./osascript
codesign -f -s - ./osascript
Once you have the unrestricted osascript, you can run it with the OSA_LIBRARY_PATH environment variable set like this:
OSA_LIBRARY_PATH="/path/to/libs" ./osascript path/to/script.scpt
As a lousy alternative, you can put a symlink at one of the "Script Libraries" folders that osascript would look at and point it to the folder you want. Note that the symlink must be a replacement for the entire folder, it can't just exist inside of it.
rm -rf ~/Library/Script\ Libraries
ln -s "/Your/Custom/Path/Goes/Here/" ~/Library/Script\ Libraries
Tested on 10.13.2
Is there mechanism to import local settings to codeception.yml configuration file?
Our developers have their own databases and maybe some other environment specific settings for the testing, so these settings shouldn't be pushed to GIT. Normally we solve this problem by having two configuration files, where other one is global & in GIT. Another, local one is merged in some way or another to global one and ignored by the git. What I like to achieve would be following structure:
codeception.yml - global settings
codeception.local.yml - local settings witch would be merged to global settings e.g. by the import
There is a include property for config files, but it seems to deal with complete testing suites.
Yes actually. I can't find anything the manual about it, so I dug through the source code and it looks like it reads both codeception.yml and codeception.dist.yml files.
I tested it out it looks like codeception.dist.yml is your global config, and codeception.yml is what you should use for your local and put into .gitignore. Same goes for the suite.yml files. acceptance.suite.dist.yml is the global that gets overwritten by acceptance.suite.yml, etc etc.
I checked quite a few similar questions, but so far I am unsatisfied with the solutions.
Ever use the Minecraft Server? At initial launch, it creates all the files and folders it needs, and allows you to make changes to files like Server.properties and ops.txt by making them external of the executable jar file.
I'm working on a similar project, and I want to duplicate that behavior. Everything works great when I run it in eclipse. When I export to a jar file though, things get funky. The external files and folders are created without a hitch, but afterword, it would appear as though they cannot be read from or written to. Any ideas how Notch made his server?
--edit--
Scratch that, it doesn't even appear to reliably create the files and folders. Maybe it only creates them the very first run after creation?
--edit again--
It creates them in the root directory. When I tested it in eclipse, the root directory was limited to the folder containing the project, and therefore looked fine. The solution was to make the class aware of it's location, and include it in all file operations.
Have the main class in your executable jar file look up where it is, then have it store that information in a global String or something. Prefix your filenames with that string in your file operations, and voila! It's writing to the correct directory.
I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!