Added local.EXT and local-deployment.EXT #20

Closed
wants to merge 4 commits into
from

Conversation

Projects
None yet
2 participants
@enyo
Contributor

enyo commented Apr 27, 2012

I added tests for it and a test for the test.yaml file as well (there wasn't any yet although the file already existed).
I also updated the History.md file.

@lorenwest

This comment has been minimized.

Show comment Hide comment
@lorenwest

lorenwest Apr 28, 2012

Owner

Hi Matias,

The runtime.json has historically been the place to stash local non-VCS configurations. Is there a reason that isn't working for you?

Owner

lorenwest commented Apr 28, 2012

Hi Matias,

The runtime.json has historically been the place to stash local non-VCS configurations. Is there a reason that isn't working for you?

@lorenwest

This comment has been minimized.

Show comment Hide comment
@lorenwest

lorenwest Apr 28, 2012

Owner

If the reason is .json isn't your preferred format, would changing runtime.json to runtime.EXT do the same thing?

Owner

lorenwest commented Apr 28, 2012

If the reason is .json isn't your preferred format, would changing runtime.json to runtime.EXT do the same thing?

@enyo

This comment has been minimized.

Show comment Hide comment
@enyo

enyo Apr 30, 2012

Contributor

Hi Loren,

Using runtime.json as a local non-vcs configuration file seems a bit dirty to me. Although it works, having local* config files feels cleaner and more what I'd expect if I wasn't familiar with the module (I wouldn't be sure if runtime.json doesn't get erased on every startup). It also gives you the ability to have local non-vcs configuration files for each deployment.

But.. I have to admit that having local conf files aren't actually necessary... At the same time they wouldn't hurt anyone :)

Contributor

enyo commented Apr 30, 2012

Hi Loren,

Using runtime.json as a local non-vcs configuration file seems a bit dirty to me. Although it works, having local* config files feels cleaner and more what I'd expect if I wasn't familiar with the module (I wouldn't be sure if runtime.json doesn't get erased on every startup). It also gives you the ability to have local non-vcs configuration files for each deployment.

But.. I have to admit that having local conf files aren't actually necessary... At the same time they wouldn't hurt anyone :)

@lorenwest

This comment has been minimized.

Show comment Hide comment
@lorenwest

lorenwest May 1, 2012

Owner

Hi Matias,

You make a convincing argument re: runtime.json not being the obvious place for this. I'm in favor of the local.EXT changes, and need a little help understanding the reasoning behind the local-{deployment}.EXT files. The reason for keeping the filenames separate is for them to all fit within one VCS, and deployed to all machines. The local.EXT file is the non-VCS (ie: hand coded) configuration, and I'd like a good answer when someone asks the reason for allowing multiple hand coded configuration files.

Owner

lorenwest commented May 1, 2012

Hi Matias,

You make a convincing argument re: runtime.json not being the obvious place for this. I'm in favor of the local.EXT changes, and need a little help understanding the reasoning behind the local-{deployment}.EXT files. The reason for keeping the filenames separate is for them to all fit within one VCS, and deployed to all machines. The local.EXT file is the non-VCS (ie: hand coded) configuration, and I'd like a good answer when someone asks the reason for allowing multiple hand coded configuration files.

@enyo

This comment has been minimized.

Show comment Hide comment
@enyo

enyo May 3, 2012

Contributor

Well... I was just thinking: why not. You may have different passwords for different services that you want to use in different deployments.
Lets say that you have a development database and a real database, and you want your app to connect to different databases depending on the deployment. You'd have to change your local.EXT file every time if you don't want the database password to be in your VCS.
Does that make sense?

Contributor

enyo commented May 3, 2012

Well... I was just thinking: why not. You may have different passwords for different services that you want to use in different deployments.
Lets say that you have a development database and a real database, and you want your app to connect to different databases depending on the deployment. You'd have to change your local.EXT file every time if you don't want the database password to be in your VCS.
Does that make sense?

@enyo

This comment has been minimized.

Show comment Hide comment
@enyo

enyo May 4, 2012

Contributor

Oups... I accidentally pushed a few other changes into this pull request.
If you would merge them both, I leave them here. If not, I can create a separate pull request!

The reason for switching from the visionmedia to the nodeca parser is mainly because I had lots of parse problems recently. The visionmedia parser is really far from finished and very buggy. There also hasn't been any commits for 5 months now. The nodeca parser is in active development and seems very stable and complete.

Contributor

enyo commented May 4, 2012

Oups... I accidentally pushed a few other changes into this pull request.
If you would merge them both, I leave them here. If not, I can create a separate pull request!

The reason for switching from the visionmedia to the nodeca parser is mainly because I had lots of parse problems recently. The visionmedia parser is really far from finished and very buggy. There also hasn't been any commits for 5 months now. The nodeca parser is in active development and seems very stable and complete.

@lorenwest

This comment has been minimized.

Show comment Hide comment
@lorenwest

lorenwest May 4, 2012

Owner

These are really two separate pull requests. I'm ready to pull the first request (local-*), and the second request needs further discussion. I'm all in favor of a better YAML library, but it can't be done in a way that breaks existing users.

If you can separate them into two pull requests, I'll merge this one and continue the discussion on the YAML improvement.

Owner

lorenwest commented May 4, 2012

These are really two separate pull requests. I'm ready to pull the first request (local-*), and the second request needs further discussion. I'm all in favor of a better YAML library, but it can't be done in a way that breaks existing users.

If you can separate them into two pull requests, I'll merge this one and continue the discussion on the YAML improvement.

@enyo

This comment has been minimized.

Show comment Hide comment
@enyo

enyo May 7, 2012

Contributor

I created a new pull request: #23

Contributor

enyo commented May 7, 2012

I created a new pull request: #23

@enyo enyo closed this May 7, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment