5 ms·

You should establish a proper pattern for storing credentials instead. Many people use environment variables, but you can also use an external configuration fil

You should establish a proper pattern for storing credentials instead. Many people use environment variables, but you can also use an external configuration file. Another simple pattern used a lot in django: try: from local_settings import * except Exception: pass Then put any variable you want to override in local_settings.py and put local_settings.py in .gitignore

jpitz 12y ago
If you read what TFA says: "Of course this is a stupid example, you would probably put the username, password and other important stuff in another file, say a config file, but let’s assume that this is not possible, or somehow this variable cannot be else where."
- oellegaard 12y ago
  I'd still argue that this is an anti-pattern. If you find yourself in a situation where you want to leave out a line from git in the middle of a file, you should reconsider the structure of your code/project/whatever.
  - oneeyedpigeon 12y ago
    Agreed. The article isn't particularly useful because it essentially says "this is how you solve a 'problem' that I'm only going to demonstrate by giving an example I immediately dismiss" and not explaining the type of situation in which this might be useful. Every time I've found myself in a similar situation, the problem has not been that git doesn't allow me to pretend that certain lines in a file don't exist, it's been that my design has been lacking.
peedy 12y ago
If you're on a django project, most probably you're using virtualenv. I had a habit of just putting environment variables in the postactivate script.
- pyre 12y ago
  E.g. I build a new virtualenv from scratch for each deploy, so that would mean that the postactivate script would need to be accessed from somewhere by the build process.
  - peedy 12y ago
    I was talking about local dev install where you can activate postactivate script is run after you source activate or call workon. In prod, you will not be activating the env but running executables directly from the env. ie, your process manager will call /path/to/env/bin/gunicorn and in this case, you'll have to configure the env variables here (in the process manager (supervisor)) config.
Mithaldu 12y ago
Ok, here, have a better example: I contract for a company which has set rules for their stuff. Trying to change these rules would be an amount of effort similar to becoming CEO, starting out as a deckswabber. One of their project is a web app. It has an .htaccess file. In production it is configured to run like this: Addhandler fcgid-script .fcgi However in development i want it to run like this: Addhandler cgi-script .fcgi Normally you'd just put the entire file on ignore with --assume-unchanged, but that doesn't work well, since the file also contains other bits of configuration that are important for the app, and get changed fairly frequently. OP's tool is perfect for this kind of situation.
- chrisan 12y ago
  FWIW we moved to a .htaccess.dist setup and our build tool would populate the actual .htaccess file with either of your examples depending if you were building for development or production. .htaccess is ignored while the .htaccess.dist template is part of the reop
  - Mithaldu 12y ago
    That still means i need to trigger a rebuild on every pull/checkout/reset. Only a marginal improvement, really.
    - chrisan 12y ago
      We only need to rebuild that file when we want to change it, which doesn't happen often. It's been at least a year since I changed my local dev copy for our main project and has survived many pulls/branches/resets What kinda stuff are you putting in .htaccess that changes so often?
- zak_mc_kracken 12y ago
  Another example: IDE configuration settings. Projects sometimes check in an IDE formatting file settings to ensure that all developers use the same formatting. There are a couple of times where I wanted to add my own little formatting detail (which didn't conflict with the project's) but couldn't because doing so would mark that file modified and force me to remember to undo my changes before each push. With the hack from the article, I have now a working solution out of this.
xorcist 12y ago
Why would you do that? Store configuration in a checked-in directory? Do you expect to develop on your production systems? Do you also store databases in the same directory? I can not think of a possible use case for this, but I guess there must be since this at least someone seems to recognize it.
zak_mc_kracken 12y ago
You're missing the point.

jpitz 12y ago

If you read what TFA says: "Of course this is a stupid example, you would probably put the username, password and other important stuff in another file, say a config file, but let’s assume that this is not possible, or somehow this variable cannot be else where."

oellegaard 12y ago
I'd still argue that this is an anti-pattern. If you find yourself in a situation where you want to leave out a line from git in the middle of a file, you should reconsider the structure of your code/project/whatever.
- oneeyedpigeon 12y ago
  Agreed. The article isn't particularly useful because it essentially says "this is how you solve a 'problem' that I'm only going to demonstrate by giving an example I immediately dismiss" and not explaining the type of situation in which this might be useful. Every time I've found myself in a similar situation, the problem has not been that git doesn't allow me to pretend that certain lines in a file don't exist, it's been that my design has been lacking.

peedy 12y ago

If you're on a django project, most probably you're using virtualenv. I had a habit of just putting environment variables in the postactivate script.

pyre 12y ago
E.g. I build a new virtualenv from scratch for each deploy, so that would mean that the postactivate script would need to be accessed from somewhere by the build process.
- peedy 12y ago
  I was talking about local dev install where you can activate postactivate script is run after you source activate or call workon. In prod, you will not be activating the env but running executables directly from the env. ie, your process manager will call /path/to/env/bin/gunicorn and in this case, you'll have to configure the env variables here (in the process manager (supervisor)) config.

Mithaldu 12y ago

Ok, here, have a better example: I contract for a company which has set rules for their stuff. Trying to change these rules would be an amount of effort similar to becoming CEO, starting out as a deckswabber. One of their project is a web app. It has an .htaccess file. In production it is configured to run like this: Addhandler fcgid-script .fcgi However in development i want it to run like this: Addhandler cgi-script .fcgi Normally you'd just put the entire file on ignore with --assume-unchanged, but that doesn't work well, since the file also contains other bits of configuration that are important for the app, and get changed fairly frequently. OP's tool is perfect for this kind of situation.

chrisan 12y ago
FWIW we moved to a .htaccess.dist setup and our build tool would populate the actual .htaccess file with either of your examples depending if you were building for development or production. .htaccess is ignored while the .htaccess.dist template is part of the reop
- Mithaldu 12y ago
  That still means i need to trigger a rebuild on every pull/checkout/reset. Only a marginal improvement, really.
  - chrisan 12y ago
    We only need to rebuild that file when we want to change it, which doesn't happen often. It's been at least a year since I changed my local dev copy for our main project and has survived many pulls/branches/resets What kinda stuff are you putting in .htaccess that changes so often?
zak_mc_kracken 12y ago
Another example: IDE configuration settings. Projects sometimes check in an IDE formatting file settings to ensure that all developers use the same formatting. There are a couple of times where I wanted to add my own little formatting detail (which didn't conflict with the project's) but couldn't because doing so would mark that file modified and force me to remember to undo my changes before each push. With the hack from the article, I have now a working solution out of this.

xorcist 12y ago

Why would you do that? Store configuration in a checked-in directory? Do you expect to develop on your production systems? Do you also store databases in the same directory? I can not think of a possible use case for this, but I guess there must be since this at least someone seems to recognize it.

zak_mc_kracken 12y ago

You're missing the point.